Menu
▾
▴
[Maxima-bugs] [ maxima-Bugs-1787111 ] Floating point imprecission
|
From: SourceForge.net <no...@so...> - 2007-09-10 15:32:05
|
Bugs item #1787111, was opened at 2007-09-03 10:04 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&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: Problem not in Maxima Group: None Status: Pending Resolution: Wont Fix Priority: 5 Private: No Submitted By: Abel Pascual (abelpascual) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point imprecission Initial Comment: I don't understand why Maxima rounds down the number... I'm currently running Ubuntu 7.04. Maxima 5.13.0 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) 4.6*10^8; (%o1) 4.5999999999999994E+8 ---------------------------------------------------------------------- >Comment By: Raymond Toy (rtoy) Date: 2007-09-10 11:31 Message: Logged In: YES user_id=28849 Originator: NO Aargh! I completely misread the problem. This whole discussion has been about 4.6e8. But the original problem is 4.6*10^8, which is completely different. 4.6 isn't exactly representable as a float The printed result is, as best as I can tell, the correct answer. However, the issue with clisp printing 4.6e8 incorrectly is still valid. Same with the bug in gcl. Perhaps we should just leave exploden as is. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2007-09-08 15:23 Message: Logged In: YES user_id=501686 Originator: NO Ray, it's OK by me if you want to modify EXPLODEN to treat fpprintprec = 0 as a special case. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-08 14:36 Message: Logged In: YES user_id=28849 Originator: NO There is one thing we could do: If fpprintprec is 0, we want to print everything, so in that case ,we might use ~a. If fpprintprec is something else, we use ~e. This will probablly fix the immediate issue. I assume most people leave fpprintprec defaulted. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2007-09-07 20:32 Message: Logged In: YES user_id=501686 Originator: NO Reported the bug (format nil "~ve" 21 46d7) => 4.5999999999999996d+8 as SF bug report # 1790496 for Clisp. http://sourceforge.net/tracker/index.php?func=detail&aid=1790496&group_id=1355&atid=101355 I think we can close this Maxima bug report now since both of problems observed are problems in Lisp implementations. Marking this report as "won't fix" and "pending" (to be closed automatically in 2 weeks) accordingly. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2007-09-07 10:51 Message: Logged In: YES user_id=501686 Originator: NO Ray, I think you are correct on both counts: changing e to a or d shouldn't help, the format indicator should remain e; and the Clisp output in this case (format nil "~ve" 21 46d7) indicates a bug in Clisp. You or I can report the Clisp bug, whoever gets to it first, and then we can close this report, I think. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-06 23:22 Message: Logged In: YES user_id=28849 Originator: NO I'm mistaken. Using ~a won't work (which implies ~d won't work either). Consider if fpprintprec is 2. Then (format t "~7a" 1.2345678d9) -> 1.2345678d9 But (format t "~7e" 1.2345678d9) -> 1.23d8 We need to do something else. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-06 22:56 Message: Logged In: YES user_id=28849 Originator: NO We should probably file a bug report for clisp for item 2. Changing ~e to ~d is ok, but ~d is really ~a, so we should just use ~a. There is a difference, however. ~e pads numbers on the left and ~a pads on the right.t. DDoDont' know if that matters or not. In addition, cmucl has a known bug that ~e prints numbers differently from ~a (princ). ~a is more accurate. ---------------------------------------------------------------------- Comment By: Robert Dodier (robert_dodier) Date: 2007-09-06 22:06 Message: Logged In: YES user_id=501686 Originator: NO (1) I've reported GCL's failure to parse 4.6e8 correctly to the GCL bug tracker as # 20992. https://savannah.gnu.org/bugs/index.php?20992 So as for this 4.6e8 in Maxima + GCL, we can close it because the problem is not in Maxima. (2) About Clisp printing 46e7 as 4.5999999999999996E+8, it appears that Clisp is interpreting "~ve" to indicate a coercion to single-float before formatting it. Changing the "~ve" to "~vd" in EXPLODEN in src/commac.lisp appears to tell Clisp to format 46e7 as 4.6E8. SBCL and GCL are happy with "~vd". Leaving this report open to gather comments on item (2). If nobody is opposed, I'll modify EXPLODEN as described above. ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-05 10:20 Message: Logged In: YES user_id=28849 Originator: NO Good question. I wasn't sure, so I checked the code. Look at make-number and readlist in nparse.lisp. If the number is not a bigfloat, readlist is called, which basically calls Lisp read-from-string to read "4.6e8". So the result depends on the underlying Lisp. All Lisps should say (floor 4.6d8) is 46000000 and 0.0d0. Clisp and cmucl do. gcl does not. We could implement our own reader. However, for a bigfloat, maxima sees 4.6, converts it to 46/10 and then multiplies by 10^8 to get a rational number. This is then converted to a bigfloat. I think 21 is because we want upto 16 digits printed, and the 5 is to make sure there's space to print the exponent marker, a sign, and the exponent itself (3 digits). If 16 is used, the number of significant digits would be too small. I think it is a bug in gcl and clisp that it prints something other than 4.6d8. ---------------------------------------------------------------------- Comment By: Andrej Vodopivec (andrejv) Date: 2007-09-05 03:27 Message: Logged In: YES user_id=1179910 Originator: NO I don't think 4.6*10^8 is parsed as one number. First 4.6 is parsed, then 10^8, and then they are multiplied. To enter 4.6e8 you should enter it as 4.6e8. OTOH, 4.6e8 is not printed correctly on clisp and gcl. The reason is that floats are printed with (format nil "~ve" 21 4.6e8) I think 21 is arbitrarily chosen - if it was 19, all lisps print it correctly, but then maybe some other example would be printed incorrectly. Why don't we just use (format nil "~ve" 16 4.6e8). Andrej ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-04 14:47 Message: Logged In: YES user_id=28849 Originator: NO The issues you see with GCL and CLISP are somewhat related, but outside the scope of this bug. If you want to discuss it further, I'd be happy to. Just not here. Please mail me directly or, even better, use the maxima mailing list. ---------------------------------------------------------------------- Comment By: Abel Pascual (abelpascual) Date: 2007-09-04 13:50 Message: Logged In: YES user_id=1881850 Originator: YES I don't know if there is any relation, but in GCL I'm having the same issue: >(* 4.6 (expt 10 8)) 4.5999999999999994E8 But otherwise in CLISP this is not happening: [1]> (* 4.6 (expt 10 8)) 4.6E8 ---------------------------------------------------------------------- Comment By: Raymond Toy (rtoy) Date: 2007-09-04 13:11 Message: Logged In: YES user_id=28849 Originator: NO Actually 4.6e8 is an integer: 460000000. This should be exactly representable as a double-float. I think it is an error that maxima prints something else out. Reopening this bug. ---------------------------------------------------------------------- Comment By: Abel Pascual (abelpascual) Date: 2007-09-03 17:37 Message: Logged In: YES user_id=1881850 Originator: YES Ok, sorry for my mistake, and thanks for your explanation... ---------------------------------------------------------------------- Comment By: Harald Geyer (hgeyer) Date: 2007-09-03 16:12 Message: Logged In: YES user_id=929336 Originator: NO Hi Abel! Thanks for you interest in maxima. The behaviour, that you see is a basic property of fixed precision floating point numbers (maxima acutally is using maschine doubles IIRC): The number 4.6e8 is not representable exactly in base 2 arithmetic, thus maxima rounds the number to the next number that can be represented as double float. If you need higher precision, you can use bfloats: 4.6b8 If you want exact numbers, you can use rational arithmetic. In this case enter the number as: 46*10^7 (that is: without decimal dot) If you still have questions, you might ask on the Mailinglist. I'm closing your bug report now, because this is nothing we can fix in maxima. ---------------------------------------------------------------------- Comment By: Abel Pascual (abelpascual) Date: 2007-09-03 10:06 Message: Logged In: YES user_id=1881850 Originator: YES Greetings ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1787111&group_id=4933 |