[Top][All Lists]
[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