GNOME Bugzilla – Bug 706720
BESSSELJ and BESSELY should accepts non-integer order
Last modified: 2013-08-28 18:26:53 UTC
OCTAVE octave:17> x=-10.; octave:18> z = 2./3.*(-x)^(3/2) z = 21.082 octave:19> j1d3 = besselj(1./3.,z) j1 = 0.10527 octave:20> y1d3 = bessely(1./3.,z) y1 = 0.13825 octave:21> ai = sqrt(-x)/2.*(j1 - 1./sqrt(3.)*y1) ai = 0.040241 octave:22> airy(-10) ans = 0.040241 octave:23> diary off Gnumeric x = -10 z = 21.0818510677892 besselj(z,1./3.) = 0.02249321774033 bessely(z,1./3.) = 0.17228790219214 Ai(x) = -0.12171171737702 Results reported by Gnumeric
bessely is documented to truncate the order to an integer.
@jim, what are you claiming as a bug??
According to OpenFormula (ODF 1.2): BESSELI( Integer X ; Number N )
> z = 21.0818510677892 > besselj(z,1./3.) = 0.02249321774033 > bessely(z,1./3.) = 0.1722879021921 The problem seems to be that for Gnumeric besselJ(z,order) order is any non negative INTEGER besselY(z,order) order is any non negative INTEGER besselI(z,order) order is any non negative NUMBER besselK(z,order) order is any non negative NUMBER
Re-opening, re-titling. We don't really have to follow XL and/or ODF here. The only reason we don't allow non-integer orders for J and Y is that the C library's versions only handle integers. It looks like we can just grab R's versions (which are based on Netlib's versions).
Of course we don't have to follow XL and/or ODF. But if we don't (and use the same function names) we do loose compatibility in the sense that saving as ODF or xls or xlsx will create files that show significantly different results in Excel or other ODF implementations.
I should mention that there is less of an issue with regard to ODF, since in ODF the conversion from number to integer is implementation-defined, so use of a non-integer argument isn't portable anyways.
You're right, of course, but we have done this kind of domain extension before. FACT and IMPOWER, I think. In practice it is not a problem. If anyone actually calls BESSELY with 2.14 as the order and expects that to be treated as 2, we are deep into self-inflicted-pain territory. And there will be a cheap work-around that actually improves readability of the expression.
I believe it would be a useful addition, to include non-integer orders for BESSELJ and BESSSELY. I believe OCTAVE notes that there are some differences and addition with MATLAB that people accept?
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.