PhiDjee

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 

To add a test, the results are then compared through a conditional 

(1) [expr] -> [mtof] -> [if] works fine, the expression object 

(2) here again, I have to put a flonum between mtof and the binop. Why?

I'd like very much to understand this... behaviour?

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?

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

problem-with-mtof-and-buffers

> 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 

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 

It seems that some of the important issues get lost with the new amount 

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


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?

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?

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 

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 

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 

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.

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


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.

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 

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.

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


(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!

When putting a pipe (like in the example I posted),

In your leftmost example, a pipe between the last

operator and the binop "Always Works" too.

I don't receive anymore your post in the digest mailing list.

(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


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

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

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.

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]

"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 :-(

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.

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,

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 

The difference between 32-bit and 64-bit representation, Philippe, is 

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

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.

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

Interface Building for |home | chez nous|

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

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,

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

> 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 

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 

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

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

> 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 

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

> I don't receive anymore your post in the digest mailing list.

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

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

> 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 

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

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 

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 

expr presumably uses 64-bit, but the only way to know for sure is to 

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

> The difference between 32-bit and 64-bit representation,

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.

Problem with mtof and... buffers?