-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New package: ExpmvCore v0.1.0 #116607
New package: ExpmvCore v0.1.0 #116607
Conversation
JuliaRegistrator
commented
Oct 4, 2024
- Registering package: ExpmvCore
- Repository: https://github.com/jecs/StaticExpmv.jl
- Created by: @jecs
- Version: v0.1.0
- Commit: 858a5d65d19bca0072d82144312db71f6f07d044
- Git reference: HEAD
UUID: 08d6d8b8-3c9c-4c77-8a4f-ab2df6813922 Repo: https://github.com/jecs/StaticExpmv.jl.git Tree: e5c90f2c671282d545834e7551e6e29e85a33949 Registrator tree SHA: 191228b6dd8b9d0e2965ae3e705fe54c51dcfee8
Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human. 1. New package registrationPlease make sure that you have read the package naming guidelines. 2. AutoMerge Guidelines are all met! ✅Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed. 3. To pause or stop registrationIf you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text Tip: You can edit blocking comments to add |
#116605 (comment) still applies |
I would prefer to make this package available now so that my research collaborators can use it while I figure out how to integrate my code cleanly into the SciML package. I would need to look into how extensions, weak dependencies, and all of that work first. I do also see the value in having a standalone package that would result in lower precompilation times for code that deals exclusively with StaticArrays. I would also prefer that whether my code is available publicly not depend on whether I want to incorporate my code into a larger package. What if I don't agree with the design choices in the package to which you want me to merge my code? What if I want to retain ownership of the project? I'm surprised to see this sort of strong-arming in the Julia community. |
Since registrations in
Your code does not have to be registered in
Or, you can register it in another registry, i.e., set up a LocalRegistry, to make it easier to work with the package if it is a dependency for other (unregistered) packages currently under development. [Edit: that would install |
I'm also a little confused about the package name and organization, in terms of this being a sub-package of https://github.com/jecs/StaticExpmv.jl. The parent package There's also that if the parent package is named Lastly, even for sub-packages, there has to be an independent README (in https://github.com/jecs/StaticExpmv.jl/tree/master/ExpmvCore) that explains the context and the relationship to the parent package, and possibly points to more complete documentation for the functionality implemented by the sub-package. |
Registering the main package requires registering the subpackage. That's why I'm starting with ExpmvCore before adding StaticExpmv. Otherwise the registration process errors out. |
Alright, that makes sense. The sub-package should definitely be
It would be possible (and even preferable, albeit a little more difficult) to manually prepare a PR that registers both I'm not fundamentally opposed to having an independent |
I personally think making code available is not a sufficient reason for registration. As soon as your package is on GitHub, it is installable and your collaborators can use it. The real question is whether your design philosophy is so different from what came before that it warrants a separate name in the general registry. |
I'd be happy to pull this in as a static array extension. Though it is a bit of an odd idea because expmv tends to only do well for sufficiently large matrices (generating the exponential is pretty good for small matrices but has poor scaling) so I'm very curious if this is even a good idea in the first place. I'd be interested to see what the benchmarks say. |
@ChrisRackauckas Even for 6x6 matrices, I saw a speedup of 3x. |
|
Those are pretty good results. Unexpected. I can see that coming in handy for Magnus methods. |
Cool. Please let me know how you'd like to proceed. Whatever package you think this would fit nicely in, I'd be happy to incorporate this code in it. |
@goerz Please feel free to close. We merged my code into ExponentialUtilities.jl. |