Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

## maxima-bugs

 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-11 14:10:53 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3014845&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-11 18:38:47 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Derek O'Connor (derekroconnor) Date: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-11 22:40:55 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-12 09:30:06 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- Comment By: Aleksas Domarkas (alex108) Date: 2010-06-12 12:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-12 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-12 22:56:08 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Derek O'Connor (derekroconnor) Date: 2010-06-12 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: 2010-06-12 10:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-13 02:00:06 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2010-06-12 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: 2010-06-12 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: 2010-06-12 05:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-13 09:54:08 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Derek O'Connor (derekroconnor) Date: 2010-06-13 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: 2010-06-13 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: 2010-06-12 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: 2010-06-12 10:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-15 02:05:05 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2010-06-14 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: 2010-06-13 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: 2010-06-12 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: 2010-06-12 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: 2010-06-12 05:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-15 05:20:22 ```Bugs item #3014845, was opened at 2010-06-11 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 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 ---------------------------------------------------------------------- >Comment By: Robert Dodier (robert_dodier) Date: 2010-06-14 23:20 Message: 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. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-14 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: 2010-06-13 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: 2010-06-12 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: 2010-06-12 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: 2010-06-12 03:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```
 [Maxima-bugs] [ maxima-Bugs-3014845 ] sin(1e22) is wrong From: SourceForge.net - 2010-06-30 02:20:05 ```Bugs item #3014845, was opened at 2010-06-11 14:10 Message generated for change (Settings changed) made by sf-robot 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 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 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-06-30 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: 2010-06-15 05:20 Message: 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. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-15 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: 2010-06-13 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: 2010-06-13 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: 2010-06-12 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: 2010-06-12 09:30 Message: (%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 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2010-06-11 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: 2010-06-11 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 ```