#2680 1000!^0.01 gives i.nfE+6166368

None
closed
nobody
5
2016-03-14
2014-01-20
No

With maxima 5.32.1 (5.32.1-1 in Debian i386), 1000!^0.01 gives i.nfE+6166368:
Here is a transript:

$ maxima
Maxima 5.32.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.10 (a.k.a. GCL)
...
(%i1) 1000!^0.01;
(%o1) i.nfE+6166368

I noticed this bug in 5.30.0 (which gave i.nfE+142498684), and it is Debian bug #707596 (i.e http://bugs.debian.org/707596 )

No doubt 1000! overflows the floating-point range, but I think maxima should say something to that effect instead of giving a random answer.

-Sanjoy

Discussion

  • Rupert Swarbrick

    I've just written a patch that catches floating point overflows and automatically does a bfloat calculation instead when it catches one.

    I timed the testsuite before and after this change. CCL seems to be slightly faster, about 2%. CMUCL is about 3% slower; GCL is about 4% slower. The other implementations (ECL, SBCL, SCL, CLISP) seem not to have changed significantly in time. (Although ECL and CLISP don't really count because they take 3-4 times as long as the other implementations!)

    Sadly, it doesn't work on Allegro 9.0, but the other implementations seem sensibly behaved except for ECL and GCL, which I've sucessfully special-cased.

    Since it makes Maxima less confusing, and turns out not to cause a dramatic slowdown, I shall push this patch. If there's a massive performance regression I haven't spotted, we can always revert it again.

     
  • Rupert Swarbrick

    • status: open --> closed
     
  • Raymond Toy

    Raymond Toy - 2014-01-28

    I'm kind of opposed to this change. A while back, people were excited about a 5% gain on the testsuite by changing zillions of lines of code to replace one function with a CL equivalent, inline. (I was opposed to that change too, especially the way it was done.)

    I'd rather get gcl to signal an overflow error. If it turns out to be impossible, or gcl doesn't want to, then we can consider this change, but I don't see why everyone must be harmed by this change until we've investigated getting gcl to signal an overflow.

     
  • Rupert Swarbrick

    I think I understand your position but

    (1) This wasn't zillions of lines of code - it's mostly just a simple wrapper around flonum-eval

    (2) I'm pretty certain that most people would consider a 0-5% slow down a good trade off for not seeing floating point overflows any more.

    (3) Consider if history was backwards and I pushed a patch with "Wonderful news! 10% improvements in speed on some lisps, but I'm afraid some calculations will explode with floating point overflow errors occasionally". I'm pretty certain that it would be reverted post-haste...

    Anyway, yes, we can get GCL to test for floating point infinity and then punt to merror, but I think that's less helpful behaviour.

    I'll start a thread on the mailing list in a sec, with a pointer to this page.

     
  • Robert Dodier

    Robert Dodier - 2016-03-14
    • labels: --> float formatting
    • status: closed --> open
     
  • Robert Dodier

    Robert Dodier - 2016-03-14

    I'm reopening this bug report, as I've reverted the promote-float-to-bigfloat code and moved it to branch promote-float-to-bigfloat, following discussion on the mailing list a while ago. I'm planning to fix this bug by fixing the display formatting code (EXPLODEN-FORMAT-FLOAT).

     
  • Robert Dodier

    Robert Dodier - 2016-03-14
    • status: open --> closed
     
  • Robert Dodier

    Robert Dodier - 2016-03-14

    Fixed (again, in a different way) by commit [d1906eae]. Closing this report.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks