Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Christophe Rhodes <csr21@ca...>  20031022 19:48:54

Hi, The following demonstrates, if not an outright bug, at least a suboptimality in float coercion. I understand where it's coming from, I guess, but it's quite undesireable to get 0.0 out at the end... is there any chance of this being fixed to "do what I mean"? [1]> (lispimplementationversion) "2.31 (released 20030901) (built 3275820501) (memory 3275821131)" [2]> leastpositiveshortfloat 2.93874s39 [3]> (coerce * 'singlefloat) ***  floating point underflow 1. Break [4]> [5]> (ext:withoutpackagelock ("SYSTEM") (setf system::*inhibitfloatingpointunderflow* t)) T [6]> leastpositiveshortfloat 2.93874s39 [7]> (coerce * 'singlefloat) 0.0 Cheers, Christophe  http://wwwjcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (setpprintdispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) 
From: Sam Steingold <sds@gn...>  20031022 21:05:22

> * Christophe Rhodes <pfe21@...> [20031022 17:19:01 +0100]: > > The following demonstrates, if not an outright bug, at least a > suboptimality in float coercion. I understand where it's coming from, > I guess, but it's quite undesireable to get 0.0 out at the end... is > there any chance of this being fixed to "do what I mean"? You are trying to coerce to SINGLEFLOAT a number which is smaller than LEASTPOSITIVESINGLEFLOAT. This means underflow, right? > [1]> (lispimplementationversion) > "2.31 (released 20030901) (built 3275820501) (memory 3275821131)" > [2]> leastpositiveshortfloat > 2.93874s39 > [3]> (coerce * 'singlefloat) > > ***  floating point underflow > 1. Break [4]> > [5]> (ext:withoutpackagelock ("SYSTEM") > (setf system::*inhibitfloatingpointunderflow* t)) > T see <http://clisp.cons.org/impnotes/numdict.html#nounderflow>; > [6]> leastpositiveshortfloat > 2.93874s39 > [7]> (coerce * 'singlefloat) > 0.0 I am confused. I have no idea what is going on. (/ (float leastpositiveshortfloat 1d0) (float leastpositivesinglefloat 1d0)) ==> 0.25 (/ (float mostpositiveshortfloat 1d0) (float mostpositivesinglefloat 1d0)) ==> 0.5 (/ (float shortfloatepsilon 1d0) (float singlefloatepsilon 1d0)) ==> 128 this means that even though short floats have 7 fewer bits of precision, they manage to cover _more_ of the real line (twice as much)! how could this be? I hope Bruno will bring clarity here...  Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.honestreporting.com>; Man has 2 states: hungry/angry and sate/sleepy. Catch him in transition. 
From: Raymond Toy <toy@rt...>  20031024 03:04:09

>>>>> "Sam" == Sam Steingold <sds@...> writes: >> * Christophe Rhodes <pfe21@...> [20031022 17:19:01 +0100]: >> >> The following demonstrates, if not an outright bug, at least a >> suboptimality in float coercion. I understand where it's coming from, >> I guess, but it's quite undesireable to get 0.0 out at the end... is >> there any chance of this being fixed to "do what I mean"? Sam> You are trying to coerce to SINGLEFLOAT a number which is smaller than Sam> LEASTPOSITIVESINGLEFLOAT. This means underflow, right? Yes, I think so. I notice that leastpositivesinglefloat and leastpositivenormalizedsinglefloat are the same value, and corresponds to the normalized value on IEEE FP. Is that intended? You don't support unnormalized floats? Ray 
From: Bruno Haible <bruno@cl...>  20031024 12:19:10

Raymond Toy wrote: > I notice that leastpositivesinglefloat and > leastpositivenormalizedsinglefloat are the same value, and > corresponds to the normalized value on IEEE FP. Is that intended? > You don't support unnormalized floats? Right. CLISP by design returns the same floating point results on all platforms (to reduce portability problems). Therefore it has a floatingpoint emulation built in for platforms that don't support IEEE FP. And I didn't spend time on unnormalized floats and various types of NaNs that are not generally useful:  When you got a NaN in your program, your program is broken. As a developer, one then ususally spends time determining where the NaN came from. It's better to signal an error in this case.  When you got unnormalized floats in your program, your results will have a greatly reduced accuracy anyway. Since clisp has the means to cope with this  LONGFLOATs of variable precision  it doesn't need to support unnormalized floats. Bruno 
From: Bruno Haible <bruno@cl...>  20031024 13:16:18

Sam Steingold wrote: > (/ (float leastpositiveshortfloat 1d0) > (float leastpositivesinglefloat 1d0)) > ==> 0.25 > > (/ (float mostpositiveshortfloat 1d0) > (float mostpositivesinglefloat 1d0)) > ==> 0.5 > > (/ (float shortfloatepsilon 1d0) (float singlefloatepsilon 1d0)) > ==> 128 > > this means that even though short floats have 7 fewer bits of > precision, they manage to cover _more_ of the real line (twice as much)! > > how could this be? The SINGLEFLOAT inmemory format in clisp follows IEEE 754, which reserves one particular exponent value for Infinitys and NaNs. Since clisp doesn't support these beasts, neither in SINGLEFLOAT nor in SHORTFLOAT, it means that one of the 255 possible exponents in the SINGLEFLOAT format is wasted. The SHORTFLOAT format is specific to clisp, not adhering to any standard, and therefore doesn't need to waste one of the 255 possible exponents. Bruno 
From: Christophe Rhodes <csr21@ca...>  20031024 13:35:33

Sam Steingold <sds@...> writes: >> * Christophe Rhodes <pfe21@...> [20031022 17:19:01 +0100]: >> >> The following demonstrates, if not an outright bug, at least a >> suboptimality in float coercion. I understand where it's coming from, >> I guess, but it's quite undesireable to get 0.0 out at the end... is >> there any chance of this being fixed to "do what I mean"? > > You are trying to coerce to SINGLEFLOAT a number which is smaller than > LEASTPOSITIVESINGLEFLOAT. This means underflow, right? I'm so sorry  I completely missed this. You're quite right, in pure Common Lisp terms. I was expecting that leastpositivesinglefloat would be the IEEE value for the least positive single float, not just the least positive normalized single float, but there's no reason that that should be the case. (I don't know why you'd do it this way, but I'm perfectly willing to believe that there are legitimate reasons for doing so :). Cheers, Christophe  http://wwwjcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (setpprintdispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) 