Hi,
I just found out that the new [list length] from Pd-0.40 counts the length of messages slightly unusual. Counting the elements in a meta-message like "walk the dog" will leave out the first element, "walk" in the example, and give a result of 2. The proper list message "list walk the dog" however will count as 3.
This gets even more confusing with the other example in the list-help.pd file: "1 x y" has a list-length of 3, however "x 1 y" only has a list-length of 2.
And it gets quite nasty with an argument-less meta-message like "set", which has a list-length of 0 just like the "real" empty list: a "bang"-message.
I can see the logic behind this (counting only the arguments to a message but not the selector). But as all other [list] objects besides [list trim] automatically convert incoming meta-messages to list-messages I think I would expect the same to happen for [list length].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Tue, 24 Oct 2006, Frank Barknecht wrote:
I just found out that the new [list length] from Pd-0.40 counts the length of messages slightly unusual. Counting the elements in a meta-message like "walk the dog" will leave out the first element, "walk" in the example, and give a result of 2. I can see the logic behind this (counting only the arguments to a message but not the selector).
This seems consistent with how messageboxes handle it. (This doesn't mean that it's a good idea)
But as all other [list] objects besides [list trim] automatically convert incoming meta-messages to list-messages I think I would expect the same to happen for [list length].
I consider this to be a bug in pd. In the meanwhile, use a dummy [list] before every use of [list length] in order to force a cast.
_ _ __ ___ _____ ________ _____________ _____________________ ... | 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:
This seems consistent with how messageboxes handle it. (This doesn't mean that it's a good idea)
I'm not sure myself, what's The Right Thing to do here. Omitting the automatic conversion to list-message in "list length" makes it possible to easily just count the arguments without selector, and with an additional "list" as you mention below it's still possible to count "all" elements including selector.
However I wonder why would anybody want to only do the former: count arguments and omiting the selector in a meta message...
But as all other [list] objects besides [list trim] automatically convert incoming meta-messages to list-messages I think I would expect the same to happen for [list length].
I consider this to be a bug in pd. In the meanwhile, use a dummy [list] before every use of [list length] in order to force a cast.
To clarify: What exactly do you consider a bug here? The automatic conversion in the other list-object operations or the missing conversion in "list length"?
I'm using an additional "list" in the 0.40 version of list-len.pd now which for pd 0.39 was constructed manually with a recursive "list split 1" and a counter, so it does the conversion automatically.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Oct 24, 2006, at 7:18 AM, Frank Barknecht wrote:
Hi,
I just found out that the new [list length] from Pd-0.40 counts the length of messages slightly unusual. Counting the elements in a meta-message like "walk the dog" will leave out the first element, "walk" in the example, and give a result of 2. The proper list message "list walk the dog" however will count as 3.
This gets even more confusing with the other example in the list-help.pd file: "1 x y" has a list-length of 3, however "x 1 y" only has a list-length of 2.
And it gets quite nasty with an argument-less meta-message like "set", which has a list-length of 0 just like the "real" empty list: a "bang"-message.
I can see the logic behind this (counting only the arguments to a message but not the selector). But as all other [list] objects besides [list trim] automatically convert incoming meta-messages to list-messages I think I would expect the same to happen for [list length].
I think this logic makes sense, but I haven't played with it yet.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this logic makes sense, but I haven't played with it yet.
You don't need to play with it much, it's a decision to make: Do you want to have [list length] give the same length for "1 2 3" and "a b c" and "list a b c" or should "a b c" be one less?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 2006-10-27 at 07:46 +0200, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this logic makes sense, but I haven't played with it yet.
You don't need to play with it much, it's a decision to make: Do you want to have [list length] give the same length for "1 2 3" and "a b c" and "list a b c" or should "a b c" be one less?
i think it is at least consistent in the sense, how list-objects work generally. would you want [list length] to count the selector in a list starting with a number as well? [1 2 3( -> 4, like [list a b c( -> would give 4 then?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i think it is at least consistent in the sense, how list-objects work generally. would you want [list length] to count the selector in a list starting with a number as well? [1 2 3( -> 4, like [list a b c( -> would give 4 then?
list-objects generally add a list-selector automatically, and then start their operations. list trim is the exception of course, it removes the list-selector.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Oct 27, 2006, at 1:46 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this logic makes sense, but I haven't played with it yet.
You don't need to play with it much, it's a decision to make: Do you want to have [list length] give the same length for "1 2 3" and "a b c" and "list a b c" or should "a b c" be one less?
What I meant is that I can't think of good examples to test this
theory. That's the next step, real world examples.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
What I meant is that I can't think of good examples to test this
theory. That's the next step, real world examples.
The existing length calculators I know for Pd count excluding the list-selector and including "meta"-selectors: [length] from zexy, [zl len] from Cyclone. See attached.
Length in list-len.pd in the traditional way is calculated by serializing the list using [list split 1] and [list append], which drive a counter. I embedded it into the attached example as a subpatch. Here the conversion of meta-messages to list-messages is happening automatically as well, so this construct counts unlike [list length] as well.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2006-10-30 at 23:04 +0100, Frank Barknecht wrote:
Length in list-len.pd in the traditional way is calculated by serializing the list using [list split 1] and [list append], which drive a counter. I embedded it into the attached example as a subpatch. Here the conversion of meta-messages to list-messages is happening automatically as well, so this construct counts unlike [list length] as well.
finally i understand, what you [list length] want to behave like. and in my eyes it makes a lot of sense now. from what you are saying i would also expect, that any [list]-object (besides [list trim]) prepends the list-selector to the incoming messages, but it doesn't here for whatever reason.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hmm, I think the design is, in fact, wrong. But should I now fix it (incompatibly)? drat.
M
On Tue, Oct 31, 2006 at 11:10:57PM +0100, Roman Haefeli wrote:
On Mon, 2006-10-30 at 23:04 +0100, Frank Barknecht wrote:
Length in list-len.pd in the traditional way is calculated by serializing the list using [list split 1] and [list append], which drive a counter. I embedded it into the attached example as a subpatch. Here the conversion of meta-messages to list-messages is happening automatically as well, so this construct counts unlike [list length] as well.
finally i understand, what you [list length] want to behave like. and in my eyes it makes a lot of sense now. from what you are saying i would also expect, that any [list]-object (besides [list trim]) prepends the list-selector to the incoming messages, but it doesn't here for whatever reason.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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:
Hmm, I think the design is, in fact, wrong. But should I now fix it (incompatibly)? drat.
I think you should. I don't think many people have used the length operation of [list] so far, as 0.40 still is quite new and there isn't a pd-extended version of 0.40, so I'd guess it's not widely in use yet. In fact, only those users, who explicitly wanted to count *without* meta-selectors will have to adapt their patches and I guess the number of users who wanted this is even smaller. So now's the time for change! ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 1 Nov 2006, Miller Puckette wrote:
Hmm, I think the design is, in fact, wrong. But should I now fix it (incompatibly)? drat.
I think you should change it, because I doubt that anyone has found a use for the behaviour of [list length] that would be changed.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Frank Barknecht -
Hans-Christoph Steiner -
Marius Schebella -
Mathieu Bouchard -
Miller Puckette -
Roman Haefeli