Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
in my patches i often need mathematical manipulation of lists of floats, which is not very convenient with internal objects. What about adding new verbs to the list objects, including often used mathematical operations? I would be thankful for + - * / in the beginning, but of course all kinds of unary and binary operations would be handy. Sure i know of Franks abstractions, but speed is an issue.
I agree with you here. With the [list]-abs I also want to offer a suggestion, how these objects could look like. I intended to loosly follow the standard set by the builtin list objects and of course they should work with plain Pd as well.
However as they are abstractions, their internals can be replaced by (external) objects tuned for speed without having to change any of the patches, that use the [list]-abs-abstractions, because the "API" stayed the same. I'm about to create a version of [list]-abs that does just this: [list-drip] with using [drip] internally etc. With some "-path"-trickery this can be used as needed, if the used externals are available, or not, if using plain Pd is necessary (like in some workshops or on PDa).
Regarding your suggestion of speeding up list-math: What about extending [expr] to handle lists as well? Maybe a new variable could deal with this like $l1, $l2, ..., so that things like this would be possible: [expr $f1 * $l1].
I didn't think too much about the best syntax for list-expr yet, like when should the result be a list, when should it be a scalar, how to handle the two kinds of multiplication possible with [expr $l1 * $l2] (inner product with a scalar result vs. element-wise product to a list), what to do with "mixed" lists that also include symbols and gpointers etc., but the basic concept looks very useful to me.
Besides that, a [list drip|serialize] and negative indices for [list split] - see my patch in the SF tracker - would be *very* handy.
Ciao