Very weird issue – is this just happening on my system?
Hi all, something weird is happening with this very, very simple patch:
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 404.3oc2TssaCBCC8Y3qHJOy53RGsr212wzTU.RaSEMAkD5Xqp+6KNA5XS8B cRaOrW.7wN1GevN688v4hVpBidD8LxyauummEB.75r8vaIsEUDkMLLm9pHeC Nv4RSa0V3JAobKUoPQogI8dqI5h0L9pERZg1UjjjvIgAPTvqrX3Yr4azKcmg UZymoF2cLOKEbMmrkZ87jjQp58va1x3UTskaQcfhFsAR+VM0USL9X1gLoXua cDAE+XZbGxkG.7fuO7HXjxxxJgIIinwylBulYMhSNciGmc8NulHM3ZpbAkSx qrQDdSphgxDMN.gyI7UmQhd3LRT7unDE2MabYIZ1+QI5LKW2ihBCmLBkKFHC Z57Kpbo23ZU7kUmaSUFtaYOIthw+9MP1NDv+pToDMxh9h2cAA5ydrjpzLNQy D7Aw.6RCBZMqrjxGNITxTvvgUfBO4+rwRGPYuNel82wmrwvmzeHeb+8H006n RUWNsTwLRuQHAyz.qIi6LsqYXIcGqOdGBQZlm0lg4FoaVrcdJ1GpyA+O.b8+ JNM -----------end_max5_patcher-----------
scrolling up through values outputs a float with two decimal places – as you would expect, until I get to 1603 at which point the output of [/100.] starts looking pretty odd – according to this patch 1603 / 100. = 16.030001 !! If I continue to scroll up through higher values, more and more weird values get spat out by [/100.].
Can anyone else confirm this issue or is it just my system? I’m running Max 6.1.1 on OS X 10.8.3
floating point numbers magic.
Furthermore, [round] can’t rectify the problem. This seems very weird!
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 467.3ocyUssbBBCD8Y3qHSd1ZgfEk9V+N5zwIJQMNXBSRvZqi+6MYCdqinXG GsuDX2rWN4PNKqCCvijqXZL5Uz6nff0gAAfKmifZ6.7B5pwETMDFdRgTTs.2 wuk8UtnfYf8hqcJqLVWluJY9B6xgZvcP3QTwTL5i53lHEFM+aHp3W5Fsul9J .EkT6sTwzLggZ3RwPEarwW6jjHahnDRO2in5kcsnjZFOiKldpLfGYvJI4fb3 4vAUNZ9SD7APUPW.PE+lhSKv65fx52vTCYB5nBHhH2VaBCcKcZIuJXeZ631p ZXq.3hUxJQt6HEeRJmzDk2.KSZfkiuHeQ7LU5.vH5z7U7Y3qaGmXuMkufo0n 3znjq6l3MmVrP.tFQNGsjbaokGlDrYVHCje8OuXJ69ol9+QQjz1Luo+Cefyy n3nntW2vFOyccLVKl3Pb4h5M3rLVZ6zVPt3Bt32+sC5uy+wTkVVoFu87UOZC sGA4LsgKfeFcPLjihYFOOmAaukAx4Z2Wr7l+j0Vz3tnbQ3De+fSVaXmz6GdR aCd5e2vSRafS1eDN9q1zxxkLkttl.Rr584RkyLsCXxEdSP6gUrk7sw68PUVo nwpCqTdYzpAoVQjsOaB+AzhQawB -----------end_max5_patcher-----------
Thanks for the reply Andrzej, that is an interesting link. If I want to convert a number like 1603 to 16.03, how should I do it then? I’d always presumed that dividing it by 100. was the way forward, with that not working and [round] not working either I’m not sure how to proceed.
This issue has been discussed many times on the forums. The point is that this number is not computable with finite precision floating point numbers – you are seeing the closest binary representation of this number.
If you want to limit your flonum’s display to two decimal places you can do so by setting the "Number of Decimal Places" attribute in the flonum inspector. But the value that is being passed will still be 16.030001.
32-bit floating point system cannot exactly represent it, so there must be some tradeoffs. The issue is rather about displaying this number (visual interpretation). If you multiply it by 100, you will get the expected result. "Floats" are not decimal fractions.
Forums > MaxMSP