[PD] (breaking symbols) was Re: find a list of numbers in a text file

Mathieu Bouchard matju at artengine.ca
Sun Aug 7 20:37:52 CEST 2011


On Wed, 3 Aug 2011, Jonathan Wilkes wrote:

> The idiosyncratic recursion happens when combining the single digits to 
> make the final two values of the numerator and denominator.  It's a 
> [list split 1] with the middle outlet to a [t a] that feeds back into 
> the left inlet.  This outputs the list backwards-- I'm not exactly sure 
> why, but it's handy in this case because I can just multiply each digit 
> by increasing powers of ten and accumulate to get the final value for 
> the numerator.  (Same process for the denominator.)  There's the danger 
> of a stack overflow, but it's unlikely that either part of the fraction 
> would have more than 249 digits.

I think I had made such a recursion in an intermediate version of 
[list-drip] that I didn't publish, which might have been a bit faster, but 
having a limit of 200 or 300 levels wasn't fine at all. Who would I be to 
say that people can't have uses for more elements than that ? That's why I 
made a half-half splitter which uses only log2(n) recursion levels, which 
means it's only one more level for each time you double the list size.

> Actually now that I look at it, there should be a much greater danger of 
> a stack overflow in the outer loop, because there are seven objects 
> involved in the recursion. Not sure I understand the relationship 
> between # of objects in recursive chain and max # function calls before 
> stack overflow.

Yeah, for Pd, it's a matter of maximum number of levels of calls, whereas 
for the OS, what matters is the total size in bytes. You'll normally reach 
Pd's limit a lot faster. The number of levels of calls is the number of 
calls per recursion times the number of recursions.

IIRC, much older versions of Pd used a stack size check in bytes, but it 
caused problems real quickly. I don't remember whether the change had to 
do with the introduction of the [list] classes, which use stack-allocated 
buffers.

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC


More information about the Pd-list mailing list