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
Hi all,
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.
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
I'm more worried about bug fixes and new platgorms (a64; macintel) at the moment, though...
cheers Miller
On Tue, Apr 18, 2006 at 09:50:02AM +0800, Chris McCormick wrote:
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
Hallo, Miller Puckette hat gesagt: // 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.
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
If Pd would get "list length" as well, then negative indices could be emulated easily with an abstraction like [list-splat], so if you don't like negative indices from an aestethic point of view ;) they wouldn't be needed anymore with [list length]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 19 Apr 2006, Frank Barknecht wrote:
If Pd would get "list length" as well, then negative indices could be emulated easily with an abstraction like [list-splat], so if you don't like negative indices from an aestethic point of view ;) they wouldn't be needed anymore with [list length]
[list length] already isn't "needed", it's just that to find the length of a list of length 1000 it takes 499500 steps, and doubling the list length makes it take four times more steps. You just have to upgrade your CPU ;-)
But seriously, if Pd had more primitives it'd be less primitive.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[list length] already isn't "needed", it's just that to find the length of a list of length 1000 it takes 499500 steps, and doubling the list length makes it take four times more steps. You just have to upgrade your CPU ;-)
Hey, I cannot even compute that number with my builtin CPU and have to use a synthetic calculator for this:
(fbar)-> $ python Python 2.2.2 (#1, Mar 17 2003, 15:17:58) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
499500 * 4
1998000
Oops, that's almost two million steps...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 19 Apr 2006, Miller Puckette wrote:
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
Ok, so you want people to do it like this instead?
| [t l l] | | | [list length] | | | [- ] <--- feed me | | [list nth] |
well, people can use this. the question is, how many will get bored with the circumlocution. Why not adapt the rest of Pd so that it accepts negative indices?
Also, what do you think of using an abstraction for the complex product on signals and actually using it in the example patches? What if your Pd actually came with abstractions? We want to see your abstractions.
I'm more worried about bug fixes and new platgorms
Yeah, I'd be worried about new flatworms too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Perhaps, if it's done frequently (I have no idea...) we just need a different name for it... "rnth" or something.
On Wed, Apr 19, 2006 at 01:02:14PM -0400, Mathieu Bouchard wrote:
On Wed, 19 Apr 2006, Miller Puckette wrote:
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
Ok, so you want people to do it like this instead?
| [t l l] | | | [list length] | | | [- ] <--- feed me | | [list nth] |
well, people can use this. the question is, how many will get bored with the circumlocution. Why not adapt the rest of Pd so that it accepts negative indices?
Also, what do you think of using an abstraction for the complex product on signals and actually using it in the example patches? What if your Pd actually came with abstractions? We want to see your abstractions.
I'm more worried about bug fixes and new platgorms
Yeah, I'd be worried about new flatworms too.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Apr 19, 2006 at 01:02:14PM -0400, Mathieu Bouchard wrote:
On Wed, 19 Apr 2006, Miller Puckette wrote:
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
Ok, so you want people to do it like this instead?
| [t l l] | | | [list length] | | | [- ] <--- feed me | | [list nth] |
You can do negative indicies of a list with a single modulus operator tuned to the length of the list:
list index to look up
|
| [r mylist]
| |
| [list length]
| |
[r mylist] [mod] | | [list split] |
Chris.
chris@mccormick.cx http://mccormick.cx
On Thu, 20 Apr 2006, Chris McCormick wrote:
list index to look up | | [r mylist] | | | [list length] | |[r mylist] [mod] | | [list split] |
this doesn't work, because the final list index is computed before the list comes in, so it can't have the correct modulo. You'd need to add [t b a] and [t a a] in appropriate places to ensure correct order.
Alternatively, you can [swap]ify the [mod] to avoid having to bang it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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
On Apr 19, 2006, at 11:50 AM, Miller Puckette wrote:
I'm more worried about bug fixes and new platgorms (a64; macintel) at the moment, though...
...besides removing the configure/makefile define for PA_BIG_ENDIAN
on MACOSX compiles, you may wish to use this version of portaudio:
cvs -d:pserver:anonymous@www.portaudio.com:/home/cvs co -r v19-devel
portaudio
...it includes better coreaudio integration and sets endianness
correctly if it isn't already...freetype's a hangup on GEM, atm...
jamie
ps: extra bonus points awarded for incorporating the new tcl/tk
framework's behavior of including both aqua and x11 versions!
hi
the original feature request was a [symbol2list] or whatever it is called. i'd like to focus on this again, since there is no possibility yet in native pd to split symbols into list, whereas the other mentionend tasks already can be realized, though they are quite cpu-expensive when realized as abstractions, compared to pd-primitives (though this seems to be less important in my eyes).
cheers roman
Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
Hi all,
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.
The negative index thing for "nth" sounds like a bad idea, out of keeping with Pd's more usual style of limiting out-of-range values to the end of the range in question.
I'm more worried about bug fixes and new platgorms (a64; macintel) at the moment, though...
cheers Miller
On Tue, Apr 18, 2006 at 09:50:02AM +0800, Chris McCormick wrote:
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Apr 18, 2006, at 3:50 AM, Chris McCormick wrote:
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?
Yes, I think it would. Plus if its a clean patch, then we can easily
include it in Pd-extended until its in Miller's Pd.
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
james tittle -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli