I was wondering of there is a simple dictionary (key-> value storage) object in pd-extended. Something with basically operations "set key", "get key" and "delete key"

Any idea what I could use?

@seb-harmonik-ar I don't really want to get into that. Feels a bit complicated for such a simple thing.

I kind of thought it's such a common thing to do with general purpose programming languages, that there must be an object implementing it in pd-extended .... but apparently there might not be!?

[coll] is more of a list really. Indexes are Integers. I have indexes that are symbols. and I want to associate them with other symbols.

[coll] is actually an associative array and can associate symbols with symbols. Yo can use it with floats as indices, and some messages give the impression it is an array. The help-patch is very confusing in this. I tried to make an improved version: http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches/coll-help.pd

dictionary-standalone.pd
dictionary-standalone-help.pd

It's "standalone" because the actual [dictionary] object uses a bunch of external patches that were replaced with [pd ] subpatches.

If you're interested, I have a bunch of those patches here (I'll update it with a Github link soon):

Pd Patches - Google Drive

With the [environments] object, you can have key-value bindings where the values are [dictionary] objects (using dynamic patching). [abstractions] lets you put your own subpatch as the value instead of a [dictionary].

Edit: Here's a standalone version of [abstractions] (that's also vanilla compatible):

abstractions-standalone.pd
abstractions-standalone-help.pd

why are you still using extended? it carries a very old cyclone library, for instance, with 0.1 versions @electrickery ressurected it back and made a great 0.2 release, me and others have carried on and now there's a 0.3 version you can use in vanilla. But anyway, I guess coll will work for what you want in Pd extended anyhow...

cheers

Something like:

[symbol hello(
|
[symhash 1000]
|
[print result]

That would give you the hash for "hello" modulo 1000 which you could use to implement a fairly performant dictionary in Pd Vanilla. (You can do it manually but it's a bit slow to split the symbol and add the ASCII value of each character in an object chain.)

A hash map is a type of dictionary, and a dictionary as I understand it is basically a bunch of key/value pairs.

For a real-time system you want to be able to take a key as input and output the value in an amount of time that is small and predictable. You also want the performance to be about the same regardless of how many keys you have or whether a particular key is at the beginning or end of the data.

Suppose I have an array of 10,000 key/value pairs and I want to find the value for key "blah." An easy way to search would be to start at the beginning and iterate through each element until I find the key named "blah." If the key is at element 0 then it's as fast as possible, but if it's at element 9,999 it's much slower (because I had to iterate through the entire array before I found it). If we want the lookup time to be constant that's not a good algorithm, and it gets worse the more elements we add.

A hashing function will take something like one of our keys and "hash" it to some value
in a fixed range. So "foo" might hash to the number 12, "blah" to 450, and so on. The point
is that the input can be an arbitrary string, and the output will be a number between,
say, 1 and 1,000. The mapping of strings to numbers should ideally happen in a way that
distributes our keys uniformly between 1 and 1,000. But it should also be predictable
so that when we hash the same string we always get the same number out.

Since we have 10,000 keys and only 1,000 total slots, we'll still get multiple key/value
pairs in each slot. But now instead of our worst case of iterating through 9,999 keys,
we have

1. time it takes to compute the hash and find the slot where our key/value pair is. (For Pd symbols, the hashing algo is essentially just doing two addition ops per character of the string, then a modulo op. That usually takes a lot less time than iterating through a big array of symbols to find a match.)
2. time it takes to iterate through 10 keys (on average) for that slot.

That's much better performance for a real-time system. And we can decrease our
average iteration from 10 to 1 by using 10,000 slots instead of 1,000, at the expense of more memory. (And possibly worse cache performance, though I'm not sure about the particulars of that.)

To sum up, there are a few variables:

1. How many slots do you want? Fewer means less memory allocation up front at the
   expensive of (potentially) longer time to find/set/remove key/value pairs in each slot.
2. How much data do you have? For small number of key/value pairs you can probably simply use a much simpler data structure and forgo hash maps altogether. For enormous amounts of key/value pairs, memory may be a limiting factor.

There are all kinds of hashing algorithms, a bit of a rabbit hole like DSP filters. I would guess some are better for situations where you may want to sort keys as well as generally efficient performance, etc. But I haven't studied them in depth.

But the problem with your [text]-based approach is that each line is just a list of atoms. It would be possible to just design it so that each line alternates "key1 value1 key2 value2 etc." but that's clunky to manipulate.

What I think could work would be to create a data structure array where each element has a text field. Then you use the hash to find the array index, and use the key to search that text field for the relevant line, add lines, delete lines, etc.

;
-- make dictionary;
;
local function defaultdict(default_value_factory);
;
local t = {};
local metatable = {};
metatable.__index = function(t, key);
if not rawget(t, key) then;
rawset(t, key, default_value_factory(key));
end;
return rawget(t, key);
end;
return setmetatable(t, metatable);
end;
;

I'll see if I can throw together an example later.

However, to hash a 4 character string in a Pd patch (using the same method that Pd uses internally for symbol lookup), the worst case realtime performance I measured is 0.088. That hash is then used as an array index to get a pointer to the correct text. Then it's just [text search] and [text get], where the average search length will be 5 instead of 5000.

Looking at your realtime result for [text search], it seems likely that a search among 5 or 10 lines is going to be performant enough to calculate easily in realtime. (Although I guess there's still a rather unlikely possibility that all the values get stored at the same exact index. I don't know how to calculate that probability, but it seems extremely unlikely on the face of it.)

Edit: here's a quick example of the hashing algorithm implemented in Pd. Would be a lot faster in C without Pd's message passing.

hasher.pd

Another edit: This isn't quite the same as the internal algorithm because I'm serializing the string backwards. (For a robust implementation you'd want to use [list-drip] to avoid stack overflows.)

dictionary.pd
dictionary-help.pd

A few things to notice:

1. Search performance should be at least 10x faster than the worst case for [text search]
2. The total computation time for [dictionary] should be vastly more predictable than [text search].

However, there's still a clear bottleneck in this abstraction-- calculating the hash. Not sure whether it's the conversion from symbol to list or the recursive addition, but it is slow. So slow that if you reimplement it in C as I did to test, you get another 10x speed increase.

So exposing the (C level) symbol hashing to the user and wrapping it in an abstraction as I've done should give you a 100x speedup over the worst case linear lookup time in your patch above with 10,000 items.

A more dramatic restatement of that-- since memory is cheap, this means you can create a much larger hashmap and handle an enormous number key/value pairs for realtime computation that would not be possible with linear lookup times of [text].

Edit: the abstraction is just a demo. It will happily duplicate keys (preventable by adding a [text search] in the right object chain), and provides no mechanism to delete entries. While lookup is tweaked for realtime performance, adding keys will cause intermittent memory allocation.

Edit2: This is basically the way t_symbol *gensym(char*) works in the Pd code. It hashes the string to get the array index, then searches through the linked list of symbols at that index for the string. If it finds it it returns the memory address; if not, it creates a new entry and returns that address. That's why you can compare two symbols in Pd source code with "==" sign-- if they're both at the same address then it's the same string.