#1264 Floating point imprecission

closed
nobody
5
2007-09-22
2007-09-03
No

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

Discussion

<< < 1 2 3 > >> (Page 2 of 3)
  • Robert Dodier

    Robert Dodier - 2007-09-07

    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.

     
  • Raymond Toy

    Raymond Toy - 2007-09-07

    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.

     
  • Raymond Toy

    Raymond Toy - 2007-09-07

    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.

     
  • Robert Dodier

    Robert Dodier - 2007-09-07

    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.

     
  • Robert Dodier

    Robert Dodier - 2007-09-08

    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.

     
  • Robert Dodier

    Robert Dodier - 2007-09-08
    • status: open --> pending
    • labels: 887077 --> Problem not in Maxima
     
  • Raymond Toy

    Raymond Toy - 2007-09-08

    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.

     
  • Robert Dodier

    Robert Dodier - 2007-09-08

    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.

     
  • Raymond Toy

    Raymond Toy - 2007-09-10

    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.

     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

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

     
<< < 1 2 3 > >> (Page 2 of 3)

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks