floating point problems

[Jordan Abel]

Actually, that's the problem. In the Real World, maths _is_ exact.

Except for quantum mechanics, the heisenberg uncertainty principle, etc

Gravity works to an infinity of decimals.

Just keep telling yourself that.

 

[Coos Haak]

Op Fri, 03 Feb 2006 01:10:39 GMT schreef Keith Thompson:

This is usually referred to as a "right triangle", not a "rectangular
triangle". ("rectangular" refers to a 4-sided polygon all of whose
vertices are 90 degress.)

In Dutch it's 'rechthoekige driehoek' and a 'rechte driehoek' does not
exist. So it's just the other way round here ;-)

But if a test case provides a triangle one of whose sides is merely *a
close approximatation to* sqrt(41), it's foolish to expect an exact
result.

Agreed.

Coos

 

[CBFalconer]

Op Fri, 03 Feb 2006 01:10:39 GMT schreef Keith Thompson:
.... snip ...


Agreed.

But if the expression "sqrt(41)" is never evaluated it is still
possible to make exact comparisons with other quantities, such as
"sqrt(4*4 + 5*5)". As others have pointed out in this very
thread. You just have to think a little, instead of applying the
magic crank. This involves realizing that floating point values are
inherently approximations.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Mark McIntyre]

This is usually referred to as a "right triangle",

In UK English, a right-angle triangle.
Mark McIntyre

 

[Mark McIntyre]

Actually such men as Cantor and Dedekind resolved those inexact
maths problems well over a century ago, with rigid definitions of
limits and other inexact concepts. "When, for any epsilon, we can
find an n such that ...".

You mean they used rigidly defined areas of doubt and uncertainty.

Wow, deep thought indeed.

Mark McIntyre

 

[Mark McIntyre]

Welcome to the Real World (tm), where maths is not exact.

Actually, that's the problem. In the Real World, maths _is_ exact.[/QUOTE]

Well, kinda. In the actual Real World, you have to use tools to do
maths and those tools are not exact. In the intellectual Real World,
maths is done in brains, and is therefore exact.

Pick a real world...


Mark McIntyre

 

[Christian Bau]

It is a school assignment and I have the program working except that
our programs are testing automatically by some program.

He lets us know 8 of the cases, the rest are hidden. 2 of the cases
seem impossible to implement in computers (and yes, we have to sqrt in
a distance function, and then resquare it in the actualy "figuring out"
function).

One of the cases has a triangle with a side that is of length sqrt(41),
which is irrational. So when the other function gets it and resquares
it, accuracy is lost. Yet his testing program wants an exactly
solution (no approximate one allowed for this case).

The other case has a triangle with 2 really large sides and one very
small sides. He wants us to get it within some tolerance, but i can't
seem to "keep" the information from the small side to "stick" within
the sqrt function.

I am going to email him and tell him that his cases are ridiculous (in
a nice way).

No, the test cases are not a problem. Putting a completely unnecessary
complication into the problem _is_ a problem.

There is a way around this. Your program started with integer values.
Each side of the triangle is the square root of an integer. If you
square it, the result is again an integer, except for rounding errors,
which means it is only close to an integer. Now you have to check whether

a*a + b*b - c*c == 0.0

or not. The squares should be integers; therefore the sum on the left
side should be an integer. It won't be an integer because of rounding
errors. Lets say you got a result of 0.01: You know you don't have the
exact result, because the exact result must be an integer. So you can
assume that the correct result is the nearest integer. To check whether
the correct result is zero, check whether the absolute value is less
than 1/2.

 

[Christian Bau]

But if the expression "sqrt(41)" is never evaluated it is still
possible to make exact comparisons with other quantities, such as
"sqrt(4*4 + 5*5)". As others have pointed out in this very
thread. You just have to think a little, instead of applying the
magic crank. This involves realizing that floating point values are
inherently approximations.

In the case at hand, it is guaranteed that square roots of integer
values are taken. The final result is a floating-point number which is
guaranteed to be an integer, except for rounding errors. You can find
the exact value if you can guarantee the rounding error is less than one
half.