## [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat

 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-23 16:04:54 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```

 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-22 16:34:06 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Tracker Item Submitted) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-22 20:07:06 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-23 09:12:07 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- >Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-23 16:04:54 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-24 06:22:14 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by chrisrein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- >Comment By: christoph reineke (chrisrein) Date: 2012-07-23 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-24 15:52:14 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-07-24 08:52 Message: There's a misunderstanding on how maxima works. Maxima parses 1.23456789123456789123456789123456789 as an IEEE double precision float, essentially independent of how many extra digits you write out. This number is the exact rational (given by rationalize) 5559999494927579/4503599627370496. When this is converted to a bfloat with a given value of fpprec, the ratio is essentially multiplied by a power of two. When it's printed, these extra digits are produced. If you really want a bfloat with the given digits, use 1.2345...b0. Whether maxima should work this way or not is a different question. That would probably be better discussed on the maxima mailing list as a feature request. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-07-31 17:03:45 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: Invalid Priority: 5 Private: No Submitted By: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2012-07-31 10:03 Message: Marking as pending/invalid. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-24 08:52 Message: There's a misunderstanding on how maxima works. Maxima parses 1.23456789123456789123456789123456789 as an IEEE double precision float, essentially independent of how many extra digits you write out. This number is the exact rational (given by rationalize) 5559999494927579/4503599627370496. When this is converted to a bfloat with a given value of fpprec, the ratio is essentially multiplied by a power of two. When it's printed, these extra digits are produced. If you really want a bfloat with the given digits, use 1.2345...b0. Whether maxima should work this way or not is a different question. That would probably be better discussed on the maxima mailing list as a feature request. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```
 [Maxima-bugs] [ maxima-Bugs-3547315 ] Problems with bfloat From: SourceForge.net - 2012-08-13 17:58:04 ```Bugs item #3547315, was opened at 2012-07-22 09:34 Message generated for change (Settings changed) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&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: Invalid Priority: 5 Private: No Submitted By: christoph reineke (chrisrein) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with bfloat Initial Comment: Enter: (%i2) fpprec:30; (%o2) 30 (%i3) bfloat((45.12*34.78923)^2); (%o3) 2.46392687692829128354787826538b6 2.46392687692829131776b6 is the correct value. build_info("5.27.0","2012-05-08 11:27:57","i686-pc-mingw32","GNU Common Lisp (GCL)","GCL 2.6.8") Regards Chris ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-31 10:03 Message: Marking as pending/invalid. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-24 08:52 Message: There's a misunderstanding on how maxima works. Maxima parses 1.23456789123456789123456789123456789 as an IEEE double precision float, essentially independent of how many extra digits you write out. This number is the exact rational (given by rationalize) 5559999494927579/4503599627370496. When this is converted to a bfloat with a given value of fpprec, the ratio is essentially multiplied by a power of two. When it's printed, these extra digits are produced. If you really want a bfloat with the given digits, use 1.2345...b0. Whether maxima should work this way or not is a different question. That would probably be better discussed on the maxima mailing list as a feature request. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 23:22 Message: Thanks for your comment, but I’m still convinced that there is a bug somewhere. Please take a look at the following numbers: (%i1) bfloat(1.23456789123456789123456789123456789),fpprec:20; (%o1) 1.2345678912345678935b0 (%i2) bfloat(1.23456789123456789123456789123456789),fpprec:30; (%o2) 1.23456789123456789347699213977b0 (%i3) bfloat(1.23456789123456789123456789123456789),fpprec:40; (%o3) 1.23456789123456789347699213976738974452b0 (%i4) bfloat(1.23456789123456789123456789123456789),fpprec:50; (%o4) 1.2345678912345678934769921397673897445201873779297b0 The trouble begins after the second 9 with the sequence …3476…, which should be…1234… As you see, it doesn’t matter if fpprec=20,30,40 or 50, the precision is always the same! That ain’t got nothing to do with our binary system, fpprec doesn’t work properly. Maxima cannot handle long decimals (more than 17/18 places after the decimal point) and that’s a bug. The function fpprec seems to work if you have to compute real numbers like sqrt(2) or log(3). It never works if you enter long decimals. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-23 09:04 Message: When you write 45.12, maxima converts that to a floating point number. But 45.12 cannot be represented exactly in floating point. Same for 34.78923. (You can see what the actual value is by using rationalize(45.12), which is close t o 4512/100, but not the same.) So maxima uses floating-point arithmetic to compute (45.12*34.78923)^2. Then that floating point number is converted to a bfloat, giving the result that maxima produces. If you want exact results, use exact rational arithmetic: bfloat((4512/100 * 3478923/100000)^2); 2.46392687692829131776b6 Of course, even that is an approximation because the exact result is 240617859075028449/97656250000, and that can't be represented exactly as a bfloat. ---------------------------------------------------------------------- Comment By: christoph reineke (chrisrein) Date: 2012-07-23 02:12 Message: Sorry, but I don’t understand you. Which value? (45.12*34.78923)^2=2.46392687692829131776b6=the correct value. Since I expect that the correct value has more than 16 digits after the comma, I use bfloat and fpprec=30. I quote from the documentation: “bfloat (expr) Function Converts all numbers and functions of numbers in expr to bigfloat numbers. The number of significant digits in the resulting bigfloats is specified by the global variable fpprec.” …all numbers…!! Now Maxima returns 30 digits, but the result is wrong. That’s all. Which simplifier? If a CAS computes a simple multiplication each digit of the displayed floating point number should be correct (apart from the last), no matter how many digits the user wants. Even if I erroneously “simplify” something, Maxima should never display a wrong result. That’s my opinion. How do I get the correct result? Thanks for your help! ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2012-07-22 13:07 Message: Can you explain why you think the value you give is the correct value? Consider this transcript: (%i1) fpprec:30; (%o1) 30 (%i2) trace(bfloat); (%o2) [bfloat] (%i3) bfloat((45.12*34.78923)^2); 1 Enter bfloat [2463926.876928291] 1 Exit bfloat 2.46392687692829128354787826538b6 (%o3) 2.46392687692829128354787826538b6 Thus, the simplifier has simplified the float expression before bfloat gets a chance to look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3547315&group_id=4933 ```