Problem with mtof and… buffers?

Dec 18, 2006 at 10:44am

Problem with mtof and… buffers?

Hi,

(MaxMSP 4.6.2 / OSX.4.8 / Quad G5)

While testing some results from a suite of operators through mtof, I
decided to concatenate these operators inside an expression.
Surprise, the results are not always identical. Strange!
Between the last operator and the mtof, I have to put a flonum (as
buffer?) to get the same result coming from the expression directly
connected to mtof. Why?

To add a test, the results are then compared through a conditional
statement (1) and through a binop (2).

(1) [expr] -> [mtof] -> [if] works fine, the expression object
appearing the most robust.
(2) here again, I have to put a flonum between mtof and the binop. Why?

I’d like very much to understand this… behaviour?

Below a patcher full of comments inside.
Kind regards,
Philippe

#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 244 260 103 196617 for matching in binop , a flonum as
buffer is needed after mtof;
#P window linecount 1;
#P comment 148 183 97 196617 – same results , ok -;
#P comment 511 236 97 196617 – same results , ok -;
#P window linecount 2;
#P comment 73 385 154 196617 neg results match at 0 , -7 , -11 ,
-14 , -25 , -32 , -39 , -50 , …;
#P comment 87 356 122 196617 pos results match at 0 , 7 , 11 , 14
, 18 , 21 , 25 , …;
#P window linecount 1;
#P comment 65 228 246 196617 —- results are not always the same
————–;
#P comment 507 183 115 196617 — same results , ok —;
#P flonum 58 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 12.;
#P comment 522 22 73 196620 works fine;
#P toggle 48 330 33 0;
#P window setfont “Sans Serif” 9.;
#P newex 169 82 34 196617 t i i 0;
#P toggle 212 330 33 0;
#P newex 212 298 31 196617 == 0.;
#P newex 48 298 143 196617 if $f1==$f2 then 1 else out2 0;
#P newex 48 269 50 196617 pipe 0. 20;
#P flonum 246 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 233 242 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 233 207 30 196617 mtof;
#P newex 233 138 110 196617 expr ($i1*0.01) + 69.;
#P flonum 59 242 86 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 48 207 30 196617 mtof;
#P newex 48 158 35 196617 + 69.;
#P newex 48 138 41 196617 * 0.01;
#P number 169 63 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 610 113 107 196617 no buffer needed from expr to if thru
mtof;
#P window linecount 4;
#P comment 463 130 97 196617 for matching in if and/or binop , a
flonum as buffer is needed before mtof;
#P window linecount 3;
#P comment 614 260 103 196617 for matching in binop , a flonum as
buffer is needed after mtof;
#P toggle 420 330 33 0;
#P window linecount 1;
#P newex 541 82 34 196617 t i i 0;
#P toggle 584 330 33 0;
#P newex 584 298 31 196617 == 0.;
#P newex 420 298 143 196617 if $f1==$f2 then 1 else out2 0;
#P newex 420 269 50 196617 pipe 0. 20;
#P flonum 618 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 605 235 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 605 207 30 196617 mtof;
#P newex 605 138 110 196617 expr ($i1*0.01) + 69.;
#P flonum 420 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 427 235 86 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 420 207 30 196617 mtof;
#P newex 420 158 35 196617 + 69.;
#P newex 420 138 41 196617 * 0.01;
#P number 541 63 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 12.;
#P comment 54 22 242 196620 results don’t match at each new value;
#P window setfont “Sans Serif” 9.;
#P window linecount 2;
#P comment 244 303 91 196617 otherwise , only matches at 0;
#P user panel 7 40 356 385;
#X brgb 255 247 207;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P background;
#P user panel 370 40 356 385;
#X brgb 255 220 180;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P background;
#P connect 10 0 11 0;
#P connect 10 0 13 0;
#P connect 12 0 16 1;
#P connect 11 0 15 1;
#P connect 11 0 12 0;
#P connect 18 1 10 0;
#P hidden fasten 18 2 19 0 570 103 405 103 405 325 425 325;
#P hidden fasten 18 2 17 0 570 103 405 103 405 325 589 325;
#P connect 16 0 17 0;
#P connect 14 0 15 0;
#P fasten 14 0 16 0 425 293 589 293;
#P connect 4 0 18 0;
#P connect 7 0 14 0;
#P connect 7 0 8 0;
#P connect 15 0 19 0;
#P connect 15 1 19 0;
#P connect 9 0 7 0;
#P connect 6 0 9 0;
#P connect 5 0 6 0;
#P connect 18 0 5 0;
#P connect 28 0 29 0;
#P connect 28 0 31 0;
#P connect 30 0 34 1;
#P connect 29 0 33 1;
#P connect 29 0 30 0;
#P connect 36 1 28 0;
#P hidden fasten 36 2 37 0 198 103 33 103 33 323 53 323;
#P hidden fasten 36 2 35 0 198 103 33 103 33 323 217 323;
#P connect 34 0 35 0;
#P connect 32 0 33 0;
#P fasten 32 0 34 0 53 293 217 293;
#P connect 23 0 36 0;
#P connect 26 0 32 0;
#P connect 26 0 27 0;
#P connect 25 0 26 0;
#P connect 25 0 39 0;
#P connect 33 1 37 0;
#P connect 33 0 37 0;
#P connect 24 0 25 0;
#P connect 36 0 24 0;
#P window clipboard copycount 47;

#29277
Dec 19, 2006 at 12:15pm

Philippe GRUCHET wrote:
> While testing some results from a suite of operators through mtof, I
> decided to concatenate these operators inside an expression.
> Surprise, the results are not always identical. Strange!
> Between the last operator and the mtof, I have to put a flonum (as
> buffer?) to get the same result coming from the expression directly
> connected to mtof. Why?

I can confirm this odd behaviour. It seems there are different
resolutions at work. I looked at your patch, first got rid of the 0
initialisation and the pipes because they should not do anything to the
result. But the pipe does for a reason I don’t know. It seems to adjust
something. The binop does not match equal numbers whereas the if does.
Might be the same “resolution” issue as with the flonum.

But its getting even wierder, I have two identical versions both with
the theoretically unecessary pipe, one works as in the original example,
the other doesn’t. THIS IS SERIOUS I want to know why. Both version
patchwise identical but with different behaviours below…
The only difference in the patch is the order of object creation. And
that must not create different behaviour !!!!

I now ask the support of cycling if this is read. (No need for an
explanation yet) And if this is confirmed. If there is no official
reply, I’ll forward it to the support. The same is true for the thread
about execution order in MSP. I want an answer from the gurus which know
the inards of Max…

It seems that some of the important issues get lost with the new amount
of people sharing the forum and list…

Stefan

This does the binop correct:

#P window setfont “Sans Serif” 9.;
#P window linecount 3;
#P comment 244 260 103 196617 for matching in binop , a flonum as
buffer is needed after mtof;
#P window linecount 1;
#P comment 148 183 97 196617 – same results , ok -;
#P window linecount 2;
#P comment 73 385 154 196617 neg results match at 0 , -7 , -11 , -14
, -25 , -32 , -39 , -50 , …;
#P comment 87 356 122 196617 pos results match at 0 , 7 , 11 , 14 ,
18 , 21 , 25 , …;
#P window linecount 1;
#P comment 65 228 246 196617 —- results are not always the same
————–;
#P flonum 58 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 48 330 33 0;
#P newex 169 82 34 196617 t i i;
#P toggle 212 330 33 0;
#P newex 212 298 31 196617 == 0.;
#P newex 48 298 143 196617 if $f1==$f2 then 1 else 0;
#P newex 66 266 50 196617 pipe 0. 20;
#P flonum 246 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 233 242 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 233 207 30 196617 mtof;
#P newex 233 138 110 196617 expr ($i1*0.01) + 69.;
#P flonum 59 242 86 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 48 207 30 196617 mtof;
#P newex 48 158 35 196617 + 69.;
#P newex 48 138 41 196617 * 0.01;
#P number 169 63 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 244 303 91 196617 otherwise , only matches at 0;
#P connect 6 0 7 0;
#P connect 6 0 9 0;
#P connect 8 0 12 1;
#P connect 12 0 13 0;
#P connect 3 0 4 0;
#P connect 3 0 16 0;
#P connect 2 0 3 0;
#P connect 11 0 15 0;
#P fasten 10 0 12 0 71 293 217 293;
#P connect 7 0 8 0;
#P connect 7 0 11 1;
#P connect 4 0 10 0;
#P connect 4 0 5 0;
#P connect 4 0 11 0;
#P connect 14 0 2 0;
#P connect 1 0 14 0;
#P connect 14 1 6 0;
#P window clipboard copycount 22;

And this doesn’t:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 67 263 55 196617 pipe 0. 20;
#P window linecount 3;
#P comment 244 260 103 196617 for matching in binop , a flonum as
buffer is needed after mtof;
#P window linecount 1;
#P comment 148 183 97 196617 – same results , ok -;
#P window linecount 2;
#P comment 73 385 154 196617 neg results match at 0 , -7 , -11 , -14
, -25 , -32 , -39 , -50 , …;
#P comment 87 356 122 196617 pos results match at 0 , 7 , 11 , 14 ,
18 , 21 , 25 , …;
#P window linecount 1;
#P comment 65 228 246 196617 —- results are not always the same
————–;
#P flonum 58 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 48 330 33 0;
#P newex 169 82 34 196617 t i i;
#P toggle 212 330 33 0;
#P newex 212 298 31 196617 == 0.;
#P newex 48 298 143 196617 if $f1==$f2 then 1 else 0;
#P flonum 246 182 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 247 242 89 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 233 207 33 196617 mtof;
#P newex 233 138 110 196617 expr ($i1*0.01) + 69.;
#P flonum 59 242 86 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 48 207 33 196617 mtof;
#P newex 48 158 35 196617 + 69.;
#P newex 48 138 41 196617 * 0.01;
#P number 169 63 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 2;
#P comment 244 303 91 196617 otherwise , only matches at 0;
#P connect 11 0 12 0;
#P connect 2 0 3 0;
#P connect 3 0 15 0;
#P connect 3 0 4 0;
#P connect 6 0 9 0;
#P connect 6 0 7 0;
#P connect 10 0 14 0;
#P connect 13 0 2 0;
#P connect 1 0 13 0;
#P connect 13 1 6 0;
#P connect 7 0 8 0;
#P connect 7 0 11 1;
#P connect 7 0 10 1;
#P fasten 21 0 11 0 72 289 217 289;
#P connect 4 0 21 0;
#P connect 4 0 5 0;
#P connect 4 0 10 0;
#P window clipboard copycount 22;


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

#91054
Dec 19, 2006 at 6:03pm

Here’s another variation:

Even when the same value is displayed in the flonums, their inputs are
different. (though their outputs are the same!)
flonum seems to be the mediating object, but I was also able to create
this behavior with trigger f, suggesting an issue with type conversion?

Peter McCulloch

#P window setfont “Sans Serif” 12.;
#P flonum 580 185 35 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P comment 584 17 94 196620 Always Works;
#P toggle 580 252 30 0;
#P newex 580 150 42 196620 + 69.;
#P newex 580 123 49 196620 * 0.01;
#P newex 580 217 66 196620 == 0.;
#P newex 636 122 131 196620 expr ($f1*0.01)+69;
#P newex 580 76 36 196620 t f f;
#P flonum 580 42 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 375 17 94 196620 Always Works;
#P newex 371 185 24 196620 t f;
#P flonum 34 196 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 218 193 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 371 252 30 0;
#P newex 371 150 42 196620 + 69.;
#P newex 371 123 49 196620 * 0.01;
#P newex 371 217 66 196620 == 0.;
#P newex 427 122 131 196620 expr ($f1*0.01)+69;
#P newex 371 76 36 196620 t f f;
#P flonum 371 42 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 134 233 30 0;
#P newex 134 154 42 196620 + 69.;
#P newex 134 127 49 196620 * 0.01;
#P newex 134 191 66 196620 == 0.;
#P newex 190 126 131 196620 expr ($f1*0.01)+69;
#P newex 134 80 36 196620 t f f;
#P flonum 134 46 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P comment 129 22 88 196620 Doesn’t work;
#P connect 27 0 22 0;
#P connect 24 0 27 0;
#P connect 22 0 25 0;
#P connect 20 0 23 0;
#P connect 23 0 24 0;
#P connect 20 1 21 0;
#P connect 19 0 20 0;
#P connect 21 0 22 1;
#P connect 10 0 11 1;
#P connect 17 0 11 0;
#P connect 13 0 17 0;
#P connect 6 0 16 0;
#P connect 6 0 4 0;
#P connect 3 0 4 1;
#P connect 3 0 15 0;
#P connect 8 0 9 0;
#P connect 9 1 10 0;
#P connect 12 0 13 0;
#P connect 9 0 12 0;
#P connect 11 0 14 0;
#P connect 4 0 7 0;
#P connect 2 0 5 0;
#P connect 5 0 6 0;
#P connect 2 1 3 0;
#P connect 1 0 2 0;
#P window clipboard copycount 28;

#91055
Dec 19, 2006 at 6:07pm

I can confirm that there’s something unusual happening. I can’t tell
you why at this moment, having just taken a quick look at it.

Nevertheless, determining the equality of floating-point numbers is
never simple. I would not rely on “==” to do the job for you. Why
“if” works where “==” doesn’t is yet another question. As to why the
“pipe” appears to be necessary is another. Maybe one of my colleagues
has some ideas.

In any case, regardless of how SERIOUS this is (!!!! – like an
andouillette AAAA, I guess, which is fairly serious), you may have to
wait a little bit before it’s looked at and/or resolved. Thanks for
your patience.

jb

Am 19.12.2006 um 13:15 schrieb Stefan Tiedje:

> THIS IS SERIOUS I want to know why. Both version patchwise
> identical but with different behaviours below…
> The only difference in the patch is the order of object creation.
> And that must not create different behaviour !!!!
>
> I now ask the support of cycling if this is read. (No need for an
> explanation yet) And if this is confirmed. If there is no official
> reply, I’ll forward it to the support. The same is true for the
> thread about execution order in MSP. I want an answer from the
> gurus which know the inards of Max…

#91056
Dec 19, 2006 at 7:05pm

#91057
Dec 19, 2006 at 7:56pm

The methods used to add and multiply in the “+” and “*” objects are
different than that used in expr. I realize that sounds absurd, but
there are likely differences after the 6th decimal point (which we
can’t see in Max, which which are there) which are significant here
(that is, the digits beyond the significant are significant). You are
better off testing for approximate equality.

jb

#P window setfont “Sans Serif” 12.;
#P flonum 75 302 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 256 264 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 175 339 30 0;
#P window linecount 1;
#P newex 175 260 42 196620 + 69.;
#P newex 175 233 49 196620 * 0.01;
#P window linecount 2;
#P newex 175 297 214 196620 if $f1 < ($f2 + 0.000005) && $f1 > ($f2 –
0.000005) then 1 else 0;
#P window linecount 1;
#P newex 231 232 131 196620 expr ($f1*0.01)+69;
#P newex 175 186 36 196620 t f f;
#P flonum 175 152 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 5 0 8 0;
#P connect 5 0 3 0;
#P connect 3 0 6 0;
#P connect 7 0 3 1;
#P connect 2 0 7 0;
#P connect 0 0 1 0;
#P connect 1 1 2 0;
#P connect 4 0 5 0;
#P connect 1 0 4 0;
#P window clipboard copycount 9;

Am 19.12.2006 um 19:03 schrieb Peter McCulloch:

> Even when the same value is displayed in the flonums, their inputs
> are different. (though their outputs are the same!)
> flonum seems to be the mediating object, but I was also able to
> create this behavior with trigger f, suggesting an issue with type
> conversion?

#91058
Dec 19, 2006 at 8:57pm

(I first thought it was due to the mtof object.
After my post, I realized it was a deaper problem.)

Thanks all for taking this concern seriously!
A lot of patchers could be wrong.

Peter:
When putting a pipe (like in the example I posted),
it works like expected, a buffer.
In your leftmost example, a pipe between the last
operator and the binop “Always Works” too.

Stefan:
I don’t receive anymore your post in the digest mailing list.
If it’s deliberate, forgive me!

Thanks again!
And, non merci, pas d’andouillette :-)
Cheers!
Philippe

#91059
Dec 20, 2006 at 2:57am

Stefan,

“I looked at your patch, first got rid of the 0 initialisation and the pipe because they should not do anything to the result.”

I put 0 in the trigger for slightly flashing the toggles.
Most of time, we just use the print object for test purpose.
I just tried to put all what needed to clearly demonstrate the problem.
While keeping the patcher readable.

“The only difference in the patch is the order of object creation”

In your first example, you kept the flonum before the binop: works.
In your 2nd patcher, you removed it: doesn’t work.
The order of object creation is not involved.
For example, just replace the flonum by another pipe, say [pipe 0. 0]

**In all case, all object working as buffer is needed.**

Bye,
Philippe

#91060
Dec 20, 2006 at 3:39am

Hi Jeremy,

“The methods used to add and multiply in the “+” and “*” objects are different than that used in expr. I realize that sounds absurd, but there are likely differences after the 6th decimal point (which we can’t see in Max, which which are there) which are significant here(that is, the digits beyond the significant are significant). You are better off testing for approximate equality.”

So, what do you recommend: to use expr or a chain of binop?

I don’t think that an FPU equality can be a user approximation.
When, in Mathematica, I find a difference at the 29 digit, this is more than significant, it means that something *very* important is occurring.
Your ‘turnaround-the-problem’ works for it’s own purpose.

Go back to mtof and… bingo, your trick doesn’t work :-(

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 392 206 115 196617 — same results , ok —;
#P comment 8 201 193 196617 —- results are not always the same —;
#P toggle 566 294 33 0;
#P newex 566 262 31 196617 == 0.;
#P window setfont “Sans Serif” 12.;
#P comment 388 24 90 196620 Always Works;
#P comment 49 24 88 196620 Doesn’t work;
#P flonum 387 163 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 346 220 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 446 220 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 446 186 30 196617 mtof;
#P newex 387 186 30 196617 mtof;
#P toggle 387 289 30 0;
#P window setfont “Sans Serif” 12.;
#P newex 387 137 42 196620 + 69.;
#P newex 387 110 49 196620 * 0.01;
#P newex 387 259 162 196620 if $f1==$f2 then 1 else 0;
#P newex 446 110 131 196620 expr ($f1*0.01)+69;
#P newex 387 76 36 196620 t f f;
#P flonum 387 47 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 6 215 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 106 215 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window setfont “Sans Serif” 9.;
#P newex 106 164 30 196617 mtof;
#P newex 47 164 30 196617 mtof;
#P toggle 47 289 30 0;
#P window setfont “Sans Serif” 12.;
#P newex 47 137 42 196620 + 69.;
#P newex 47 110 49 196620 * 0.01;
#P window linecount 2;
#P newex 47 247 214 196620 if $f1 < ($f2 + 0.000005) && $f1 > ($f2 – 0.000005) then 1 else 0;
#P window linecount 1;
#P newex 106 110 131 196620 expr ($f1*0.01)+69;
#P newex 47 76 36 196620 t f f;
#P flonum 47 47 95 12 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P connect 7 0 10 0;
#P connect 0 0 1 0;
#P connect 1 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 7 0;
#P connect 7 0 3 0;
#P connect 3 0 6 0;
#P connect 1 1 2 0;
#P connect 2 0 8 0;
#P connect 8 0 9 0;
#P connect 8 0 3 1;
#P connect 18 0 21 0;
#P connect 11 0 12 0;
#P connect 12 0 15 0;
#P connect 15 0 16 0;
#P connect 16 0 22 0;
#P connect 22 0 18 0;
#P connect 18 0 14 0;
#P connect 14 0 17 0;
#P connect 12 1 13 0;
#P connect 13 0 19 0;
#P connect 19 0 20 0;
#P connect 19 0 14 1;
#P fasten 21 0 25 0 351 248 571 248;
#P connect 25 0 26 0;
#P fasten 20 0 25 1 451 248 592 248;
#P window clipboard copycount 29;

#91061
Dec 20, 2006 at 10:36am

On 19-Dec-2006, at 20:56, Jeremy Bernstein wrote:
> The methods used to add and multiply in the “+” and “*” objects are
> different than that used in expr. I realize that sounds absurd,

Not all that absurd.

Floating point values are passed between objects as 32-bit single-
precision. Calculations inside an object are (mostly) performed in 64-
bit double-precision. This makes a difference when mutliplying by
0.01 because in binary arithmetic you need an infinite number of bits
to exactly represent that value, and neither 32 bits nor 64 bits are
infinite.

The difference between 32-bit and 64-bit representation, Philippe, is
what you’re seeing.

But the main mistake is testing floating point values for equality.
This has been discussed numerous times on the list. If you want a
robust test, do something like [if abs($f1-$f2)<0.000001 then 1 else
0]. Floating point values are very rarely equal.

Do yourself a favor and read Peter Elsea’s tutorial on floating point
numbers. Actually, if you are the least bit serious I recommend
Donald Knuth’s _The Art of Computer Programming_ (and not just the
section on numeric representations but the entire 896 pages).

On 20-Dec-2006, at 4:39, Philippe Gruchet wrote:
> When, in Mathematica,

Expecting Max to provide infinite precision calculations, the way
Mathematica does, is simply not realistic. Mathematica contains
gazillions of highly specialized mathematical algorithms and costs
something like $1800. You’re expecting that to get all of that
wrapped inside Max/MSP? You might as well expect a Lamborghini and a
Manhattan penthouse appartment to come bundled with Max.

————– 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

#91062
Dec 20, 2006 at 3:29pm

Jeremy Bernstein wrote:
> In any case, regardless of how SERIOUS this is (!!!! – like an
> andouillette AAAA, I guess, which is fairly serious), you may have to
> wait a little bit before it’s looked at and/or resolved. Thanks for
> your patience.

Thanks Jeremy for the confirmation. The seriousness has not so many
practical implications for me, as I never really rely on float
comparisons (as you recommend correctly). But that two identicaly
patched patches behave different does throw up questions about the
underlying reliability of Max…

I am happily patient, as I suspect I am living with this for years
without problems and I am sure its problematic part is within the last
digit of floating point precision (and I am still a 7-bit Midi guy ;-)

Stefan


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

#91063
Dec 20, 2006 at 4:07pm

Jeremy Bernstein wrote:
> The methods used to add and multiply in the “+” and “*” objects are
> different than that used in expr. I realize that sounds absurd, but
> there are likely differences after the 6th decimal point (which we
> can’t see in Max, which which are there) which are significant here
> (that is, the digits beyond the significant are significant). You are
> better off testing for approximate equality.

This is less an issue for the comparison stuff, its an issue of overal
precision. Which of the two is more precise? I’d only use the more
precise one if I need it as precise as possible, which is the case for
pitch determination for example. (The speed of beating is very well
recognisable even if pitches are very close)
And the two identical patches with different results remain a mystery…

(By the way, you’re coming up faster with answers than I can read the
list, take your time… ;-)

Stefan


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

#91064
Dec 20, 2006 at 4:09pm

Philippe Gruchet wrote:
> Stefan:
> I don’t receive anymore your post in the digest mailing list.
> If it’s deliberate, forgive me!

If you don’t get this digested, you should ask the list moderator… ;-)

Stefan


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

#91065
Dec 20, 2006 at 4:23pm

Philippe Gruchet wrote:
> I put 0 in the trigger for slightly flashing the toggles.

I use a bang behind an object if I want to see a flash if it received a
message. Much more visible…


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

#91066
Dec 20, 2006 at 9:48pm

On 20-Dec-2006, at 17:07, Stefan Tiedje wrote:

> This is less an issue for the comparison stuff, its an issue of
> overal precision. Which of the two is more precise?

Data sent through patch cords can only be 32-bit. Period. Ende der
Durchsage.

Objects can, if they are programmed accordingly, perform 64-bit
floating point calculations internally. Most objects use double-
precision because it is actually *faster* than single-precision on
PPC and Pentium chips.

expr presumably uses 64-bit, but the only way to know for sure is to
look at the source code.

————– 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

#91067
Dec 21, 2006 at 2:25am

Hi Peter,

> The difference between 32-bit and 64-bit representation,
> Philippe, is what you’re seeing.

You’re right! As always ;-)
And I’m feeling okay with floating point numbers.
(We are talking about math here, not about what we are doing with.)
But, when I see 443.060455 from a chain of operators, and 443.060516 from the expression object, I can’t deal with a such discrepancy as a user subjective approximation of what’s the best result.
If I dropped a word a bout Mathematica, this was for pointing out that I can put anywhere the limits I want or need.
Here, the limits are imposed by the unknown FPU precision of such or such processing object, unless…

“the only way to know for sure is to look at the source code”

Of course, no, I don’t have the time for.
Nor the money for “a Lamborghini and a Manhattan penthouse apartment” :-)

Thanks for your participation in this thread.
Kind regards,
Philippe

#91068
Dec 21, 2006 at 2:41am

Quote: Stefan Tiedje wrote on Wed, 20 December 2006 09:09
—————————————————-
> Philippe Gruchet wrote:
> > Stefan:
> > I don’t receive anymore your post in the digest mailing list.
> > If it’s deliberate, forgive me!
>
> If you don’t get this digested, you should ask the list moderator… ;-)

No, I just received the notification of your post about this thread because I firstly clicked “Subscribe to topic” for this particular topic on the onboard forum.
I you go there and click the “Subscribe to… mailing list” link, I’ll receive each of your post.
I personally subscribed to MaxMSP, Pluggo and Javascript on the forum website and I receive all the mails from users who did the same.

Bye,
Philippe

#91069
Dec 21, 2006 at 9:14am

Peter Castine wrote:
> Data sent through patch cords can only be 32-bit. Period. Ende der
> Durchsage.
>
> Objects can, if they are programmed accordingly, perform 64-bit
> floating point calculations internally. Most objects use double-
> precision because it is actually *faster* than single-precision on PPC
> and Pentium chips.
>
> expr presumably uses 64-bit, but the only way to know for sure is to
> look at the source code.

Thanks for the clarification… If I want it precise as possible, I pack
all into an expr. This is a good excuse to use expr more often…
(Without looking at the source, the difference is explained clearly, as
the two object version has to connect with patch chords und thus must be
the one which is less precise…)

Stefan


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

#91070
Dec 21, 2006 at 10:46am

#91071
Dec 21, 2006 at 11:09am

Undersigned wrote:
> Data sent through patch cords can only be 32-bit.

Actually, it’s occurring to me that even that needs to be confirmed
by someone who has the source code. I think the claim is correct,
from examining the API it *looks* like that. But life is full of
surprises.

– Peter

————– 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

#91072
Dec 21, 2006 at 11:18am

That is currently the case. A_FLOAT is a 32-bit float.

jb

Am 21.12.2006 um 12:09 schrieb Peter Castine:

> Undersigned wrote:
>> Data sent through patch cords can only be 32-bit.
>
> Actually, it’s occurring to me that even that needs to be confirmed
> by someone who has the source code. I think the claim is correct,
> from examining the API it *looks* like that. But life is full of
> surprises.
>
> — Peter

#91073
Dec 21, 2006 at 12:59pm

Peter,

> You, as a programmer, will have to find a way to present Max’
> calculations to the end user in an appropriate form. This may take
> a bit of added work, and some battle with Max’ idiosyncrasies.

That’s right. Go back to my buzz who could become a sound… and why
not some music ;-)

Bye,
Philippe

#91074
Dec 21, 2006 at 12:59pm

#91075

You must be logged in to reply to this topic.