CORRECTION:
-8.522008497671888 should be -0.8522008497671888
Derek O'Connor
sin(1e22);
(%o1) 0.41214336710708
The correct answer is -8.522008497671888
Please note that 10^22 is exactly representable as an IEEE double precision floating point number, whose binary representation is
10^22 = 1000011110000110011110000011001001101110101011001001 x 2^22
This incorrect result suggests that the range-reduction step, where the argument x is reduced to lie in a small interval around 0, such as [-pi/2,+pi/2], has not been done properly. This means that the other trigonometric functions will be incorrect.
This value 10^22 was carefully chosen by Ng to uncover faulty range reduction:
http://www.derekroconnor.net/Software/Ng--ArgReduction.pdf
Maxima is not alone: R, Octave, Freemat, Euler, Python, and Lua have the same problem. Matlab used to have this problem but fixed it.
I am neither a systems programmer nor a Maxima developer so I don't know what is going on in the background. I suspect that the mingw32 system may be at fault. If so, this prompts the question: do Maxima developers not check the components they are using?
Maxima version: 5.21.1
Maxima build date: 8:13 4/26/2010
Host type: i686-pc-mingw32
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.8
Dell Precision 690, Intel 2xQuad-Core E5345 @ 2.33GHz
16GB RAM, Windows7 64-bit Professional.
Derek O'Connor
CORRECTION:
-8.522008497671888 should be -0.8522008497671888
Derek O'Connor
Maxima computes sin(1e22) by defering to the Lisp implementation to evaluate it. Gcl produces the incorrect answer.
Maxima with cmucl produces -0.8522008497671888, as you expect.
I consider this a bug in gcl, not maxima.
Marking as pending/wontfix.
(%i1) fpprec : 32;
(%o1) 32
(%i2) bfloat(sin(10^22));
(%o2) -8.5220084976718880177270589375303b-1
(%i3) build_info()$
Maxima version: 5.21.1
Maxima build date: 8:13 4/26/2010
Host type: i686-pc-mingw32
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.8
I am NOT concerned about bfloat(sin(10^22)) or sin(bfloat(10^22)). I am concerned that sin(10^22) gives the wrong answer on my system, and presumably, on many similar systems.
As I mentioned, I consider this a bug in gcl, not maxima.
Although I could fix it, I'm not inclined to do so. It would be a lot of work to do and to support just for gcl when ccl, I think, produces the correct result. (It does on Mac OS X.)
The bug is not really in gcl but in ming32.
R 2.11.0 under ming32 gives the wrong answer while R 2.11.0 under ming64 gives the right answer.
Is it possible to get a version of Maxima (or gcl) that uses ming64?
I think it would be best to ask on the mailing list to see if someone can do a windows build with gcl using ming64. Or ask on the gcl list if there's a mingw64 version.
Setting this to pending/wontfix again.
For the record, Clozure CL (Version 1.4-r13122 on Windows Vista) returns (sin 1d22) => 0.41214336710708466D0.
I agree with Ray T that these are bugs in the Lisp implementation. I don't think Maxima should try to replace all of the math functions in Lisp, so we have to rely on the Lisp implementation for sin and other functions.
If someone has time to report these bugs to the Lisp implementations bug trackers, that would be terrific.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Log in to post a comment.