#2017 sin(1e22) is wrong

closed
nobody
5
2010-06-30
2010-06-11
No

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

Discussion

  • Derek O'Connor

    Derek O'Connor - 2010-06-11

    CORRECTION:

    -8.522008497671888 should be -0.8522008497671888

    Derek O'Connor

     
  • Raymond Toy

    Raymond Toy - 2010-06-11
    • status: open --> pending
     
  • Raymond Toy

    Raymond Toy - 2010-06-11

    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.

     
  • Aleksas Domarkas

    (%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

     
  • Derek O'Connor

    Derek O'Connor - 2010-06-12

    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.

     
  • Derek O'Connor

    Derek O'Connor - 2010-06-12
    • status: pending --> open
     
  • Raymond Toy

    Raymond Toy - 2010-06-13

    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.)

     
  • Derek O'Connor

    Derek O'Connor - 2010-06-13

    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?

     
  • Raymond Toy

    Raymond Toy - 2010-06-15

    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.

     
  • Raymond Toy

    Raymond Toy - 2010-06-15
    • status: open --> pending
     
  • Robert Dodier

    Robert Dodier - 2010-06-15

    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.

     
  • SourceForge Robot

    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).

     
  • SourceForge Robot

    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks