[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Fateman
Subject: Re: [Gcl-devel] Re: [Maxima] Bugs in gcl cause maxima build failures
Date: Tue, 21 May 2002 15:07:22 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

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)


 (integer-decode-float r)

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

Does this help?

Raymond Toy wrote:

"Camm" == Camm Maguire <address@hidden> writes:

    Camm> Greetings!
    Camm> Raymond Toy <address@hidden> writes:

    >> >>>>> "Camm" == Camm Maguire <address@hidden> 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.


Maxima mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]