Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: SourceForge.net <noreply@so...>  20100611 14:10:53

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Tracker Item Submitted) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 18:38:47

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100611 22:40:55

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 09:30:06

Bugs item #3014845, was opened at 20100611 17:10 Message generated for change (Comment added) made by alex108 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  Comment By: Aleksas Domarkas (alex108) Date: 20100612 12:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100612 01:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 21:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100612 22:56:08

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100612 23:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 10:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 23:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100613 02:00:06

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100612 22:00 Message: 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.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 18:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 05:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100613 09:54:08

Bugs item #3014845, was opened at 20100611 15:10 Message generated for change (Comment added) made by derekroconnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Derek O'Connor (derekroconnor) Date: 20100613 10:54 Message: 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?  Comment By: Raymond Toy (rtoy) Date: 20100613 03:00 Message: 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.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 23:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 10:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 23:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 19:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100615 02:05:05

Bugs item #3014845, was opened at 20100611 10:10 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Raymond Toy (rtoy) Date: 20100614 22:05 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 05:54 Message: 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?  Comment By: Raymond Toy (rtoy) Date: 20100612 22:00 Message: 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.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 18:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 05:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 18:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 14:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100615 05:20:22

Bugs item #3014845, was opened at 20100611 08:10 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: Robert Dodier (robert_dodier) Date: 20100614 23:20 Message: For the record, Clozure CL (Version 1.4r13122 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.  Comment By: Raymond Toy (rtoy) Date: 20100614 20:05 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 03:54 Message: 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?  Comment By: Raymond Toy (rtoy) Date: 20100612 20:00 Message: 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.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 16:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 03:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 16:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 12:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
From: SourceForge.net <noreply@so...>  20100630 02:20:05

Bugs item #3014845, was opened at 20100611 14:10 Message generated for change (Settings changed) made by sfrobot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Lisp Core  Floating point Group: None >Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Derek O'Connor (derekroconnor) Assigned to: Nobody/Anonymous (nobody) Summary: sin(1e22) is wrong Initial Comment: 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 rangereduction 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/NgArgReduction.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: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8 Dell Precision 690, Intel 2xQuadCore E5345 @ 2.33GHz 16GB RAM, Windows7 64bit Professional. Derek O'Connor  >Comment By: SourceForge Robot (sfrobot) Date: 20100630 02:20 Message: 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).  Comment By: Robert Dodier (robert_dodier) Date: 20100615 05:20 Message: For the record, Clozure CL (Version 1.4r13122 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.  Comment By: Raymond Toy (rtoy) Date: 20100615 02:05 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100613 09:54 Message: 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?  Comment By: Raymond Toy (rtoy) Date: 20100613 02:00 Message: 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.)  Comment By: Derek O'Connor (derekroconnor) Date: 20100612 22:56 Message: 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.  Comment By: Aleksas Domarkas (alex108) Date: 20100612 09:30 Message: (%i1) fpprec : 32; (%o1) 32 (%i2) bfloat(sin(10^22)); (%o2) 8.5220084976718880177270589375303b1 (%i3) build_info()$ Maxima version: 5.21.1 Maxima build date: 8:13 4/26/2010 Host type: i686pcmingw32 Lisp implementation type: GNU Common Lisp (GCL) Lisp implementation version: GCL 2.6.8  Comment By: Raymond Toy (rtoy) Date: 20100611 22:40 Message: 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.  Comment By: Derek O'Connor (derekroconnor) Date: 20100611 18:38 Message: CORRECTION: 8.522008497671888 should be 0.8522008497671888 Derek O'Connor  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 
Sign up for the SourceForge newsletter:
No, thanks