Re: real.c implementation

[Richard Henderson <rth@redhat.com>]

On Thu, Oct 17, 2002 at 02:01:05PM -0500, Brad Lucier wrote:
> 1.	Implement algorithms where the working precision is the target
> 	precision plus two bits (guard and sticky) and apply whatever
> 	tricks there are in the literature (Tuckerman's test for 0.5ulp
> 	accuracy of sqrt, Guy Steele's and Will Clinger's algorithms for
> 	exact decimal<->binary conversions) to get the correct answers.
> 
> 2.	Implement somewhat inaccurate algorithms in an intermediate precision
> 	so large that conversion to the target precision gives correct
> 	results.
> 
> I believe that real.c adopts the second approach.

It was not *intended* that real.c adopt the second approach.

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.

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.


r~