Mathieu Chamagne

isn't it strange that a so simple operation produces such weird 

have a look at this patch...
isn't it strange that a so simple operation produces such weird  
result ?...
probably a round error...
how do you explain that ?

strange-round

Wow that is really odd. The number is being passed to 

the numbox as a double. If you put a print object after 

the mult, it prints the correct value in the Max window. 

But the numbox seems to alter the number. Pretty scary.

Date: Tuesday, February 20, 2007 10:35 am

> isn't it strange that a so simple operation produces such weird 

> #P comment 64 144 80 196617 0.1 * 100. = 10;

> #P comment 64 122 80 196617 0.08 * 100. = 7;

> #P comment 63 100 80 196617 0.07 * 100. = 7;

> #P comment 63 78 80 196617 0.05 * 100. = 5;

> #P comment 63 34 80 196617 0.01 * 100. = 0;

> #P flonum 87 295 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P flonum 26 190 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

> #P number 26 235 63 36 0 0 0 3 0 0 0 255 92 174 222 222 222 0 0 0;

> #P comment 63 56 80 196617 0.03 * 100. = 2;

> #P comment 125 298 100 196617 result in float = ok...;

Wow that is really odd. The number is being passed to 
the numbox as a double. If you put a print object after 
the mult, it prints the correct value in the Max window. 
But the numbox seems to alter the number. Pretty scary. 

----- Original Message -----
From: "mathieu.chamagne@gmail.com" 
Date: Tuesday, February 20, 2007 10:35 am
Subject: [maxmsp] strange round...

> Hi list.
>
> have a look at this patch...
> isn't it strange that a so simple operation produces such weird  
> result ?...
> probably a round error...
> how do you explain that ?
>
> Mathieu
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 64 144 80 196617 0.1 * 100. = 10;
> #B color 7;
> #P message 36 143 21 196617 0.1;
> #B color 7;
> #P comment 64 122 80 196617 0.08 * 100. = 7;
> #B color 14;
> #P message 36 121 26 196617 0.08;
> #B color 14;
> #P comment 63 100 80 196617 0.07 * 100. = 7;
> #B color 7;
> #P message 36 99 26 196617 0.07;
> #B color 7;
> #P comment 63 78 80 196617 0.05 * 100. = 5;
> #B color 7;
> #P message 36 77 26 196617 0.05;
> #B color 7;
> #P message 36 33 26 196617 0.01;
> #B color 14;
> #P comment 63 34 80 196617 0.01 * 100. = 0;
> #B color 14;
> #P message 36 55 26 196617 0.03;
> #B color 14;
> #P flonum 87 295 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 26 190 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P window setfont "Sans Serif" 36.;
> #P number 26 235 63 36 0 0 0 3 0 0 0 255 92 174 222 222 222 0 0 0;
> #P window setfont "Sans Serif" 9.;
> #P newex 26 209 47 196617 * 100.;
> #P comment 63 56 80 196617 0.03 * 100. = 2;
> #B color 14;
> #P window setfont "Sans Serif" 18.;
> #P comment 48 162 100 196626 ...;
> #P window setfont "Sans Serif" 9.;
> #P comment 125 298 100 196617 result in float = ok...;
> #P window setfont "Sans Serif" 36.;
> #P comment 98 238 100 196644 ?!?;
> #B color 14;
> #P fasten 8 0 6 0 41 74 31 74;
> #P fasten 11 0 6 0 41 96 31 96;
> #P fasten 10 0 6 0 41 52 31 52;
> #P fasten 15 0 6 0 41 140 31 140;
> #P fasten 13 0 6 0 41 118 31 118;
> #P fasten 17 0 6 0 41 163 31 163;
> #P connect 6 0 4 0;
> #P connect 4 0 5 0;
> #P fasten 4 0 7 0 31 230 92 230;
> #P window clipboard copycount 19;
>
>


On 20-Feb-2007, at 17:29, mathieu.chamagne@gmail.com wrote:

0.01, 0.03, and 0.08 are not exactly representable in in binary 

floating point. Neither are the other values you used, but sometimes 

I've written about this stuff on the list dozens of times, but now I 

ncg_goldberg.html>, and for a more interactive approach

0.01 is represented as 00111100001000111101011100001010. Multiplying 

by 100 gives something like 00111111011111111111111111111111, which 

evaluates to 0.99999994. That number, in a flonum, gets rounded up 

when it's displayed by sprintf(), which is what flonum apparently 

uses. When converted to an int it is truncated.

The other values are left as an exercise.

Yeah, it would be nice if this stuff could be made easier for users.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

> have a look at this patch...
> isn't it strange that a so simple operation produces such weird  
> result ?...
> probably a round error...

0.01, 0.03, and 0.08 are not exactly representable in in binary  
floating point. Neither are the other values you used, but sometimes  
one gets lucky.

I've written about this stuff on the list dozens of times, but now I  
can just point to . For  
more details:
ncg_goldberg.html>, and for a more interactive approach
schmidt.net/FloatApplet/IEEE754.html>

0.01 is represented as 00111100001000111101011100001010. Multiplying  
by 100 gives something like 00111111011111111111111111111111, which  
evaluates to 0.99999994. That number, in a flonum, gets rounded up  
when it's displayed by sprintf(), which is what flonum apparently  
uses. When converted to an int it is truncated.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

if you want to make a 'clean' convertion of floats to integers, don't 

forget to use : round / f0.round / jmod.round / Lround / lp.scampi ...

so :
if you want to make a 'clean' convertion of floats to integers, don't  
forget to use : round / f0.round / jmod.round / Lround / lp.scampi ...
(!!? only 3rd party externals...??!)

On 21-Feb-2007, at 9:27, mathieu.chamagne@gmail.com wrote:

> if you want to make a 'clean' convertion of floats to integers, 

> don't forget to use : round / f0.round / jmod.round / Lround / 

Some of the best things in life are 3rd party externals.

If all you want is rounding of positive values, it is dead easy to 

Negative values need to *subtract* 0.5 before truncation, which trips 

up a lot of people. Still easy enough to abstract.

The objects you list mostly offer some additional options. In the 

case of scampi, it began as a convenient scale&map object in an age 

when neither scale nor zmap was included the factory install. I added 

rounding capabilities (plus other mathematical truncations, there are 

a lot more) as a convenience. Over time more functions have been 

added, making it a Swiss Army knife for mapping an input value range 

to an output range. Coincidentally, that's exactly what your patch 

wants to do. Just replace the [* 100.] box in your patch with 

[lp.scampi 100 round] and you will get the results you expect.

Mais il-y-a plusieurs methodes pour peler le chat.

On 21-Feb-2007, at 9:27, mathieu.chamagne@gmail.com wrote:
> if you want to make a 'clean' convertion of floats to integers,  
> don't forget to use : round / f0.round / jmod.round / Lround /  
> lp.scampi ...
> (!!? only 3rd party externals...??!)

If all you want is rounding of positive values, it is dead easy to  
make an abstraction for that:

Negative values need to *subtract* 0.5 before truncation, which trips  
up a lot of people. Still easy enough to abstract.

The objects you list mostly offer some additional options. In the  
case of scampi, it began as a convenient scale&map object in an age  
when neither scale nor zmap was included the factory install. I added  
rounding capabilities (plus other mathematical truncations, there are  
a lot more) as a convenience. Over time more functions have been  
added, making it a Swiss Army knife for mapping an input value range  
to an output range. Coincidentally, that's exactly what your patch  
wants to do. Just replace the [* 100.] box in your patch with  
[lp.scampi 100 round] and you will get the results you expect.

> Wow that is really odd. The number is being passed to 

> the numbox as a double. If you put a print object after 

> the mult, it prints the correct value in the Max window. 

> But the numbox seems to alter the number. Pretty scary.

Not if you know about the option called "float display correction" which 

apalomba@austin.rr.com wrote:
> Wow that is really odd. The number is being passed to 
> the numbox as a double. If you put a print object after 
> the mult, it prints the correct value in the Max window. 
> But the numbox seems to alter the number. Pretty scary. 

Not if you know about the option called "float display correction" which 
you can switch on or off...

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


> if you want to make a 'clean' convertion of floats to integers, don't 

> forget to use : round / f0.round / jmod.round / Lround / lp.scampi ...

But if you use my rint abhaXion, and de-encapsulate it, you turn the 3rd 

(and to simplify it you can erase the parts you don't need...)

mathieu.chamagne@gmail.com wrote:
> if you want to make a 'clean' convertion of floats to integers, don't  
> forget to use : round / f0.round / jmod.round / Lround / lp.scampi ...
> (!!? only 3rd party externals...??!)

But if you use my rint abhaXion, and de-encapsulate it, you turn the 3rd 
party into a max patch...
(and to simplify it you can erase the parts you don't need...)

yes, I know that some of these 3rd party are abstractions (and I love 

using externals!) ; I just meant that i'm a bit surprised that 

there's nothing built in max to prevent that kind of 'error' (even if 

it's not really an error...). I imagine it can be quite confusing for 

a beginner to discover that 0.03 * 100. = 2

not same result if you click a message box, or type in value in float 

yes, I know that some of these 3rd party are abstractions (and I love  
using externals!) ; I just meant that i'm a bit surprised that  
there's nothing built in max to prevent that kind of 'error' (even if  
it's not really an error...). I imagine it can be quite confusing for  
a beginner to discover that 0.03 * 100. = 2

not same result if you click a message box, or type in value in float  
number box...
isn't it confusing ?!?

www.maxobjects.com
http://mathieu.chamagne.free.fr

> I imagine it can be quite confusing for a beginner to discover that

Yes, but the only alternative would be to do it like in Pd where 

intergers just don't exist, and even that would still lead to confusion. 

To be confused is part of the learning process, no matter what you learn...

mathieu.chamagne@gmail.com wrote:
> I imagine it can be quite confusing for a beginner to discover that
> 0.03 * 100. = 2

Yes, but the only alternative would be to do it like in Pd where 
intergers just don't exist, and even that would still lead to confusion. 
To be confused is part of the learning process, no matter what you learn...