[clisp-list] Re: short float coercion

[Sam S. <sd...@gn...>]

> * Christophe Rhodes <pf...@pn....hx> [2003-10-22 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 SINGLE-FLOAT a number which is smaller than
LEAST-POSITIVE-SINGLE-FLOAT.  This means underflow, right?

>   [1]> (lisp-implementation-version)
>   "2.31 (released 2003-09-01) (built 3275820501) (memory 3275821131)"
>   [2]> least-positive-short-float
>   2.93874s-39
>   [3]> (coerce * 'single-float)
>
>   *** - floating point underflow
>   1. Break [4]> 
>   [5]> (ext:without-package-lock ("SYSTEM")
>     (setf system::*inhibit-floating-point-underflow* t))
>   T

see <http://clisp.cons.org/impnotes/num-dict.html#no-underflow>

>   [6]> least-positive-short-float
>   2.93874s-39
>   [7]> (coerce * 'single-float)
>   0.0

I am confused.
I have no idea what is going on.

(/ (float least-positive-short-float 1d0)
   (float least-positive-single-float 1d0))
==> 0.25

(/ (float most-positive-short-float 1d0)
   (float most-positive-single-float 1d0))
==> 0.5

(/ (float short-float-epsilon 1d0) (float single-float-epsilon 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.