[Gcl-devel] Re: [Maxima] Bugs in gcl cause maxima build failures

I'm not sure what the background of this is, but in any IEEE FP
system with single precision,
I think you would get the same answers as for Allegro CL
on a Pentium 3...

(setf r least-positive-normalized-single-float)


1.1754944e-38

  (integer-decode-float r)
8388608
-149
1

so r  is  (* 8388608 (expt 2 149))


Does this help?
RJF

Raymond Toy wrote:

>>>>>>"Camm" == Camm Maguire <camm@enhanced.com> writes:
>>>>>>
> 
>     Camm> Greetings!
>     Camm> Raymond Toy <toy@rtp.ericsson.se> writes:
> 
>     >> >>>>> "Camm" == Camm Maguire <camm@enhanced.com> writes:
>     >> 
>     Camm> Please keep the gcl-list abreast of these hacks!  Probably all need to
>     Camm> find there way into gcl at some point.
>     >> 
>     >> With your latest changes, I don't really think there is a need for
>     >> this anymore, after you fix the least-positive-normalized-single-float
>     >> issue. :-)
>     >> 
> 
>     Camm> OK, this is now set to the unnormalized result.  I think that's right
>     Camm> from the spec.
> 
> At least for sparc and x86 which implement IEEE FP arithmetic, I don't
> think this is right.  The CLHS says the normalized float must be a
> normalized float.  If you make it the unnormalized one, then you're
> wrong.  And the sparc and x86 have unnormalized numbers.
> 
> For the most part, it probably doesn't matter, but some numerical
> algorithms expect them to be right.
> 
> I can help you get the right values, but I don't know how to tell gcl
> to get the right values.
> 
> Ray
> 
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>