-
-
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
incorrect bessel functions of large order #4366
Comments
By the way,
(the correct result, more or less), so the |
Possibly this issue is related to the version of the Amos library used by Julia? The netlib version is an older version, which was later updated (but the updated version has a different license). I came across a similar issue a few years ago in the octave implementation of bessel functions, which I think is the same as Julia's. |
We should really use the SLATEC version (patched with bugfixes as needed) for licensing reasons, since only the SLATEC version comes with a clear statement that it is in the public domain. (In contrast, anything in ACM TOMS is by default unusable.) |
I had tried slatec at one point, but just dropping it in did not even make our tests pass. It is probably in the history of openlibm-extras and can be reinstated from the git history. I never dug deep into what happened. |
I believe this is fixed now? |
The purity issue seems to be fixed. However, julia> besselj(2^29,0.1) #Takes ~8s to run
0.0
julia> besselj(float(2^29),0.1)
0.0
julia> besselj(2^31, 0.1)
0.049937526036242
julia> besselj(float(2^31), 0.1)
6.9318596292179e-310 |
The underflowing cases reported in this issue now throw |
The integer order version is still a bit wonky. I get
|
Our version of openlibm uses a recurrence relation to build higher order Bessel functions from j0 and j1. For orders greater than int32_t, the recurrence loop never runs thanks to integer overflow in the loop index. The fix here is to simply throw a DomainError for such enormous values of the order of the Bessel function.
Thanks for the reminder for that case. This should now be fixed as well. |
- Instead of throwing DomainError for besselj(n, x) when n>typemax(Int32), call besselj(float64(n), x) instead. - Fixes also wraparound for n<typemin(Int32). The behavior for n::Int is now symmetric and complements the runtime dispatch behavior for n::FloatingPoint.
e.g.
besselj(n, 0.1)
should underflow to zero forn > 110
(as checked via WolframAlpha), but our implementation underflows forn > 100
.Worse, for sufficiently large orders it "un-underflows". For example,
besselj(2.0^70, 0.1)
gives2.1386280643e-314
instead of 0.0.Worse, the behavior for large orders is not pure: it depends upon previous function calls! Consider the following two examples (both after restarting Julia):
(where
2^70
gives0
, so the the latter is the correct result forbesselj(0, 0.1)
), but:where somehow the earlier result for
2^70
has "corrupted" the later result for2.0^70
!!!The text was updated successfully, but these errors were encountered: