jhindsight

bit weird this. i'm sending match lists of 3 integers from my monome and it behaves as expected except for when i send the list

when i send it this list match first returns a really high negative number then the list 1 1 1. you have to check the max window to see the negative number. anyone know what's going on?

bug-in-match-object

I don't know if it's a bug but it's strange.

The behavior you mention only seems to occur when [match] has a wildcard (nn) as the first argument. What's interesting is that given your match arguments of nn 1 nn and your input of $1 1 1 - you can have ANY value in the first position and you won't get the -2147483648 error.. UNLESS the first value is a 1. ANY other value (symbol, int, float, whatever) will not give you the -2147483648 output. So why would that be?

Keep in mind that while -2147483648 is the lowest possible 32-bit number, it's also not always treated as number, but as an expression that refers to an undefined value.. something larger than Max can handle.

It's almost as if [match] defines the first nn as the positive limit of all possible integer values (2147483647) and at some point along the line internally "adds" the first input received to nn. So if the input is a 0, it's within the 32-bit range (2147483647 + 0 = 2147483647) . If it's a 2... 2147483647 + 2 is 2147483649 (too large) so it 'flips' to -2147483647 which is within the 32-bit range. If it's a -1.. 2147483647 + -1 = 2147483646. No problem. But if it's a 1.. 2147483647 + 1 is 2147483648.. which is too big for 32-bit so it flips to -2147483648 which Max interprets as 'undefined'. Or something like that. I'm curious about other thoughts on this.

If you need your output free of -2147483648, you can append a symbol at the end of your input list and remove it after the match object. For some reason [match] handles the first input differently if the final argument is a symbol.

The behavior you mention only seems to occur when [match] has a wildcard (nn) as the first argument.  What's interesting is that given your match arguments of nn 1 nn and your input of $1 1 1 -  you can have ANY value in the first position and you won't get the -2147483648 error..   UNLESS the first value is a 1.  ANY other value (symbol, int, float, whatever) will not give you the -2147483648 output.  So why would that be?

Keep in mind that while -2147483648 is the lowest possible 32-bit number, it's also not always treated as number, but as an expression that refers to an undefined value.. something larger than Max can handle.   

It's almost as if [match] defines the first nn as the positive limit of all possible integer values (2147483647) and at some point along the line internally "adds" the first input received to nn.  So if the input is a 0, it's within the 32-bit range (2147483647 + 0 = 2147483647) .   If it's a 2...  2147483647 + 2 is 2147483649 (too large) so it 'flips' to -2147483647 which is within the 32-bit range.  If it's a -1.. 2147483647 + -1 = 2147483646.  No problem.  But if it's a 1..  2147483647 + 1 is 2147483648.. which is too big for 32-bit so it flips to -2147483648 which Max interprets as 'undefined'.  Or something like that.  I'm curious about other thoughts on this.

If you need your output free of -2147483648, you can append a symbol at the end of your input list and remove it after the match object.  For some reason [match] handles the first input differently if the final argument is a symbol.

oops yeah you're right i'm trying to match the column (first integer in the list) with the row and state as wildcards so my match object and set message should both be [match $1 nn nn] but my idiocy did unveil this strange behaviour.

Match doesn't take $1 syntax. I think what you meant to say is create a message box with [set $1 nn nn] and feed it values in the left inlet.. then output the result to the match object. That will set the match object with 1 nn nn, 2 nn nn, 3 nn nn, etc. In that case, there won't be any problem with undefined errors...

Match doesn't take $1 syntax.  I think what you meant to say is create a message box with [set $1 nn nn] and feed it values in the left inlet..  then output the result to the match object.  That will set the match object with  1 nn nn, 2 nn nn, 3 nn nn, etc.    In that case, there won't be any problem with undefined errors...


yeah that's what i meant. sorry having a complete brain fart day.

bug in match object?