You are invited to Log in or Register a free Frihost Account!

# square root of 4 minus 2

Arrogant
square root of 4 minus 2, no doubt gives zero
Try it in Windows calculator
cybersa

But it gives correct answer,when trying square root of 4 minus 1.
lkglacier
 Arrogant wrote: square root of 4 minus 2, no doubt gives zero Try it in Windows calculator
Of course, it depends on the order of operations. (square root of 4) -2=0

 cybersa wrote: Answer:-1.068281969439142e-19 But it gives correct answer,when trying square root of 4 minus 1.

For this, you're doing: {square root of (4-2)}, which is the square root of two. Also, there are two answers to this equation, one positive, one negative. Not just a negative.
SonLight
Agreed, the statement in the OP is somewhat ambiguous, but cybersa apparently interpreted it as I would expect most people would, as ( sqrt(4) ) - 2. The answer given is apparently due to a roundoff error, smaller than epsilon for "most epsilons".

Other possible interpretations are that sqrt(4) = -2, in which case the answer would be -4, or sqrt(4-2), about 1.414.

It would be interesting to know exactly which calculator program(s) give(s) the roundoff error. A well-programmed application, with standard-compliant floating-point hardware, should have gotten exactly zero. It might be possible to set some fp flags on the computer which would cause a roundoff error, but it seems unlikely with such a simple problem.

For the record my system, 64-bit intel, Linux Maya 13 with standard calculator got zero when I typed in sqrt(symbol) 4 = - 2 =, but not before I mistyped it at 4 sqrt(symbol) - 2 = and found out it didn't work that way (it gave me about 5.65i, don't remember now if that was plus or minus).

Well, -1.068281969439142e-19 is pretty close to zero.
Arrogant
@lkglacier - you interpreted it the other way

The windows calc doesnt give an exact zero which is the correct answer
And yes it is a rounding off error
kelseymh
 SonLight wrote: It would be interesting to know exactly which calculator program(s) give(s) the roundoff error. A well-programmed application, with standard-compliant floating-point hardware, should have gotten exactly zero. It might be possible to set some fp flags on the computer which would cause a roundoff error, but it seems unlikely with such a simple problem.

To first order, I agree with you, but the underlying problem is rather subtle. It depends on exactly how the SQRT() function has been implemented. Some systems use lookup tables for small-integer arguments, with interpolation to handle fractional parts. In that case, I would certainly expect sqrt(4) to return exactly 2.

Other systems might reuse the tabulated versions of exp() and ln(), and implement sqrt(x) as exp(ln(x)/2). In that case, it's quite possible that the nested functions could end up returning 2-1e-19 or so (i.e., a difference from 2.0 in the final bit).

Ultimately, it boils down to where the system programmer tried to optimize CPU usage versus preserve maximum accuracy.
Arrogant