Luke Woodbury

max-and-floating-numbers

Nicolas, I'm afraid this won't help for Luke's problem. 

 will correctly display the value, but . 

 wont as 20.30 and 20.2999999 are the same float.

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.

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

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 

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

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

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

@Peter, thanks for the info. as for the random comment, I know it's not random, but from a user perspective, it's really hard to predict what can and cannot be represented - just my excuse for lazy typing :)

Max and floating numbers