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]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]