gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: [Maxima] Re: Epsilon calculation


From: Raymond Toy
Subject: [Gcl-devel] Re: [Maxima] Re: Epsilon calculation
Date: 18 Oct 2002 16:21:44 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.5 (brussels sprouts)

>>>>> "Stavros" == Stavros Macrakis <address@hidden> writes:

    Stavros> Raymond--
    Stavros> I understand your theory, but I don't think it's correct.

    Stavros> Here's my understanding of IEEE floating point.  Suppose we're 
working
    Stavros> with a 5-bit stored mantissa and an 8-bit register mantissa.  When 
we
    Stavros> add .xxxxx and .00010000, the register result is .xxxxx100, which 
should
    Stavros> be rounded according to the 'even' rule.  Now what if we add 
.xxxxx and
    Stavros> .00010001?  Well, if there were no sticky bit, we would still get
    Stavros> .xxxxx100 in the register (since the final 1 has been shifted off),
    Stavros> which again would round to even when stored.  But if we have a 
sticky
    Stavros> bit (which remembers if anything non-zero has been shifted off), 
then
    Stavros> the register sum is .xxxxx101.  When we store .xxxxx101, we need to
    Stavros> round to five bits, and since 101 is greater than 100, we round 
up.  So
    Stavros> we shouldn't be losing the round-up quality when storing.  After 
all, it
    Stavros> would be a pity if despite the elaborate IEEE machinery, you 
couldn't
    Stavros> get a simple sum of two floats to round correctly except in 
intermediate
    Stavros> register results....

    Stavros> Or have I gotten something wrong here?

I think I was wrong.  Your reasoning looks good and I think this is
what happens if the intermediate results are stored.  If the compiler
decided to keep everything in registers, things might be different.
You didn't say what FMEM did and whether it was in the same file or
not.

    Stavros> Anyway, your theory does not explain the Lisp facts.  How is it 
that
    Stavros> Emacs Lisp and GCL manage to round their results correctly -- 
remember,
    Stavros> they're written in C, too -- but native C does not?

Because they always store the results away in memory after each basic
operation?  I'm guessing.  I don't really know.  I suppose you could
look at the C file that gcl produces to see what it's doing.

All I can say is that since the results you get are different, they
must be doing something different.  I just don't know exactly what
that might be.

Ray




reply via email to

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