Platform-specific Stack Overflow problem

I am using Max/MSP 4.6.2 on multiple platforms: MacPPC, MacIntel,
and XP. On MacIntel and XP, the following patch works fine – click
the button at the top, and it will do its thing (actually a whole lot
of nothing, in this stripped down patch). On MacPPC though, clicking
the button will yield a Stack Overflow error.

To reproduce the error, create a text file called "Foo.txt" wherever
you save the patch. Also curiously, if you change the number 64 in
the patch to 63 or some other lower number, it will work without the
stack overflow.

Quote: Dan Nigrin wrote on Wed, 07 March 2007 13:29
—————————————————-
> Hoping someone can help me figure this out.
>
> I am using Max/MSP 4.6.2 on multiple platforms: MacPPC, MacIntel,
> and XP. On MacIntel and XP, the following patch works fine – click
> the button at the top, and it will do its thing (actually a whole lot
> of nothing, in this stripped down patch). On MacPPC though, clicking
> the button will yield a Stack Overflow error.
>
> To reproduce the error, create a text file called "Foo.txt" wherever
> you save the patch. Also curiously, if you change the number 64 in
> the patch to 63 or some other lower number, it will work without the
> stack overflow.

OK, here’s a further stripped down patch that still shows the same behavior – only stack overflow on MacPPC (OS 10.4.8), not on MacIntel or XP.

>> I am using Max/MSP 4.6.2 on multiple platforms: MacPPC, MacIntel,
>> and XP. On MacIntel and XP, the following patch works fine – click
>> the button at the top, and it will do its thing (actually a whole lot
>> of nothing, in this stripped down patch). On MacPPC though, clicking
>> the button will yield a Stack Overflow error.
>>
>> To reproduce the error, create a text file called "Foo.txt" wherever
>> you save the patch. Also curiously, if you change the number 64 in
>> the patch to 63 or some other lower number, it will work without the
>> stack overflow.

On different machines, different stack sizes are permitted.
Everywhere you have non terminal feedback in your patch, you are
growing the stack size. You have recursion in your patch that you
should try to change to an iterative approach. Most recursive
algorithms can be represented in an iterative form–e.g. rather than
using non terminal feedback, use something like uzi to trigger an
single graph traversal one at a time. If you need more complex case
handling you can use a gate to exit the calculation (as I’ve done in
the example below), and if you need to cache values for each
sequential iteration you can use the right inlet of the float or int
object to store the result of one iteration for use the next time.

At 7:59 AM -0800 3/8/07, Joshua Kit Clayton wrote:
>On different machines, different stack sizes are permitted.
>Everywhere you have non terminal feedback in your patch, you are
>growing the stack size. You have recursion in your patch that you
>should try to change to an iterative approach. Most recursive
>algorithms can be represented in an iterative form–e.g. rather than
>using non terminal feedback, use something like uzi to trigger an
>single graph traversal one at a time. If you need more complex case
>handling you can use a gate to exit the calculation (as I’ve done in
>the example below), and if you need to cache values for each
>sequential iteration you can use the right inlet of the float or int
>object to store the result of one iteration for use the next time.
>
>http://www.google.com/search?q=recursive+iterative+algorithms+comparison
>
>Hope this helps. In general, it’s something important to learn for
>advanced max use.