Forums > MaxMSP

Max5 flonum strange behaviour

May 15, 2008 | 4:56 pm

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

– Pasted Max Patch, click to expand. –

May 15, 2008 | 6:18 pm

hi maurizio, yes i can reproduce it, sometimes it happens but only in max 5.
antonino


May 15, 2008 | 9:46 pm

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

Nice bug.
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…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


May 15, 2008 | 10:45 pm

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…

– Pasted Max Patch, click to expand. –

May 16, 2008 | 6:04 am

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…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


May 16, 2008 | 10:55 am

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.


Viewing 6 posts - 1 through 6 (of 6 total)