Hallo!
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messages
just some more suggestions (these objects are often the reason why I have to use externals in simple patches):
1) a storage object for lists would also be useful in main-pd (like "lister" from zexy - maybe the easiest way would be to make a 2.inlet at the "list" object (to have the same behaviour as "symbol" or "float" ...) ?
2) get a specific element from a list (like "packel" from zexy) - so it's easier to handle dynamic length list (if you know which atoms you want and don't know the exact length) don't know a good name, maybe "list get" or "list packel" (IOhannes: why packel?) (also I don't if it is a good idea to count the elements from 1 and not from 0 - like in packel ...) -> maybe also a "list set", where you can set a specific element in a list without unpack - repack everything (which is not possible if you don't know the exact size ...)
All of these would expect the "list" selector at the head of messages,
with
the exception of plain "list"; all of them would output "list" messages
except
"list selector". These would work as follows:
Hm - I see, but what is the advantage of only handle messages with list-selector (beside that you can use the name "list" for the objects ... :) ? This means you often have to:
| [list] - add a list selector | do something like [list reverse] | [list selector] - remove again the list selector |
(should it also be possible to remove the list selector at all with "list selector" ?)
But, just some thoughts ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Hallo!
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messages
just some more suggestions (these objects are often the reason why I have to use externals in simple patches):
- a storage object for lists would also be useful in main-pd (like "lister"
from zexy - maybe the easiest way would be to make a 2.inlet at the "list" object (to have the same behaviour as "symbol" or "float" ...) ?
I think, "list append" would be just that. However I agree that using the plain "list" for this would feel more natural compared to the other Pd types symbol and float.
A further suggestion by me would be to maybe add a kind of combination "list first" and "list last", that is: Give "first" a second outlet wich outputs the rest of the list.
Reading through the planned actions, it might be useful to take a look at the max object [zl] which is also available in Cyclone. For those who don't know it, I attached the help file. I sometimes used it, but not too often yet to say anything about which operations would be useful to have in a Pd "list" object as well.
Another collection to consider would be the Lobjects externals for Max. PDF doc here: ftp://arts.ucsc.edu/pub/ems/lobjects/LObjs_doc.pdf
However Lobjects is a really huge collection of list operations, some of which might be better off as being implemented in externals (for now).
Ciao
On Wed, 20 Jul 2005, Frank Barknecht wrote:
However Lobjects is a really huge collection of list operations, some of which might be better off as being implemented in externals (for now).
The idea should be to be able to do all list handling without externals. One approach to this would be to think about how to implement typical operations with the set of proposed messages as abstraction.
Someone wants to try "sort" ? Who knows, maybe there is an elegant counter like implementation, bubblesort, quicksort .. or should sort be part of the list API ?
The list container should be list <noarg> probably ?
Guenter
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
Hallo, Guenter Geiger hat gesagt: // Guenter Geiger wrote:
On Wed, 20 Jul 2005, Frank Barknecht wrote:
However Lobjects is a really huge collection of list operations, some of which might be better off as being implemented in externals (for now).
The idea should be to be able to do all list handling without externals. One approach to this would be to think about how to implement typical operations with the set of proposed messages as abstraction.
Yes, I agree. For that a complete set of basic operations would be very useful. Probably there already is some theory available about this somewhere. Will the real IT students/scientists please stand up?
Someone wants to try "sort" ? Who knows, maybe there is an elegant counter like implementation, bubblesort, quicksort .. or should sort be part of the list API ?
[zl] also has "union" and "sect" which remove duplicates rsp. sends out only common elements in two lists.
[zl] has another interesting property: It is possible to dynamically change the mode of operation. E.g. [zl join] joins two lists. But if you send a "mode slice 2" to it, it will transform itself to be a list slicer (and send out the first 2 elements and the rest). This could be handy, though I'm not if it isn't a bit too smart.
Ciao
- a storage object for lists would also be useful in main-pd (like "lister"
from zexy - maybe the easiest way would be to make a 2.inlet at the "list" object (to have the same behaviour as "symbol" or "float" ...) ?
I think, "list append" would be just that. However I agree that using the plain "list" for this would feel more natural compared to the other Pd types symbol and float.
There's a delicate problem with "list" sprouting an inlet to store lists... what do you do when someone "bangs" it? If "bang" is to be considered as the same thing as an empty list, then the correct thing would be to replace the stored list with an empty one, then output it -- but that would make it impossible ever to get the stored list back out!
On the other hand, perhaps "list" should be taken to mean "list append" and to just prepend a "list" selector should be some more special name like "list listify". Seems to me that's more ugly than having to use "append" to store lists, but maybe there's a third way somewhere...
cheers Miller
A further suggestion by me would be to maybe add a kind of combination "list first" and "list last", that is: Give "first" a second outlet wich outputs the rest of the list.
Seems like this would be a great convenience. Maybe I should just omit "list first" and "list last" and replace them with a "list split" that splits it in two at any desired point.
Reading through the planned actions, it might be useful to take a look at the max object [zl] which is also available in Cyclone. For those who don't know it, I attached the help file. I sometimes used it, but not too often yet to say anything about which operations would be useful to have in a Pd "list" object as well.
My own motivation is to make it possible to write libraries such as RRADical (especially RRADical!) without needing to include other libraries (which is confusing, especially because of the two competing "prepend" objects.) So if you can name any other functionality you'd need beyond what's here I'll certainly want to put it in. (Not even limited to the list object...)
cheers Miller
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
There's a delicate problem with "list" sprouting an inlet to store lists... what do you do when someone "bangs" it? If "bang" is to be considered as the same thing as an empty list, then the correct thing would be to replace the stored list with an empty one, then output it -- but that would make it impossible ever to get the stored list back out!
That's indeed a delicate situation, which I didn't think of.
A further suggestion by me would be to maybe add a kind of combination "list first" and "list last", that is: Give "first" a second outlet wich outputs the rest of the list.
Seems like this would be a great convenience. Maybe I should just omit "list first" and "list last" and replace them with a "list split" that splits it in two at any desired point.
I think I'd prefer "split" over "first" and "last" (but maybe the Lisp people would even prefer something else... ;)
My own motivation is to make it possible to write libraries such as RRADical (especially RRADical!) without needing to include other libraries (which is confusing, especially because of the two competing "prepend" objects.) So if you can name any other functionality you'd need beyond what's here I'll certainly want to put it in. (Not even limited to the list object...)
I did a little check what externals I used in the state savingi part of RRAD, and those are not many. In fact, apart from OSC and [pool] I only depend on "prepend" and for some OSC-related operations I use fromsymbol/tosymbol to modify the first element of a list (change "/s/c 1 2 3 ..." to "/o/s/c 1 2 3 ...")
I think, having OSC available as internal in Pd could be very useful: It has become a kind of standard for communication between (multimedia) software and IMO is now almost as important as Midi-IO.
A kind of more general key/value container (like an extended textfile/coll/qlist) also is something, that many people seem to look for and only find in externals as coll, pool, pbank, etc.
Ciao
Something like a python dictionary?
how does the PDcontainer stuff relate this this? (oh so much to keep track of! I gotta get that external searching prototype going...
B>
Frank Barknecht wrote:
A kind of more general key/value container (like an extended textfile/coll/qlist) also is something, that many people seem to look for and only find in externals as coll, pool, pbank, etc.
Ciao
On Thu, 21 Jul 2005, Frank Barknecht wrote:
I think I'd prefer "split" over "first" and "last" (but maybe the Lisp people would even prefer something else... ;)
In Perl, Python, Ruby, etc., split is a string operation that generates a list of strings according to where a certain pattern was found. E.g. if the pattern is /\s*-\s*/ which means "a dash surrounded by any number of spaces, maybe none", then
"-hello- blah blah - foo bar -" .split /\s*-\s*/
gives
["", "hello", "blah blah", "foo bar"]
a list of four elements (trailing delimiters are ignored).
The above sample code is in Ruby: "" are string delimiters // are pattern delimiters . means send message split is a method selector [] are list delimiters , are list element delimiters.
The Tcl language has a similar proc split but works like C's strtok() instead of using regexp patterns.
A list-oriented split probably should do something similar and thus it would need to output any number of lists (possibly bundled in a list themselves).
The "split" that Frank suggests, afaik, doesn't exist in the above languages; the closest is the "splice" of Perl and the "slice!" of Ruby (and I don't know enough Python or Tcl)
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Wed, 20 Jul 2005, Miller Puckette wrote:
On the other hand, perhaps "list" should be taken to mean "list append" and to just prepend a "list" selector should be some more special name like "list listify". Seems to me that's more ugly than having to use "append" to store lists, but maybe there's a third way somewhere...
I think that having "append" as the default behaviour is au contraire something quite clever in that context. That is, _if_ the whole [list] thing is a good idea, then just [list] should be like [list append] or [list prepend] so that a bang just outputs the stored list, to be more like [f] and [symbol] and [pointer], although a list is not an atomtype and thus it isn't *that* important to be consistent there.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
Attached is a simple example that I just ran into while working. Basically, when I want to assemble messages, I try to avoid "lists" as much as possible because once messages stop being undefined messages and become symbols or lists, things get much less flexible. [prepend] factors heavily in this approach.
.hc
On Jul 20, 2005, at 1:17 PM, Miller Puckette wrote:
- a storage object for lists would also be useful in main-pd (like
"lister" from zexy - maybe the easiest way would be to make a 2.inlet at the "list" object (to have the same behaviour as "symbol" or "float" ...) ?
I think, "list append" would be just that. However I agree that using the plain "list" for this would feel more natural compared to the other Pd types symbol and float.
There's a delicate problem with "list" sprouting an inlet to store lists... what do you do when someone "bangs" it? If "bang" is to be considered as the same thing as an empty list, then the correct thing would be to replace the stored list with an empty one, then output it -- but that would make it impossible ever to get the stored list back out!
On the other hand, perhaps "list" should be taken to mean "list append" and to just prepend a "list" selector should be some more special name like "list listify". Seems to me that's more ugly than having to use "append" to store lists, but maybe there's a third way somewhere...
cheers Miller
A further suggestion by me would be to maybe add a kind of combination "list first" and "list last", that is: Give "first" a second outlet wich outputs the rest of the list.
Seems like this would be a great convenience. Maybe I should just omit "list first" and "list last" and replace them with a "list split" that splits it in two at any desired point.
Reading through the planned actions, it might be useful to take a look at the max object [zl] which is also available in Cyclone. For those who don't know it, I attached the help file. I sometimes used it, but not too often yet to say anything about which operations would be useful to have in a Pd "list" object as well.
My own motivation is to make it possible to write libraries such as RRADical (especially RRADical!) without needing to include other libraries (which is confusing, especially because of the two competing "prepend" objects.) So if you can name any other functionality you'd need beyond what's here I'll certainly want to put it in. (Not even limited to the list object...)
cheers Miller
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On Wed, 20 Jul 2005, Georg Holzmann wrote:
Hallo!
list append - append a list to another list prepend - prepend a list to another list cat - build a list by accumulating elements list serialize - spit out elements of a list one by one list first - output first n elements list last - output last n elements list length - output number of items in list list reverse - permute elements of a list back to front list pack - synonym for 'pack' list unpack - synonym for 'unpack' list selector - change selector of a list list <no args> - "prepend" the selector list to non-list messages
just some more suggestions (these objects are often the reason why I have to use externals in simple patches):
- a storage object for lists would also be useful in main-pd (like
"lister" from zexy - maybe the easiest way would be to make a 2.inlet at the "list" object (to have the same behaviour as "symbol" or "float" ...) ?
- get a specific element from a list (like "packel" from zexy) - so
it's easier to handle dynamic length list (if you know which atoms you want and don't know the exact length) don't know a good name, maybe "list get" or "list packel" (IOhannes: why packel?) (also I don't if it is a good idea to count the elements from 1 and not from 0 - like in packel ...) -> maybe also a "list set", where you can set a specific element in a list without unpack - repack everything (which is not possible if you don't know the exact size ...)
Since I think we should try to implement as much of Pd in Pd, I think these two (get/set) should both be implemented in Pd. They would be quite straightforward to do, though Matju might demonstrate how inefficient these would be.
All of these would expect the "list" selector at the head of messages,
with
the exception of plain "list"; all of them would output "list" messages
except
"list selector". These would work as follows:
Hm - I see, but what is the advantage of only handle messages with list-selector (beside that you can use the name "list" for the objects ... :) ? This means you often have to:
| [list] - add a list selector | do something like [list reverse] | [list selector] - remove again the list selector |
(should it also be possible to remove the list selector at all with "list selector" ?)
That could come in handy since sometimes that can be a problem and there is currently know way to do this AFAIK.
.hc
zen \ \ \[D[D[D[D
________________________________________________________________________ ____
"Information wants to be free." -Stewart Brand
On Wed, 20 Jul 2005, Hans-Christoph Steiner wrote:
Since I think we should try to implement as much of Pd in Pd, I think these two (get/set) should both be implemented in Pd. They would be quite straightforward to do, though Matju might demonstrate how inefficient these would be.
I can't demonstrate anything until you tell me how you'd do it. How would you implement those "get" and "set" in Pd itself ?
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Wed, 20 Jul 2005, Georg Holzmann wrote:
you want and don't know the exact length) don't know a good name, maybe "list get" or "list packel"
Tcl: proc lindex Lisp: function nth (just like [zl nth]) Smalltalk: selector at: Ruby: syntax [], selector [] Python: syntax [], selector __getitem__ Perl: syntax [], selector FETCH C++: syntax [], selector operator[]
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Thu, 21 Jul 2005, Mathieu Bouchard wrote:
On Wed, 20 Jul 2005, Georg Holzmann wrote:
you want and don't know the exact length) don't know a good name, maybe "list get" or "list packel"
Also, about indexing, pretty much any list (or array) indexing I've seen starts at 0, including [tabread] and excluding A_DOLLAR and A_DOLLSYM.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Thu, 21 Jul 2005, Mathieu Bouchard wrote:
On Wed, 20 Jul 2005, Georg Holzmann wrote:
you want and don't know the exact length) don't know a good name, maybe "list get" or "list packel"
Also, about indexing, pretty much any list (or array) indexing I've seen starts at 0, including [tabread] and excluding A_DOLLAR and A_DOLLSYM.
Yes, please make indexing, slicing, first-ing and last-ing start with zero. (It's my major gripe about the iem-matrix objects, that they start indexing rows and cols at 1 ...)
Ciao
On Thu, 21 Jul 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Also, about indexing, pretty much any list (or array) indexing I've seen starts at 0, including [tabread] and excluding A_DOLLAR and A_DOLLSYM.
Yes, please make indexing, slicing, first-ing and last-ing start with zero. (It's my major gripe about the iem-matrix objects, that they start indexing rows and cols at 1 ...)
Funny, me, it's my major gripe with mathematicians =)
Btw, did I last that jMax's [listelement] and [libsublist] also start indexing at 0 ? And GF mimicks that behaviour.
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Thu, 21 Jul 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Also, about indexing, pretty much any list (or array) indexing I've seen starts at 0, including [tabread] and excluding A_DOLLAR and A_DOLLSYM.
Yes, please make indexing, slicing, first-ing and last-ing start with zero. (It's my major gripe about the iem-matrix objects, that they start indexing rows and cols at 1 ...)
Funny, me, it's my major gripe with mathematicians =)
Btw, did I last that jMax's [listelement] and [libsublist] also start indexing at 0 ? And GF mimicks that behaviour.
I think, apart from aesthetic reasons, starting indexing at zero has practical advantages. For example modulo-counting is a common operation in Pd (many musicians have to deal with loops and bars), and [mod 16] counts zerobased from 0-15. To access matrix-elements, a counter could feed:
[div height] [mod width]
to get zero-based indices to walk through the whole matrix. One-based containers like Iem/zexy matrix require an additional addition.
For lists in Pd there probably are similar use cases available where lists would profit from a consistent zero base. The only problem is $1. ;)
Ciao
On Thu, 21 Jul 2005, Frank Barknecht wrote:
I think, apart from aesthetic reasons, starting indexing at zero has practical advantages. For example modulo-counting is a common operation in Pd (many musicians have to deal with loops and bars),
I have also used modulo for a wealth of other purposes, e.g. cycles of halftones and cycles of fifths and such, and then all the visual aspects of modulo: the tiling, for example. [#store]'s array indexing is modulo the size of each dimension, which is responsible for that behaviour of [#remap_image] that zooming out causes a tiling of small images.
and [mod 16] counts zerobased from 0-15.
According to the mathematicians' definition of modulo, there is a priori no enforced representation of modulo, and to say 0, it's just as valid to say 0 or 16 or 32 or -16, because all those values are the same value in the mod 16 context. However, there's a habit of naming "0" anything that behaves much like the "0" of ordinary numbers, and the same for "1". Therefore, although mathematicians could've picked 1..16 for working in mod 16, they use 0..15 instead.
Note that int formats of the C language behave like just like mod. e.g. the short int type is automatically mod 65536. However the signed short int uses a different range (-32768..32767) than the unsigned short int (0..65535). Note that the results of addition, substraction and even multiplication are the same in both signed and unsigned formats. (the x86 have different opcodes for signed and unsigned because they don't discard the upper bits of the result; once you cast back to short, they're the same)
To access matrix-elements, a counter could feed: [div height] [mod width]
You mean [div width] [mod width].
to get zero-based indices to walk through the whole matrix. One-based containers like Iem/zexy matrix require an additional addition.
Yes.
For lists in Pd there probably are similar use cases available where lists would profit from a consistent zero base. The only problem is $1. ;)
Unfortunately I don't think we can do anything about this one... (or can we? how?)
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
On Thu, Jul 21, 2005 at 03:35:15PM -0400, Mathieu Bouchard wrote:
On Thu, 21 Jul 2005, Frank Barknecht wrote:
and [mod 16] counts zerobased from 0-15.
According to the mathematicians' definition of modulo, there is a priori no enforced representation of modulo, and to say 0, it's just as valid to say 0 or 16 or 32 or -16, because all those values are the same value in the mod 16 context. However, there's a habit of naming "0" anything that behaves much like the "0" of ordinary numbers, and the same for "1". Therefore, although mathematicians could've picked 1..16 for working in mod 16, they use 0..15 instead.
In both mathematics and computing, a modulus is calculated from the remainder of the division. Nobody "could've picked" anything.
Best regards,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Fri, 22 Jul 2005, Chris McCormick wrote:
In both mathematics and computing, a modulus is calculated from the remainder of the division. Nobody "could've picked" anything.
In mathematics, modulo is a way to reduce an algebraic structure into a smaller such structure. For example, if you quotient a Ring by an Ideal of that Ring, it gives you a modulo Ring. e.g. Z/16Z is the set of equivalence classes in which its zero is really the Ideal 16Z, that is, {0,16,-16,32,-32,etc}. The other elements are the Cosets of that Ideal. A "canonical projection" function takes each element of Z making it correspond to the element of the modulo Ring that contains it. If you try inverting that function, you will have to choose a representant of each set so that the inverse becomes 1-to-1. This is why I am talking about picking.
http://mathworld.wolfram.com/Congruence.html http://mathworld.wolfram.com/QuotientRing.html
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
Mathieu Bouchard wrote:
On Thu, 21 Jul 2005, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Yes, please make indexing, slicing, first-ing and last-ing start with zero. (It's my major gripe about the iem-matrix objects, that they start indexing rows and cols at 1 ...)
Funny, me, it's my major gripe with mathematicians =)
well, just to defend myself (not that there would be a real need, but seeing half of zexy's objects vanish within [list] is both a pleasure and a pain, so i feel like i must say at least *some*thing), the original (and BIG) idea of iemmatrix is to be a kind of "matlab/octave for pd"; this explains the naming of the objects and the 1-based indexing.
mfg.asd.r IOhannes
On Thu, 21 Jul 2005, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote: well, just to defend myself (not that there would be a real need, but seeing half of zexy's objects vanish within [list] is both a pleasure and a pain, so i feel like i must say at least *some*thing), the original (and BIG) idea of iemmatrix is to be a kind of "matlab/octave for pd"; this explains the naming of the objects and the 1-based indexing.
the original and big idea of GridFlow is to be a kind of APL for Pd. This explains the naming and behaviour of some objects (#fold,#scan,#inner,#outer) but it doesn't explain why all indices in GridFlow start at 0, even the numbering of dimensions (in a picture, 0=rows, 1=columns, 2=channels).
How much did you aim for compatibility with matlab/octave and why?
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'
Mathieu Bouchard wrote:
On Thu, 21 Jul 2005, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote: well, just to defend myself (not that there would be a real need, but seeing half of zexy's objects vanish within [list] is both a pleasure and a pain, so i feel like i must say at least *some*thing), the original (and BIG) idea of iemmatrix is to be a kind of "matlab/octave for pd"; this explains the naming of the objects and the 1-based indexing.
the original and big idea of GridFlow is to be a kind of APL for Pd. This
alright, this had to come...
explains the naming and behaviour of some objects (#fold,#scan,#inner,#outer) but it doesn't explain why all indices in GridFlow start at 0, even the numbering of dimensions (in a picture, 0=rows, 1=columns, 2=channels).
How much did you aim for compatibility with matlab/octave and why?
my intentions were not very religious. i just tried to not disturb people coming from matrix-manipulation background (and most people at our in institute that deal with matrices do it with matlab/octave and not with a background in C).
as for naming: whenever there is a matrix-operation that makes it into iemmatrix, i open octave and look how it is called there. the corresponding object will bear the same name (if possible)
mfg.adr. IOhannes