SpecialFunctions.jl
SpecialFunctions.jl copied to clipboard
JuliaMath
implement Lambert W function
This copies the implementation of the Lambert W function and related functions and data from jlapeyre/LambertW.jl to SpecialFunctions.jl
How do you prefer updates to the PR ? I could rebase and force push, but I think we lose link between comments and code this way.
@stevengj I suggest putting off reviewing until this round of changes are made to avoid duplicating effort / wasting time.
You can just push more commits to your branch and they'll show up here. We can squash on merge.
The latest commit addresses all comments made by @ararslan. I did a bit of other refactoring and tidying.
I'd like to close this and issue a new PR after v1.0. In the upstream source LambertW.jl, I dropped v0.6 support, and have improved clarity and compliance with style standards. The upstream source already incorporates changes made during the code review here. (I have not yet pushed all these changes to github.)
@alyst, this PR is out of date. LambertW has changed in the meantime. I (or we) need to merge the changes into this PR branch.
@alyst, this PR is out of date.
LambertWhas changed in the meantime. I (or we) need to merge the changes into this PR branch.
Let me know how you want to do it.
Seems like lots of people want this, but maybe it is easiest to just refresh the package that @jlapeyre has. Is it registered? Should we move it to JuliaMath?
It's not clear to me the advantage of moving lambertw to SpecialFunctions. A few people want it moved, but I didn't see an argument. Maybe they use it frequently and already import SpecialFunctions a lot, and don't want to be required to do import LambertW.
@ViralBShah : Yes, this package is registered. I very much support moving this to JuliaMath.
It seems like a bit of work to get this moved to SpecialFunctions. One issue is the big, flat, namespace in SpecialFunctions. What to do with LambertW.omega? I think SpecialFunctions.omega is not a good choice.
I'm not completely against moving LambertW.jl, but I'd like to see arguments for why.
I'm not completely against moving LambertW.jl, but I'd like to see arguments for why.
- it's more likely that packages like SpecialFunctions.jl will have (co-)maintainers in the long run
- even if (co-)maintainers of "fine-grained" packages are available, it would be an extra burden for them to do the tedious, but necessary work of keeping the API, documentation, unit tests and CI scripts up-to-date
- Labert W function does not depend on any other packages, and the code base is sufficiently lean and straightforward, so adding it to SpecialFunctions.jl would not make the latter heavier
- it's a matter of taste, but I find it's easier to discover/evaluate methods/tools when they are organized into dedicated registries like SpecialFunctions.jl
What to do with
LambertW.omega? I thinkSpecialFunctions.omegais not a good choice.
How about using lambertw(1) as the public API to access the value of the Omega constant? No need for an additional name. Just guarantee that lambertw(1) has a fast evaluation path.
I think
SpecialFunctions.omegais not a good choice.
Another option is SpecialFunctions.lambert_omega, and it doesn't have to be exported.
- it's more likely that packages like SpecialFunctions.jl will have (co-)maintainers in the long run
My experience so far has been the opposite: large packages like SpecialFunctions.jl and Distributions.jl struggle to keep maintainers. Smaller packages tend to have an easier time keeping maintainers (I presume due to a lower maintenance burden, and the code author feeling an ownership of the package).
Perhaps, as a middle ground solution, the functions can be reexported then?
I agree with @simonbyrne, I don't think it's necessarily better maintained if it is part of SpecialFunctions.
IMO separate packages are fine in this case. In my experience they are annoying mainly if one always has to load a specific set of packages to achieve some basic functionality but I don't think this is the case here. One can use LambertW just fine without loading SpecialFunctions, and similarly SpecialFunctions without LambertW.
One problem with reexporting LambertW is that any breaking release of LambertW requires a breaking release of SpecialFunctions. Due to the large number of dependencies (1625 packages), it takes quite a while until a breaking release of SpecialFunctions is propagated through the Julia ecosystem and it requires work and time from many downstream developers, whereas a breaking release of LambertW (if SpecialFunctions does not reexport it) would have less severe effects since it only has a few (4 to be precise) dependencies.
How about using lambertw(1) as the public API to access the value of the Omega constant? No need for an additional name. Just guarantee that lambertw(1) has a fast evaluation path.
The problem is that Omega should be of type Base.Irrational{:XXX} (as the other constants), which could then be explicitly converted to a numeric type the user specifies, so it cannot be returned by lambertw(1) directly for the sake of type stability.
But the fast path to calculate lambertw(1)/lambertw(big(1))/lambertw(complex(1,0)) is already there.
Smaller packages tend to have an easier time keeping maintainers (I presume due to a lower maintenance burden, and the code author feeling an ownership of the package).
"Feeling an ownership" is a double-edged sword. In my experience the code quality of community-maintained packages is better -- more eyes to look at the code, more chances to keep up with the evolving Julia standards, more predictable PR review and acceptance policy. Anyway, what I am saying about community maintenance only concerns the functionality that is "adjacent" to the core of the language. Clearly, SpecialFunctions.jl belongs to this category. I believe lambertw() belongs there too, given its numerous applications in different branches of science. But then again, it is up to the core Julia "stakeholders" to define and implement the strategy that would keep such functionality in good shape. For my part I have just implemented in #371 what I have thought is need for this PR to be accepted.
In my experience the code quality of community-maintained packages is better -- more eyes to look at the code, more chances to keep up with the evolving Julia standards, more predictable PR review and acceptance policy.
It seems that just transferring to LambertW.jl to JuliaMath would also achieve this? It could then be seen as a community package, no longer with a sole owner. Also more people will have commit access, code reviews, etc. ... And that way it remains independent of SpecialFunctions.jl, which has a lot more ~~dependencies~~dependants.
Looked at it this way, it would seem that transferring LambertW.jl to JuliaMath is the happy solution for everybody.
Looked at it this way, it would seem that transferring LambertW.jl to JuliaMath is the happy solution for everybody.
Authorship aside, it's yet another package to make sure that e.g. .github/workflows or docs/make.jl scripts are up-to-date.
So far lambertw() doesn't have any dependencies, so I don't expect that in the future SpecialFunctions.jl would need minor version updates because of lambertw()
(Well, for my fork I had to add Compat to support evalpoly() on Julia 1.3, but if that is critical, I can switch to @evalpoly macro that should work everywhere).
I thumbs-upped the comments supporting not putting LambertW in SpecialFunctions. I propose moving it to JuliaMath. This does not preclude, or make it any more difficult, to later move it to SpecialFunctions. I know there are arguments both ways. The problem is you can't put yourself in the shoes of every user and know what their workflow is like.
@simonbyrne Can I ask why was this closed? Is it still the plan to transfer lambertw to this package?
That, and it seems there was a consensus in keeping it as a separate package?