-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
move special functions out of Base? #8536
Comments
This issue can fight it out with #4301 :) |
Cc: @lindahua |
This didn't get much attention, but I'm in favor of it primarily because it gets rid of a Fortran dependency with a pretty minor performance cost. Does anyone use these special functions frequently enough that moving them into a package would be a major hassle for them? If so then no rush, we can wait until package precompilation is working well I suppose. In order for this to happen, SpecialFunctions.jl would have to be fleshed out the rest of the way by copying over the docs (tests look like they're copied already?) from the relevant parts of base / openspecfun, registered and tested (on travis and package evaluator). |
I'd be okay with this as well. |
I guess we need to resolve the "big Base vs small Base" argument first, e.g., #75. |
And #5155, #1906 and a few others. I feel like the more-or-less consensus for the right thing to do is small[er than now] base with a good mechanism for making bundled installs including most of the commonly-used packages by default, preferably precompiled for fast load times. We haven't implemented either bundled-with-packages installs or precompiled packages yet. But at least for something small and maybe not-so-widely-used like this it could be good to do a dry run of what the process of migrating things out of base looks like, regardless of whether the nice-to-have features are ready yet. We've seen several cases of packages moving into base, especially when replacing troublesome binary dependencies. Not so many cases of the other way around recently, since the original creation of the package manager right? |
@nolta I took your work and updated it for 0.6 (not the translator, but the resulting files). |
Continuing the discussion in #8294, now that the amos code has been converted to julia, do we want to start moving the special functions (e.g.,
airy*
,bessel*
,hankel*
) out of Base and into a package?The text was updated successfully, but these errors were encountered: