On Wed, Apr 19, 2006 at 08:50:02AM -0700, Miller Puckette wrote:
I'm thinking of adding "parallelize" and "serialize" options to list that (I think) would include the function of "drip"... and I think I should add "list length" too.
So parallelize and serialize would be inverses of eachother? Sounds good. I think that these three constitute the minimal set of builtins required to speed up what currently has to be done using [until].
Best rgds,
Chris.
On Wed, Apr 12, 2006 at 12:01:29PM +0200, pd-list-request@iem.at wrote:
Date: Wed, 12 Apr 2006 10:14:46 +0200 From: Frank Barknecht fbar@footils.org Subject: Re: [PD] feature request for [list]
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
So basically I'd like to see a [list length] and an [s2l].
You can do "list length" with a simple counter and "list split" already. It's called [list-len] in [list]-abs. However unfolding a list using [until] and [list split] is very slow. I did benchmarks comparing it to [drip] and it takes ages longer. As a "drip" operation is used so often - Matju once compared it to the "for"-loop of other languages - it is important that "drip" is fast, and not only fast, but very fast. I'd much prefer to have a fast unfolding operation over getting "list length".
Yes, good point.
And negative indices are just very convenient, and the object is already in.
I don't think that [s2l] should become part of [list]. To me it is a typical string operation, like Perl's split and string.split() in Python.
Agreed. If someone made patches against Miller's Pd and put it in SF patch tracker would these probably make it in?
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
chris@mccormick.cx http://mccormick.cx