Max5 flonum strange behaviour
I apologize if this has been discusses before, but Max5 flonum has a strange behaviour when dealing with big numbers (not so big, actually) and decimals: if you have a value of, say 10000 (ten thousand) in the float number box, and you try to increase decimals sometimes you get -2147.483643… (I guess this has to do with computer precision)
Try this patch, it gives no problems in max 4.6
----------begin_max5_patcher---------- 419.3ocsT1raBCCCG+b6SgUtgDf5WHX6vj1ywDaJzZnYqMA03JXCw69ZSZGv VA0wX8Pix+3D6e1wYmqCagZKpYv8vSfiyNWGGiTsfSybGVNeabFWaLiEqxyQ IwFZWivsjQOX.7LjTv2.aDTJPoHjqJ0HHjlIEhUoDnEIHnVBKyTxx71CISHw XUozbRAMhUqKjYHYbqei3RkjzhOPiVvXuC1pJoViaUWyo3Tgb0KEXLYYLbR8 l.+oyLCS7pGBiF6Aya1jHwfiZwqiticjWk7biWYOVH3Yr5E165V+a3eLy4O. hyDwuAoXABip9df8elC7CMT66YSEdg0CAdcmCldayAKJIRIuHdmxQqpUhdeM ZgfsfKWw9Jh6.yfvPKe9s7cdJmbMrjiZMeE9y5oW0WmHF7apfmk7dQcng5nH yjYcSczss1dZO80e0M3bfW4.dU6Sup8161SlZGlcohue+RClsZdp5auWZ7es 9o4FsprHtMzsWxFBGBfDTSBImDUsCGrI5DaREIIn7314bQxZkPRMg.Luy5Te inndDQ9+gHpZxd2OATIs7UC -----------end_max5_patcher-----------
hi maurizio, yes i can reproduce it, sometimes it happens but only in max 5.
Maurizio Giri schrieb:
> if you have a value of, say 10000 (ten thousand) in the float number
> box, and you try to increase decimals sometimes you get
> -2147.483643… (I guess this has to do with computer precision) Try
> this patch, it gives no problems in max 4.6
The position of the dragging seems to cause this, I have to drag in the
area right to the last displayed digit…
For sure this has nothing to do with the precision…
Any number higher than 2147.483643 will cause this btw…
Quote: Stefan Tiedje wrote on Thu, 15 May 2008 15:46
> For sure this has nothing to do with the precision…
> Any number higher than 2147.483643 will cause this btw…
…are you sure? the minimum negative integer number in Max is -2147483648, so I think it has something to do with it…
----------begin_max5_patcher---------- 412.3ocuTF0aCBBDG+Y8SAgGWzFwZU6xdYeNVZVPjprgPiPy5VS+tOD0Tcy1 4xZlOvAGmG+uem3QWGXl7.UAA2CdB33bz0ww5pwgS2ZGXE9.giU1vfDYUEUn gds6ooGzV+O366CHbF4UPIsl1u+VoPqXePahAEtHnysXeESvoZaNQcN2g0jR ln34ZJQ2pIT5Ry6.PIwVypfFSnYDro6kX41iWl8hOZI7b5k6084OXfVD3JqV fOVyvbXyFmbcaF7lI.Dz2LG12p+6.n.6yh9sZUf98cz1ZAtkKwlf27KPS3UP SXpEFHKShWeMxjLMXP2TvTQUJbA8ajw2BlKRkaMPPIVST6hzoAR7+APL4NiV ewBm0bKB.yvhhyLHqfH4x51PBVjFadR7lbFZPoMBcQW+ZltloHXtM1fEq+4u vhBsljVyxAGaYSSdrfSBVkl5M4Lzz8hno6EgypWXSHjyDe8uX15ow+3FjRtu lz2A5tZ.NKqbpRyDXMSJFDSznXJY44TwverTwx2IMsyNI.1L4GKyUQwyPQI+ AEYVbx8SdhDWYA -----------end_max5_patcher-----------
Maurizio Giri schrieb:
> …are you sure? the minimum negative integer number in Max is
> -2147483648, so I think it has something to do with it…
This points to a type conflict in the code. The way the new value is
calculated is truncated at this point or something…
We had no response from the bug fixing department, maybe they missed it?
This sort of bug should be fixable in a couple of minutes…
Its a typical problem for lousy typed languages like C…
In Max 4, to handle certain precision problems with floats, the flonum object actually worked with fixed-point decimal while dragging… it used the 32-bit signed integer range with an implicit decimal point, giving an effective range of something like -21474836.48..21474836.47. I seem to remember Stefan complaining about flipping from positive to negative when mousing over in that range.
Apparently Max 5 is doing something similar, just with the decimal point further to the left.
What’s cute about the Max 5 flonum is that the precision of mouse scrolling matches the digit you moused-down on to initiate the drag. So if you moused-down on the first digit to the right of the decimal point, you scroll in units of 1/10, on the second digit you scroll in units of 1/100, etc.
There are still some artifacts of 32-bit floating point that crop up. For instance, I scrolled to -1984.2, but when I mouse up that turns into -1984.19951. I need to check with a fp bit mapper, but the latter value is probably the closest 32-bit value to the decimal value displayed while mousing. It appears that during the drag Max is taking the integer -19842000000, incrementing/decrementing by units of 1000000, and inserting a decimal point into the printout after the fourth digit from the left. This all works nicely, the way most people expect. Just on conversion to a real 32-bit float you get the typical surprises.
Probably the most practical rule of thumb is not to use flonum outside the range -100..100. The object works great inside that range. Outside that range you start getting dem ol’ limited 32-bit float precision blues mama.