Cos(90) <> 0?
BlitzMax Forums/BlitzMax Programming/Cos(90) <> 0?
| ||
| This is just something I'm confused about. If I get the cosine of a 90 degree angle, using Cos(90), it returns 6.1230317691118863e-17. Now, this is a tiny number, almost negligible... but why isn't the result 0? Sin(0) gives me 0.00000000000...., for example. |
| ||
| Floating point inaccuracy I'd say. |
| ||
| I think sine and cosine functions are represented by expansions of series of powers of x. These series have an infinite number of terms, only a limited number of which are reproduced in the function. For example sin(x)=x-((x^2)/6)+higher order terms.... This is fine for sin(x) near to 0, as sin(x) is roughly x near zero, so only the leading term suffices. The series approximation obviously doesn't do quite as well for cos(90). Short answer: approximation errors. See here for more info http://en.wikipedia.org/wiki/Taylor_series |
| ||
| It's such a negligibly small value that it ought not to matter, anyhow. Cheers. |
| ||
| but why isn't the result 0? It is. Floating point numbers are only accurate to seven digits. |
| ||
| It is. Floating point numbers are only accurate to seven digits Explain whyfloat(Cos(90))<>0:Float then I agree its that cos(90)<>0 by a negligable amount, and we should all know that these things happen. But saying it does = 0 is just wrong |
| ||
| The floating point representation problem must occur at some mid-point during the calculation. It cannot happen with 0, because 0 is a number which can accurately be stored as a floating point number. |
| ||
| float(Cos(90))<>0:Float then Because the computer doesn't know that floats only have 7 digits worth of accuracy. But saying it does = 0 is just wrong Oh really? In what possible scenario is 0.000000000000000061230317691118863 significantly different from 0? But saying it does = 0 is just wrong No because as I mentioned earlier, floats only have 7 digits worth of accuracy, and as it so happens, the first seven digits of 0.000000000000000061230317691118863 are 0.000000 or zero. |
| ||
| There's some numbers that you just cannot represent with floating point. Integers get away with it because you only want integer accuracy but a floating point number only *attempts* to be a `real` number, which would have to provide infinite accuracy in order to be a perfect representation. That's why people use Double's, to get the extra accuracy. The only issue really is when you try to compare one of these `almost` numbers to some specific value, like comparing what you got with 0, obviously they are not quite the same. So then, because of this *flaw* in number accuracy, you have to implement a bandaid, such as giving the number a threshold of how close it must be to be the number you're comparing to. |
| ||
| No because as I mentioned earlier, floats only have 7 digits worth of accuracy, and as it so happens, the first seven digits of 0.000000000000000061230317691118863 are 0.000000 or zero. Print 0.0000000000000001 <> 0.0000000000000002Accurate to seven didgits, is not the same as only accurate to 7 significant digits If you want to say the float number 6.1230317691118863e-17 is only accurate to 6.12303e-17 then you can, but this number is not zero. it is equal to zero within acceptable boundries, but it is not zero In what possible scenario is 0.000000000000000061230317691118863 significantly different from 0? When we are going to multiply it by a big number. Say c^2, or a mole, or a cyclic addition over a long time.Or more specificaly when we go if 0.000000000000000061230317691118863 <> 0 then ... |
| ||
Floats are not accurate. They haven't been accurate since the dawn of time. With mathematical formulae involving floats you will never EVER get precise results. It is not Blitz's fault.r:float = Cos(90) If r < 0.0000001 r = 0 EndIf Problem solved. Maybe we can stop with the inane rambling/arguing about it now. |
| ||
| fwiw, when I did some experimenting with generating sounds, I found out that using floats resulted in crappy quantization noise, doubles otoh sounded truly clean. So, yet another example where float fails. |
| ||
| if you want to compare floats, use ranges, for example if abs(num1-num2)<range where range is 0.01 or such. This is a good way to determine an equals if you absolutely really must. |
| ||
| Why are we talking about Floats, anyhow? Cos() produces a Double result. And of course, as H&K says, it's accurate to significant figures, not decimal places (else the result would be 0). I appreciate the knowledge of what's going on under the hood, though, and that's the main thing. |
| ||
| The real lesson here is that the trigonemetric functions become less accurate as the angle gets bigger. Consider Cos(x). The function is cyclic, with a period of 360. So theoretically Cos(30), Cos(390), Cos(750) etc. have exactly the same value. For simplicity, imagine that numbers have exactly five significant digits. We want the value of Cos(365.12), where 365.12 has five digit accuracy. The first thing Cos() does is reduce x from 365.12 to 5.12. This number has now has only three significant digits, so the accuracy of Cos() is similarly limited. The bigger x gets the more digits it loses and the less accurate Cos(x) becomes. In reality the computer uses bits instead of digits, and "mod 2*pi" instead of "mod 360", but the ideas are the same. |
| ||
| ...and, internally, sin/cos work in radians, so 90 really means PI/2, which may not even be representable itself. |
   |