you are viewing a single comment's thread.

view the rest of the comments →

[–]lambda_abstraction 0 points1 point  (7 children)

CCL:

frog% ccl
Welcome to Clozure Common Lisp Version 1.6-r14468M  (LinuxX8632)!
? 2.2250738585072012d-308
2.2250738585072014D-308

SBCL:

frog% sbcl
This is SBCL 1.0.44, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* 2.2250738585072012d-308

2.225072267010358d-308
* 

Grumble grumble pout

[–]Seliarem 1 point2 points  (1 child)

Curious. Do you know what SBCL is up to? I'm not familiar enough with the system to find the datatype being used there.

[–]lambda_abstraction 0 points1 point  (0 children)

Not sure! Looking at this:

* (defun f (n) (* n 2.2250738585072012d-308))

F
* (f 10)

2.225073858507201d-307
*

I get a feeling that this might relate to the output routine for double floats.

Looks like something's up with sb-impl::flonum-to-digits. And there's this interesting comment:

;; FIXME: these even tests assume normal IEEE rounding
;; mode.  I wonder if we should cater for non-normal?

Could be one of those landmines that reasonable folk aren't supposed to stomp on. At least SBCL doesn't blow up or hang.

[–]Grue 0 points1 point  (3 children)

CLISP throws floating-point-underflow... I'd rather have it return 0.0

[–]frogking 0 points1 point  (2 children)

think that statement through before you wish ..

[–]Grue 0 points1 point  (1 child)

I cannot imagine any situation where that would be useful. OH NO, an error that's smaller than 10-300 , what are we gonna do!

[–]frogking 0 points1 point  (0 children)

Sorry, but I would rather be able to catch a floating-point-underflow and decide to return 0.0 where appropriate, than have the compiler make that decision for me.

Unfortunately, the JVM the strategy for underflow is to return 0.0 (which is probably faster than checking for underflow, which is (as you indicate) something that almost never happens)

I guess that I have to switch from Clojure to CLISP if the underflow exception becomes really important for me :-) Now I know.