This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Henderson <rth at redhat dot com>*To*: Brad Lucier <lucier at math dot purdue dot edu>*Cc*: gcc at gcc dot gnu dot org*Date*: Fri, 18 Oct 2002 11:35:11 -0700*Subject*: Re: real.c implementation*References*: <200210171901.g9HJ15b19315@banach.math.purdue.edu>

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~

**Follow-Ups**:**Re: real.c implementation***From:*Brad Lucier

**Re: real.c implementation***From:*Brad Lucier

**References**:**real.c implementation***From:*Brad Lucier

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |