This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: real.c implementation
- From: Brad Lucier <lucier at math dot purdue dot edu>
- To: rth at redhat dot com (Richard Henderson)
- Cc: lucier at math dot purdue dot edu (Brad Lucier), gcc at gnu dot org
- Date: Fri, 18 Oct 2002 14:22:49 -0500 (EST)
- Subject: Re: real.c implementation
> My understanding is that the guard bit is supposed to be the correct
> value of the .5ulp bit, and the sticky bit is supposed to be set if
> the result is not exact at the .5ulp position.
>
> Thus one should get correct results for any target precision if the
> following rules are observed:
>
> * The intermediate representation has _at least_ two more
> bits than the target format. Obviously.
>
> * The bit 0 of the intermediate precision is sticky; all
> other bits contain the proper values.
>
> * When rounding to the target format, the guard bit is
> read from the target's lsb-1, and the sticky bit is the
> sum of all bits between lsb-2 and 0.
>
> Perhaps I'm being naieve. If this is incorrect, stop me now.
> An explanation of why this is wrong would also be appreciated.
This may very well be correct; I did not really understand what your
goal was before by reading the code. I'll think about it more this
weekend. Perhaps this is why paranoia is passing for +,-,*,/.
> If this is correct, do we get better results for decimal<->binary
> conversion if all computations are correctly rounded for, say,
> a 158-bit intermediate representation?
I don't know. What I do know is that having correct intermediate results
to 2k+2 bits after doing all the conversion stuff does guarantee the
correct target result to k bits. Something similar will come up with
sqrt.
> If so, does this allow us to get correct results for the worst-case
> 113-bit target format with a 126-bit intermediate format? I.e. can
> we remove the extra word added the other week? I'm guessing not,
> but I don't actually know.
The problem is that unless you want to do some algorithmic tricks (along
the lines I gave in my e-mail) the easiest and safest way to compute
decimal<->binary conversions and sqrt is to calculate results to > 2k+2 bits
and then round to k bits. I'll try to come up with some tests to see
if 113-bit decimal<->binary conversion works.
Brad