Hallo, lsw hat gesagt: // lsw wrote:

Looks pretty useful. Also a great structures example.

Btw.: To fill the symbolarray [list-enumerate] from [list]-abs is great.

[symbolarray] also is pretty fast if you have to lookup something in large lists. I tested it with an arraysize of 100,000,000 elements, which takes roughly 300 MB RAM according to my system monitor (with all elements except the last one empty). Creating the array takes several seconds, but looking up the final element happens instantly afterwards.

The other Pd-vanilla ways I know to implement this are textfile-dumps with "rewind"+[until] or [select]-constructs or [list-idx], which all are unusable with arrays of these sizes.

And of course the patch can be modified to look up any kind of list whose structure is known.

Now we still need maps/hashes.

Ciao

Frank

Hi Frank, Does [drawpolygon] affect creation time with that many elements?

-Jonathan

--- On Fri, 4/17/09, Frank Barknecht fbar@footils.org wrote:

From: Frank Barknecht fbar@footils.org Subject: Re: [PD] symbolarray To: "PDlist" pd-list@iem.at Date: Friday, April 17, 2009, 3:52 PM Hallo, lsw hat gesagt: // lsw wrote:

...

Looks pretty useful. Also a great structures example.

Btw.: To fill the symbolarray [list-enumerate] from [list]-abs is great.

[symbolarray] also is pretty fast if you have to lookup something in large lists. I tested it with an arraysize of 100,000,000 elements, which takes roughly 300 MB RAM according to my system monitor (with all elements except the last one empty). Creating the array takes several seconds, but looking up the final element happens instantly afterwards.

The other Pd-vanilla ways I know to implement this are textfile-dumps with "rewind"+[until] or [select]-constructs or [list-idx], which all are unusable with arrays of these sizes.

And of course the patch can be modified to look up any kind of list whose structure is known.

Now we still need maps/hashes.

Ciao

Frank

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Fri, Apr 17, 2009 at 03:52:33PM +0200, Frank Barknecht wrote:

Hallo, lsw hat gesagt: // lsw wrote:

...

Looks pretty useful. Also a great structures example.

Btw.: To fill the symbolarray [list-enumerate] from [list]-abs is great.

[symbolarray] also is pretty fast if you have to lookup something in large lists. I tested it with an arraysize of 100,000,000 elements, which takes roughly 300 MB RAM according to my system monitor (with all elements except the last one empty). Creating the array takes several seconds, but looking up the final element happens instantly afterwards.

The other Pd-vanilla ways I know to implement this are textfile-dumps with "rewind"+[until] or [select]-constructs or [list-idx], which all are unusable with arrays of these sizes.

And of course the patch can be modified to look up any kind of list whose structure is known.

Now we still need maps/hashes.

Maybe this is something close: http://lists.puredata.info/pipermail/pd-list/2008-03/060712.html

Best,

Chris.

http://mccormick.cx

Hi Frank,

unfortunatily pd has next to no string functions (without externals). Otherwise it shouldn't be too hard, to write a hashfunction that retrieves a numeric hash for a given symbol, which could be used as struct index. At least something like get_character_of_symbol_at_position and get_ascii_value_of_character would be needed to do so.

All the best, Lsw~

Am 20.04.2009, 15:32 Uhr, schrieb Frank Barknecht fbar@footils.org:

Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:

...

On Fri, Apr 17, 2009 at 03:52:33PM +0200, Frank Barknecht wrote:

...

Now we still need maps/hashes.

Maybe this is something close: http://lists.puredata.info/pipermail/pd-list/2008-03/060712.html

Yeah, but I was thinking of something faster than walking around in a
textfile would be. :) The really nice thing about data structure arrays is that
they are very fast. The not so nice things are that they only accept integers for
lookup and that the structure of the thing they store has to be predefined.

What I would love would be a "map" type field for [struct] so you could
say:

[struct item float i]

[struct example map items item]

just like for the "array" field. But now the index to lookup a map
element would be a symbol key.

The setter could look like this:

        [symbol key(
        |
        [mapelement example items]

[100\ | | | [set item i]

and a getter like this:

[symbol key( | [mapelement example items] | [get item i] | [100\

All in analogy to [element] for arrays

Ciao

Frank Barknecht wrote:

Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:

...

On Fri, Apr 17, 2009 at 03:52:33PM +0200, Frank Barknecht wrote:

...

Now we still need maps/hashes.

Maybe this is something close: http://lists.puredata.info/pipermail/pd-list/2008-03/060712.html

Yeah, but I was thinking of something faster than walking around in a textfile would be. :) The really nice thing about data structure arrays is that they are very fast. The not so nice things are that they only accept integers for lookup and that the structure of the thing they store has to be predefined.

What I would love would be a "map" type field for [struct] so you could say:

[struct item float i]

[struct example map items item]

just like for the "array" field. But now the index to lookup a map element would be a symbol key.

The setter could look like this:

        [symbol key(
        | 
        [mapelement example items]

[100\ | | | [set item i]

and a getter like this:

[symbol key( | [mapelement example items] |
[get item i] | [100\

All in analogy to [element] for arrays

Ciao

I just knocked up a little (pointless, maldocumented) example (attached).

It basically creates a new abstraction instance for each symbol in the map, and binds it to a receive name - so it's as fast/slow as pd's settable send is. Only maps symbols to lists, no float keys or meta-message values, and no deletion is supported (though I think I know how it would be possible - query the relevant abstraction for its position (sent inside as creation arguments) then cut it using the nefarious mouse click emulation...).

Enjoy,

Claude

http://claudiusmaximus.goto10.org

#N canvas 0 0 627 461 10; #N canvas 0 0 450 300 $0-assoc 0; #X restore 153 48 pd $0-assoc; #X obj 108 22 loadbang; #X msg 107 47 clear; #X obj 107 81 send pd-$0-assoc; #X obj 233 17 inlet; #X obj 315 17 inlet; #X obj 28 215 receive $0-got; #X obj 31 19 inlet; #X obj 31 41 symbol; #X obj 233 41 symbol; #X obj 27 385 outlet; #X obj 84 385 outlet; #X obj 31 98 pack s $0; #X msg 31 133 symbol $2-$1-get; #X obj 48 191 send; #X obj 84 341 spigot; #X msg 117 317 1; #X obj 27 338 t a b; #X obj 84 363 t b b; #X msg 137 350 0; #X obj 248 175 send; #X obj 233 92 pack s $0; #X obj 28 239 list prepend; #X obj 28 281 route get set; #X obj 28 308 list; #X msg 123 213 get; #X obj 28 261 list trim; #X msg 233 130 symbol $2-$1-get; #X obj 31 157 t b b a b b; #X obj 233 151 t b b a b b; #X msg 153 212 set; #X obj 233 219 f; #X msg 280 191 0; #X msg 248 196 1; #X obj 65 307 bang; #X obj 233 244 sel 0 1; #X obj 252 276 list append; #X obj 252 302 send; #X obj 233 110 t a a; #X msg 304 242 symbol $2-$1-set; #X obj 188 374 send pd-$0-assoc; #X obj 180 285 t b b; #X msg 188 334 obj 0 0 assoc-elem $1 $1-$2; #X obj 188 311 pack $0 s; #X obj 233 65 t a a; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 4 0 9 0; #X connect 5 0 36 1; #X connect 6 0 22 0; #X connect 7 0 8 0; #X connect 8 0 12 0; #X connect 9 0 44 0; #X connect 12 0 13 0; #X connect 13 0 28 0; #X connect 15 0 18 0; #X connect 16 0 15 1; #X connect 17 0 10 0; #X connect 17 1 19 0; #X connect 18 0 11 0; #X connect 18 1 19 0; #X connect 19 0 15 1; #X connect 21 0 38 0; #X connect 22 0 26 0; #X connect 23 0 24 0; #X connect 23 1 34 0; #X connect 24 0 17 0; #X connect 25 0 22 1; #X connect 26 0 23 0; #X connect 27 0 29 0; #X connect 28 0 15 0; #X connect 28 1 14 0; #X connect 28 2 14 1; #X connect 28 3 16 0; #X connect 28 4 25 0; #X connect 29 0 31 0; #X connect 29 1 20 0; #X connect 29 2 20 1; #X connect 29 3 32 0; #X connect 29 4 30 0; #X connect 30 0 22 1; #X connect 31 0 35 0; #X connect 32 0 31 1; #X connect 33 0 31 1; #X connect 34 0 33 0; #X connect 35 0 41 0; #X connect 35 1 36 0; #X connect 36 0 37 0; #X connect 38 0 27 0; #X connect 38 1 39 0; #X connect 39 0 37 1; #X connect 41 0 9 0; #X connect 41 1 43 0; #X connect 42 0 40 0; #X connect 43 0 42 0; #X connect 44 0 21 0; #X connect 44 1 43 1;

#N canvas 0 0 450 300 10; #X obj 25 94 list append; #X obj 25 57 bang; #X obj 25 126 send $1-got; #X obj 25 28 receive $2-get; #X obj 123 28 receive $2-set; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 3 0 1 0; #X connect 4 0 0 1;

#N canvas 0 0 450 300 10; #X obj 105 179 assoc; #X msg 20 49 symbol foo; #X msg 20 69 symbol bar; #X msg 20 90 symbol baz; #X obj 132 208 print none; #X obj 105 235 print found; #X msg 20 110 symbol quux; #X msg 100 49 symbol foo; #X msg 100 69 symbol bar; #X msg 100 90 symbol baz; #X msg 100 110 symbol quux; #X msg 181 49 list a b c; #X msg 181 71 list 1 2 3; #X msg 180 93 list a 2 c; #X msg 179 117 list 1 b 3; #X connect 0 0 5 0; #X connect 0 1 4 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 6 0 0 0; #X connect 7 0 0 1; #X connect 8 0 0 1; #X connect 9 0 0 1; #X connect 10 0 0 1; #X connect 11 0 0 2; #X connect 12 0 0 2; #X connect 13 0 0 2; #X connect 14 0 0 2;