Probably a stupid question but...
Hello everybody,
I am new to Max MSP and just bought Max 5 a month ago - working pretty intensely on it at the moment. Best program ever in my opinion, but then I just stumbled upon a problem when trying to multiply 441 by 0.1 in Max: the result I get is 44.100002. So I tried to divide it by 10 instead but I got 44.099998. This is just an example but it annoys me quite a lot, as certain numbers show no problem and some, even as simple as these ones, do.
Damn, how come simple multiplications/divisions give wrong results?? Can anyone tell me if there is any way this kind of things won't make all my patches lack of precision in the end?
Thanks to you all for contributing to this great forum, and hope I will be of some use in a near future too!
Yann
This is a question that comes up quite regularly. Google a bit on terms like {floating-point precision accuracy IEEE754} and include the site:cycling74.com term in your query, and you'll get a couple of hundred messages covering this.
The short answer is: the results are not wrong at all. They are exactly what you you should expect with digital arithmetic. 44.100002 and 44.099998 are as close as you can get to 44.1, which cannot be represented with finite precision on your computer. This is the math that your computer is using every nanosecond of every day for every program you have ever used.
The complete answer is: read "What Every Computer Scientist Should Know About Floating-Point Arithmetic," <http://docs.sun.com/source/806-3568/ncg_goldberg.html> is one link. Don't matter if you don't think you're a computer scientist, you're programming a computer with Max and you need to know this stuff. Period.
The intermediate answer: take a piece of paper and a pencil. Divide 10 by 3, to six digits accuracy. You get 3.33333. Multiply that by 3. You get 9.99999. That's what your computer is doing.
--
Corrected typo: 'finite' instead of 'infinite'. Apols for the confusion.
Thanks a lot for the link and the explanations Peter. I was quite sure it was something like that but didn't think it would be the case when doing such operations, that are - at least to me and to any basic calculator - so trivial, as dividing something by 10 seems nothing like dividing 4 by 3! But I get the point now (haha), no need for further explanations as I just read quite a lot about it.
On the other hand the Float Display Correction in the preferences doesn't seem to visually correct this, which is of course not really important but would look better on the patch: it was already checked.
Anyway once again, thanks!
Yann
So, my question is whether fixed-point math encounters the same problems when doing operations on large numbers. I realize the range is much less with fixed point, and that's not my question. Does the accuracy issue crop up even within the fixed-point range the way it does with floating-point?
We're so used to 10 being a 'round' number that we overlook that in binary arithmetic 1/10 is an infinitely repeating binary fraction, every bit as evil as 1/3.
Apropos fixed point (@Steve): you still have the fundamental issue that arithmetic is binary. As soon as you divide by a number that isn't a power of 2, the result can only be an approximation of the real answer. (If you dislike puns, please ignore this one). Fixed point avoids some problems of floating point, but it has it's own issues.
Re: Float Display Correction, to be honest, I never understood exactly what it did. It's probably documented somewhere I still haven't read. But most options that have been introduced over the years seemed immediately obvious to me, whereas this one remains a bit mysterious...
Peter Castine wrote on Wed, 20 May 2009 07:44
Apropos fixed point (@Steve): you still have the fundamental issue that arithmetic is binary. As soon as you divide by a number that isn't a power of 2, the result can only be an approximation of the real answer. (If you dislike puns, please ignore this one). Fixed point avoids some problems of floating point, but it has it's own issues.
As I suspected...it's just that I've always come across posts (here and elsewhere) decrying the 'problems with floating-point accuracy' without mentioning fixed-point...implying that somehow fixed-point is more accurate, if not just superior in general. Having spent quite a few years with FORTH/HMSL I just got used to doing everything in fixed-point, but sure appreciate the programming convenience of floating-point.
i dont think he doesnt know about accuracy, maybe he
just wonders why numbers sometimes show up rounded
and sometimes not, as if the "correct number display"
option was turned on while it isnt.
sometimes i see that too and usually closing and reopening
the patcher fixes it.