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*: Brad Lucier <lucier at math dot purdue dot edu>*To*: gcc at gcc dot gnu dot org*Cc*: lucier at math dot purdue dot edu (Brad Lucier)*Date*: Fri, 18 Oct 2002 17:25:26 -0500 (EST)*Subject*: Re: real.c implementation

(Sorry, this wasn't cc'ed correctly to the gcc list when I replied to Richard.) > 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

**Follow-Ups**:**Re: real.c implementation***From:*Richard Henderson

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

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