Storing floats accurately in pattrstorage

I believe you're dealing with issues associated with the fact that Max works with 32-bit floating point, so it's unlikely you're going to get more resolution for floating-point values than you're seeing.

Peter Elsea's explanation (from his tutorial "Max and Numbers") remains a touchstone of clarity on this point. And I quote:

"The float data type seems like a familiar sort of number-most of us have been writing decimals since grade school. However, there are some features of the way computers deal with floating point numbers that you should be aware of. Even if a number is shown on the screen as a decimal number, the computer is still working with bits, and has a limited number of them at its disposal. In the case of Max, that's 32 bits. These are used to represent the infinite range of decimal numbers by a scheme called floating point notation. You may be familiar with a version of this known as scientific notation- to represent 4823, you write 4.823 X 10^4.

To encode floating point numbers, Max follows a convention known as IEEE single precision floating point format. This uses 32 bits as follows:

1 bit to indicate sign (0 for positive)
8 bits for the exponent
23 bits for the significand, which has the form b(sub m).bbbbbbbbbbbbbbbbbbbbbbb where each b is either 1 or 0.

The actual value of the number is ± significand x 2^(exponent)

There is further massaging to save bits or processing time where possible. For instance, the exponent can be positive or negative, but instead of having a sign bit in the exponent, 127 is subtracted from the exponent when the number is converted. With 8 bits, the exponent may range from –127 to 128. In addition b(sub m) is unnecessary since it's always the same. ( 1 for most numbers, 0 if the exponent is –127.)

The result of all this is that floats can sometimes surprise you. For instance, you cannot represent all possible numbers with this scheme. In fact there are fewer floating point numbers than there are ints. The difference is that while ints are simply limited in magnitude, floats are spotty, jumping from value to value. With large numbers, the jumps can be pretty big, say from 134217712 to 134217720.

With small numbers some odd things happen too. You can see this by stretching a float box, typing in 0, and scrubbing the value up. You'll see the numbers change by steps of 0.01 up to 1.14, but the next value is 1.149999. That's because you can't actually represent 0.01000000000000000 as a binary number times some binary power of two. The value is really something like 0.0099999999999, which will round up to 0.01, but if you keep adding it in, eventually the rounding error catches up with you and 1.149999 pops up."

I suppose it's possible that there's a bug with the way that pattr stores 32-bit floats, but if so I'm not seeing it on a cursory look (Macbook Pro 10.5.8, current version of Max). In fact, the enclosed patch suggests to me that you might be able to type in whatever value you wish, but the result is still truncated to 32-bit on recall. Here's the patch:

And here's the .json file with the preset information in it (this is raw text):

{
    "pattrstorage" :     {
        "name" : "ffooz",
        "slots" :         {
            "1" :             {
                "id" : 1,
                "data" :                 {
                    "nmbr" : [ 1.618034 ]
                }

            }
,
            "2" :             {
                "id" : 2,
                "data" :                 {
                    "nmbr" : [ 1.61803398 ]
                }

            }

        }

    }

}

On my system, presets 1 and 2 are recalled to the same floating-point value of 1.618034 (the nearest 32-bit value), as I'd expect.