Maurizio Giri

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

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

max5-flonum-strange-behaviour

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

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


> 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...

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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...

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...

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...

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.

Apparently Max 5 is doing something similar, just with the decimal point further to the left. 

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.


Max5 flonum strange behaviour