Re: comare tow int

richyjsm@xxxxxxxxx writes:

On May 5, 4:06 am, CBFalconer <cbfalco...@xxxxxxxxx> wrote:
Ben Bacarisse wrote:
CBFalconer <cbfalco...@xxxxxxxxx> writes:
The point is that the slight excess makes adding 0.5 (above) put
the result above the value of x, so it could return x+1 (in some
cases).  Some would consider this an error.  I think it will
require large x.

So you were serious.  Right.  How big an x do you think you need so
that sqrt of (double)x * x is out by > 0.5?  I don't think it is
possible on any sane implementation.

Lets assume the FP has a 52 bit significand, and a 12 bit
exponent.  It normalizes, so it can save one bit of the 52 for the
sign.  If x is a 27 bit value (just a long) the square won't notice
an error of 1.  Now adjust that input value so the error, after
rounding (which any decent FP system will do), is positive.  Take
the root.  If that root is 0.5 larger than the original x, adding
0.5 will give an error of one.

Actually, most well-designed FP systems should have the property
that sqrt(x*x) == fabs(x) for *any* floating-point number x,
provided only that x*x neither overflows nor underflows.

Yes, I agree. However (just to be clear) despite the initial claim
about sqrt and then the later claim about the square, the original
problem CBF is talking about is in neither (as far as I can see). It
is simply that, for sufficiently large ints, (int)(double)x != x so,
since x can't be represented exactly, neither can the square and so
the sqrt will be "wrong" no matter how good the function.

--
Ben.
.

Relevant Pages
Loading