Re: real.c implementation

[Brad Lucier <lucier at math dot purdue dot edu>]

> 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 seems to be correct.  I also think it's a very clever idea.

It may give more confidence if you set up an artificial arithmetic
that has 158-bit accuracy to be tested by paranoia.

> 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?
> 
> 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.

I don't know the answers to these questions.  Steele and White, Clinger,
and David Gay (his code is at netlib.org) worked out provably correct methods
to do exact binary<->decimal conversion.  All of them rely on extra-precision
integer arithmetic for some cases.  I don't know if Moshier's code has this
property, and I don't know if it benefits from extra intermediate precision.

Is exact conversion a goal for gcc?

Brad