janwillem

Make a 1x1 float32 matrix and set te cell to 215.666. Store the matrix, read it and ask for de value.

It happens that it is changed to 215.916 !

I happend to found some more numbers who act the same way (215.69725 215.7285 216.519516 216.582016 216.613266 216.644516 216.675766 216.707016 216.738266) and there are possibly many others.

Note that a value of 0.25 is always added to the number once stored, but it won't happen using the matrix

I can work around this strange behaviour using a float64 matrix, but I only need a 5 decimal precision.

Can someone explain how Max/Jitter handles floating numbers, or give some links where

And is it realy a bug which needs attention?

Is this an amazing bug?
Make a 1x1 float32 matrix and set te cell to 215.666. Store the matrix, read it and ask for de value.
It happens that it is changed to 215.916 !
I happend to found some more numbers who act the same way (215.69725  215.7285  216.519516  216.582016  216.613266 216.644516  216.675766  216.707016  216.738266) and there are possibly many others.
Note that a value of 0.25 is always added to the number once stored, but it won't happen using the matrix
values live in the patcher.
I can work around this strange behaviour using a float64 matrix, but I only need a 5 decimal precision.
Can someone explain how Max/Jitter handles floating numbers, or give some links where
And is it realy a bug which needs attention?

why-cant-a-float32-matrix-storeread-the-number-215-666

http://en.wikipedia.org/wiki/Single_precision

Here's the long answer:
http://en.wikipedia.org/wiki/Single_precision

There is no way to put more than 2^32 different values in a 32 bits variable.

Floating point is a trick to store big numbers and very small ones, but you loose precision. On big numbers, you can't even increment by one unit.

The article mzed point you to, explain it very well.

Anyway, I think there is another problem in your case. Because according to the article, a float32 have 23 bits for the significand, so it allows 2^23 = 8388608 values. Enough to hold the 6 digits of your 215.666 ... but I may be wrong.

I can confirm empirically (using a couple of quick test that this is not a floating point accuracy issue in max.

bokan is right - if I remember correctly 23 bits equates roughly to 6 or 7 significant decimal figures, so you should expect to be fairly close to the value given (I turned off floating point correction in my preferences and sent the number from a message into a float object, then to the right inlet of another message box and it returned exactly - obviously there is still some rounding going on for display with float correction off).

There's something else going on here to do with file formatting of floats - the accuracy is not good for text files (3 decimal places I believe - which is not always sufficient) and seemingly there is an issue for jxf format too. Given this is a non-human readable file format specifically for numerical data I'd expect all the values to be recalled exactly (the textfile thing at least has a clear rationale, even if it is potentially frustrating).

To be totally clear, for me the value recalls fine if I do so straightaway, but not after saving...

I'd say this is a bug and you should contact support with your patch and a clear explanation.

If you need a workaround you might look at other ways of storing the matrix to a file - there may be something on the forum relating to the accuracy of floats in files that can help you.

Thank you for your clear report. I can confirm that this is in fact a bug, related to byte swapping issues, as the JXS format uses network byte ordering (big endian). I'm not sure that the change will be in 5.1.5 which is close to ready, but I will get it in before 5.1.6.

The current workaround is to use float64 matrices as you've discovered, or use jit.fprint with as many textual digits of precision you need with @precision.

Why can't a float32-matrix store/read the number 215.666 ?