On 25/12/2006, at 16.02, Frank Barknecht wrote:

If you want a "list of lists" data structure in Pd, you can do it
with Pd's data structures however.

"list of lists" is the same as two-dimensional arrays except the
lists (in the list) can consist of something non-float too.

That sounds nice since it will provide and easier solution to what
I'm having a hard time building: A two-dimensional array "data-type"
out of a list of floats with delimiter items to go with something
like 2dtabread and 2dtabwrite abstractions. - Has anyone done that
already?

On Sat, 30 Dec 2006, Frank Barknecht wrote:

Steffen hat gesagt: // Steffen wrote:

...

That sounds nice since it will provide and easier solution to what I'm having a hard time building: A two-dimensional array "data-type" out of a list of floats with delimiter items to go with something like 2dtabread and 2dtabwrite abstractions. - Has anyone done that already?

I guess you will like the iemmatrix-externals.

The difference between matrices and lists-of-lists is that, in the former case, the sublists need to be of fixed size.

If lists are allowed to contain any atoms and there exists an atom type for pointing to lists, then another difference is that some parts of the array may be "1-dimensional" where other parts "2-dimensional" or "3-dimensional" or etc, depending on the number of list accesses have to be done to reach a non-list atom.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

...

...

...

A two-dimensional array "data-type" out of a list of floats with delimiter items to go with something like 2dtabread and 2dtabwrite abstractions. - Has anyone done that already?

I've done something like that for storing parameters in arrays, but like matthieux bouchard said for matrixes, the length of the 'listed list' is fixed. An example with arrays is attached. I would be glad to make a version where the list lengthes are not fixed, but it's very complicated to do with arrays, [trigger], [once] and [until] maybe someone will find it out later... PC.

#N canvas 28 9 707 671 12; #X obj 161 273 + 1; #X obj 201 274 + 2; #X obj 168 246 i; #X obj 208 247 i; #X obj 128 249 i; #X obj 254 218 sel 0 1; #X obj 246 168 * 3; #X obj 50 208 t f b; #X obj 143 203 t f b; #X obj 97 203 t f b; #X obj 280 444 i; #X obj 435 274 * 3; #X obj 314 444 + 1; #X msg 279 388 3; #X obj 280 414 until; #X obj 254 307 t b a b; #X obj 279 468 t a a; #X obj 314 518 mod 3; #X obj 279 546 demux 0 1 2; #X msg 345 613 set $1; #X msg 405 611 set $1; #X msg 279 617 set $1; #X obj 321 334 i; #X obj 279 333 list; #X obj 345 303 t a b; #X obj 279 360 t b a; #X obj 314 389 list trim; #X floatatom 148 134 5 0 0 0 - - -; #X floatatom 98 136 5 0 0 0 - - -; #X floatatom 43 139 5 0 0 0 - - -; #X floatatom 497 51 5 0 96 0 list_pos - -; #X text 380 13 List Of Fixed List; #X obj 299 54 tgl 15 0 empty empty List_Select 17 7 0 10 -262144 -1 -1 1 1; #N canvas 0 0 450 300 (subpatch) 0; #X array LOFL2 100 float 0; #X coords 0 -1 99 1 100 70 1; #X restore 573 176 graph; #N canvas 0 0 450 300 (subpatch) 0; #X array LOFL1 100 float 0; #X coords 0 -1 99 1 100 70 1; #X restore 578 303 graph; #X obj 145 177 / 100; #X obj 42 169 / 100; #X obj 93 173 / 100; #X msg 254 244 set LOFL1; #X msg 272 272 set LOFL2; #X obj 279 494 tabread LOFL1; #X obj 25 432 tabwrite LOFL1; #X obj 436 250 r list-pos; #X obj 21 68 r A; #X obj 101 68 r B; #X obj 166 68 r C; #X obj 279 639 s A; #X obj 344 635 s B; #X obj 406 641 s C; #X obj 254 192 r list-sel; #X obj 246 146 r list-pos; #X obj 299 76 s list-sel; #X obj 496 75 s list-pos; #X text 36 36 three values list; #X obj 554 48 hradio 15 1 0 8 empty empty empty 0 -8 0 10 -262144 -1 -1 0; #X obj 279 579 * 100; #X obj 345 580 * 100; #X obj 405 577 * 100; #X connect 0 0 41 1; #X connect 1 0 41 1; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 41 1; #X connect 5 0 38 0; #X connect 5 1 39 0; #X connect 6 0 4 1; #X connect 6 0 2 1; #X connect 6 0 3 1; #X connect 7 0 41 0; #X connect 7 1 4 0; #X connect 8 0 41 0; #X connect 8 1 3 0; #X connect 9 0 41 1; #X connect 9 1 2 0; #X connect 10 0 12 0; #X connect 10 0 16 0; #X connect 11 0 24 0; #X connect 12 0 10 1; #X connect 13 0 14 0; #X connect 14 0 10 0; #X connect 15 1 23 0; #X connect 15 2 22 0; #X connect 16 0 40 0; #X connect 16 1 17 0; #X connect 17 0 18 1; #X connect 18 0 55 0; #X connect 18 1 56 0; #X connect 18 2 57 0; #X connect 19 0 47 0; #X connect 20 0 48 0; #X connect 21 0 46 0; #X connect 22 0 10 1; #X connect 23 0 25 0; #X connect 24 0 22 0; #X connect 24 1 23 0; #X connect 25 0 13 0; #X connect 25 1 26 0; #X connect 26 0 40 0; #X connect 27 0 35 0; #X connect 28 0 37 0; #X connect 29 0 36 0; #X connect 30 0 52 0; #X connect 32 0 51 0; #X connect 35 0 8 0; #X connect 36 0 7 0; #X connect 37 0 9 0; #X connect 38 0 15 0; #X connect 38 0 41 0; #X connect 39 0 15 0; #X connect 39 0 41 0; #X connect 40 0 18 0; #X connect 42 0 11 0; #X connect 43 0 29 0; #X connect 44 0 28 0; #X connect 45 0 27 0; #X connect 49 0 5 0; #X connect 50 0 6 0; #X connect 54 0 52 0; #X connect 55 0 21 0; #X connect 56 0 19 0; #X connect 57 0 20 0;

On Mon, 1 Jan 2007, Patco wrote:

I've done something like that for storing parameters in arrays, but like matthieux bouchard said for matrixes, the length of the 'listed list' is fixed.

the main thing missing in my nested list plan is a name for the atomt type. it can't really be A_LIST because of this correspondence

atomtype -> selector A_FLOAT float A_SYMBOL symbol A_POINTER pointer

but A_LIST can't work because the name "list" is already taken for a type of non-atom message. (an atom message is one carries exactly one atom which is always supposed to be of the type indicated by the selector)

I'm thinking of "plist" meaning "pointer-to-list", or "listp" as "list pointer", because that'll be what it is. if you put this in a messagebox:

{1 2 3}

it would be equivalent to writing it with that selector, e.g.:

listp {1 2 3}

and because that's an atomtype and that it would be able to contain the same thing that a regular list-message can, you will be able to nest listp into list or into listp:

1 2 3 {4 5 6} is like list 1 2 3 {4 5 6}

{1 2 3 {4 5 6}} is like listp 1 2 3 {4 5 6}

so, what do you think? is listp a good word? what else could it be?

(besides, another advantage of listp over regular lists is that they would be more efficient because they would require less copying of memory)

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

On Tue, 2 Jan 2007, Martin Peach wrote:

Mathieu Bouchard wrote:

...

but A_LIST can't work because the name "list" is already taken for a type of non-atom message. (an atom message is one carries exactly one atom which is always supposed to be of the type indicated by the selector)

A list is just a bunch of atoms laid out contiguously in memory: I guess that makes it a molecular message? ;)

That's the paradox. If a list is to be just a bunch of atoms, and you don't want to complicate the definition, but you want to support nested lists in a proper way, then you have to accept that an atom may be a list (or may represent a list via some kind of pointer, which amounts to the same...)

What about extending the pointer type so that it can point to any kind of atom, including a list of atoms?

That may be a good idea. I have the following questions about it:

1. What do you do with the fact that an A_POINTER atom points to a

t_gpointer which points to a t_gstub ? Isn't that too much indirection for just a list? (The t_gstub may be skipped, but it's required in order to know whether we really are pointing to atoms!)

2. What do you do with types of pointees? gpointers are expected to be

either pointer-to-array-element or pointer-to-scalar-in-glist (where glist is supposed to be canvas nowadays, but is still called glist in the source, even DesireData's). The assumption made by pointer-using patches is that if one has a pointer that is not null, then it points to a struct. Do you break the assumption that a pointer points to a struct, or do you introduce a way of looking at an atom as if it were a struct?

3. Even though the gpointer type for scalars is GP_GLIST (meaning

"canvas"), the type of the corresponding fielddesc is DT_LIST, and the associated typename is the symbol "list"... what should be done about it?

4. I'm really going to introduce plain refcounts already for another

reason, and I think that it would be important to not tie those new lists to a specific canvas, I want them to fly around in a carefree manner; therefore, should the list atoms be distinct from t_gpointer stuff, or should t_gpointer (as we know it) die? I'm open to either, really, and it's possible that both would happen - it needs not be either/or.

And also, here's a plan for making t_gpointer die:

1. Move gs_refcount to t_array and t_canvas.

2. add a t_pd header to t_array so that it can be recognised by its

t_class*.

3. Remove gs_which because we can already figure it out: if (!gs_un) then

it's a GP_NONE, else we check whether *(t_pd*)gs_un == t_array_class to figure out whether it's GP_ARRAY or GP_LIST.

4. nuke gp_valid, a_valid and gl_valid, because if they ever are useful,

they'll cause spurious warnings from valgrind, and because there are better ways of taking care of stale pointers. Note that the currently implemented gp_valid doesn't even work, because a_valid isn't cleared when freeing the t_array, so a matching a_valid is not a guarantee of whatever. I'd rather have pointers never go stale, by making deallocation completely automatic (refcounts and nothing else).

5. nuke t_gstub completely, by replacing gp_stub by gs_un.

6. at this point, the only remaining things are the element pointer

(gp_un) and the container pointer (gp_stub aka gs_un). If the unused portion of a_type is recycled (only compatible if no externals check for A_POINTER) then we could make it hold the index, but in the case of GP_LIST this wouldn't be efficient until t_glist stops holding its elements as a linked-list. If it does become efficient, then a_type may hold the gpointer index, and so t_gpointer will only need to store gp_stub, so t_gpointer can be nuked completely, by replacing w_pointer by gp_un.

Does that look good? (I admit that step 6 is more difficult, but I expect that DesireData's t_canvas/t_gobj will stop using linked-lists pretty soon

• they're getting too cumbersome to use, for some of the upcoming

features).

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

Mathieu Bouchard a écrit :

I'm thinking of "plist" meaning "pointer-to-list", or "listp" as "list pointer", because that'll be what it is. if you put this in a messagebox:

{1 2 3}

it would be equivalent to writing it with that selector, e.g.:

listp {1 2 3}

and because that's an atomtype and that it would be able to contain the same thing that a regular list-message can, you will be able to nest listp into list or into listp:

1 2 3 {4 5 6} is like list 1 2 3 {4 5 6}

{1 2 3 {4 5 6}} is like listp 1 2 3 {4 5 6}

For quantitative structure-property relationship models, that could be a very good tool.

so, what do you think? is listp a good word?

I don't know if I could help to find the good answer because I'm rather seducted by the word

E_STATE

for some reasons I would explain if it's really important,

which means electrotopological state.

Patco.

___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com