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
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
