Max and floating numbers
----------begin_max5_patcher---------- 854.3oc0XkraaCCD8r8WAqP6M0.QpU1KE8VO1CEHnnnnfVhNgoRjBTzYoA4e ubQxwNIRVwawMHPxbwbdyal4Mx59oS7lItk13A9D3mfISte5jI1oLSLoc7Du Jxs4kjF6173zaDytxy2sjhdqxNcofTLivunaAwBUIUotql5NbO6hfe0tbMQk eIiewukzbkaGYQmE3CfolqIAlqH80keCVg0NZa+QTmQlK3JNoxZBuuHYjxtU 3KpXbM.rXFtx1aX+0tcHRagk60gV2lMS9vzolK9ijSxEUUTt5Yjx2ujB9lTL qjV40uiiicNan0+CvC45gAa12MlOWTJjtiO3rrnzLThu9SAPLNy8IsoVwDaO e0Masj1n4.hhI3Oy4fXqE6trzrykWLaLnbOGSNWH+CQJVvKFHrDljL93BL8+ r3RTjyVogmJAly+5O.jJ.CzPo5HggpQXyee9cfABSnPW7AZkOPwnACSImpgo CHg2ihsNwnlxK.2HYJZux1CJYibk0nvLysrvAo9nSMU6d3EEnALqe9veDsx5 3EmzQ3v7B7PxKnsfWpnMMjKnOiXxKoDoOnRbMUIz9i9+sKsIz0puMsABcsHx dY9A+JoGzqJsYXQRD19zHHHbcQxsfTKyK5krJYMJSdU2cF2daToXIXGGZQHF 8xbX1fIRqSIQafRhcTRDdmojdp+ZpkZBXNn4NCr.e3Lz7cRcBll5nnAKCSO0 TmlWJzGRudtdYhZThQv1N8tFj3AYgQzdrlH0yqnxeS4D8S1tZSrcPmZCOEo0 ERi24bt8MqlYq6hxFhTieyH08n3u14B2txPmXejM1EFMjTe3AUp+DPztsu2n zrguFM6CaWde2yHBdObWx.PgNcnjAyAfAGqj.q00gO9Se+GVOvL+5rWiXgLu yeaeMDfG8gBZihwsBWqrmv01ykrhBJe0h6BViod25+AuXTbrnIbDnIcCnohU TKzIxsDhtWQrIfgM2z+VrkidzL6M3a94AaD+YGM1z7T4aDNOAyGb7.2.dvGM 3jNF1AdzfC9jJ2YLUhIaUkXfS5LBubzAnRbLvOdafeZfE1NzaF7FAdSKliUY avXvyVBGWCLRc80TYS6QZQhtQ+UtWeUhucHi6FZOQOI8ZV29imZNsGl9O3ac 9IF -----------end_max5_patcher-----------
Nicolas, I’m afraid this won’t help for Luke’s problem. flonum will correctly display the value, but . lcd wont as 20.30 and 20.2999999 are the same float.
Not sure using tosymbol looks better: 20.3000
The sprintf solution works fine with lcd, but can someone explain why 20.3 equates to 20.29999 in the first place?
it’s the way floating point works and it’s inherent limitations. most fp calculations use double precision (64- or 80- bits) rather than 32 to minimise this.
take a look at http://www.h-schmidt.net/FloatConverter/IEEE754.html and enter 20.3 in the box. here you can see how this number is internally represented and what that actually comes out as
Thanks leehu, I think I understand now. I’m just surprised I haven’t come across it before.
kind of random really as to what numbers cannot be represented, so until you hit one you never really see it. kinda surprised that they’re not using doubles internally rather than floats…
Maybe it’s legacy from the early days, when memory was at a much higher premium. This way things are more compatible and patches don’t get broken…? just a guess.
This really ought to be a sticky. I feel like I’m reading this thread for about the 10,000th time.
@leehu: doubles *are* used for internal arithmetic (mostly), but for message-passing between objects it has always been convenient to use data types that are the same size for floating-point, integers, and symbols (pointers). And the common "denominator" was a 32-bit word. Never mind that in the mid-1980s a lot of computers didn’t even support 64-bit float registers (plus Apple’s software double-precision float was an 80-bit datum).
Nor is it "random" what can be represented exactly. If it’s a binary fraction, it can be represented exactly. If it ain’t, it cain’t.
PS: Google turns up over 10,000 hits for this query. Some these are documentation and other non-forum stuff, but my initial claim isn’t that far off.-)
(And it may be instructive to read a few of the links!)
My description of what can and cannot be precisely represented is a bit of an over-simplification, but once you’ve got binary fractions in your head, you’ll have far fewer wtf-moments in Max.
Sorry to have wasted your valuable time Peter…
Forums > MaxMSP