Is My Version Of Turing Broken?

[Amit]

I'm using Turing Version 4.1 . I'm in the process of making a top down shooter, and I'm getting an error - Overflow to the round function. After some debugging, I find that when my version of Turing calculates "cosd (90)" it doesn't equal to 0 like it should, but rather 1.22464e-16. Is this a known bug, or is my version of Turing just messed?

Edit: I just tried "cos (Math.PI / 2)" and I get the same answer, 1.22464e-16.

[Laplace's Demon]

The problem occurs on my machine as well.

I believe the problem you're seeing is due simply to the fact that the PC is not designed to perform precision math, it's called a floating point error.

see the wikipedia article:

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

[Amit]

So it's not Turing, it's my computer?

[Euphoracle]

No; It's working as intended.

[DemonWasp]

Euphoracle's right. Let me explain:

Floating point numbers are not stored in decimal on your computer. They are stored in a bizarre binary format that attempts to be as accurate as possible over a large range of numbers using minimal storage. For the most part, it's very very good at this; most numbers are represented quite accurately. Only very small (close to 0) or very large numbers (10^20, etc) have any appreciable inaccuracy.

However, there are some downsides. Depending on the arithmetic used, you may arrive at slightly different results (due to errors caused by rounding or the inability of the float to store a number accurate enough). This can often cause minute errors, like the one you're experiencing. Generally, this isn't a huge concern; when are you ever going to notice that a number about 1*10^-16 isn't exactly zero?

When circumstances arise where this could be a real problem (you're writing the software for the Space Shuttle, you're writing a scientific simulation of climate change or theoretical physics, etc), people tend to use a much larger data type to store exactly as much precision as they need. This usually consumes 10-100 times as much memory as a simple real number (properly called a floating-point number, or "float"). Since the float type is generally "close enough", there's usually no point in using anything more complex.

[Amit]

Ok, I understand now. I guess it's always been like that, and I just never noticed.

[saltpro15]

just a question, if this program was made in C++ would it make it more accurate?

[Laplace's Demon]

no, the problem is due the machine hardware not the programming language used, so simply translating the program into C++ would not make a difference.

I'm not sure if this would completely solve your problem, but when I ran into the problem of an undefined function (dividing by 0) I simply created a special case for this, in the form of an if statement above the regular math, so that if the number you are using will cause a problem (90, 270) you simply have a special case which sets the answer to 0 automatically.

[saltpro15]

clever, thanks for answering my question too

[Insectoid]

Remember, saltpro. It's the way the computer stores floats, not the program that handles them. Every language will run into this.

[chrisbrown]

You could just write wrappers for the trig functions, checking if the passed argument is equal to 0 mod 2*Pi, Pi/2 mod 2*Pi, etc and return the integer result. It's not a big deal, but if you were, say, making a mathematical expression evaluator, you would definitely want cosd (90) to be zero, etc...