hi,
thanx to miller and krzystof for the ideas!
Am Donnerstag, den 17. Januar 2002 um 12:03:24 Uhr (+0100) schrieb Krzysztof Czaja:
hi,
how about passing symbols, possibly written as somehow prefixed octal, hex or binary numbers, and then atoi()/strtol()/sscanf()/whatever() them to integers?
That's a very nice idea, but I think, I will end up using Millers suggestion of passing lists of smaller integers instead, since that's the way I used the object before anyway (see below).
But I wonder: if there was a huge amount of different masks generated during a Pd session, how this would affect the overall performance? What I mean is that the penalty of symbol hash table slot chaining could get high.
If this is true, then I wonder: is the above a viable reason for giving users a way (like sending a message to pd) to clear symbol table of currently unused (not bound, etc.) elements?
Yes, that would be definitely necessary, as the amount of generated symbols would be immense.
The object, I'm needing it for is the markov object, I mentioned some time ago. It stores elements in two data structures: (1.) A table, implemented as linked list, which defines the succession of elements and (2.) a correlated multidimensional search tree, which stores the statistics of occurence of elements of the table in respect to markov properties of any order. These statistics can for example be used to generate new elements with probabilities which match the current state of the table. The table can be extended by supplying elements to the object from the outside world, or by the elements generated by the object itself, it can be shrunk, manipulated etc...
The elements to be stored need to have the following properties:
They have to be comparable not only for equality, but also, in special cases, whether they lie in a certain range (for example, if you code delta times of performers in real time performances, or if some properties of a complex event should not matter in respect of markov properties, but need to be stored within the element nevertheless)
It should be possible to store an element with more than one dimension, for example if you want to store a chord progression including the velocities or delta times.
The idea, I came up with when I first wrote the object, was, to use one 32-bit integer value internally for each element and define it as up to 8 bitfields of variable (and userdefinable) width. In practice that worked fine even with 32 bits, although sometimes problems arose (like if you want to code 5 voice counterpoints including interval structure, metrical weight, delta time and tie in information). It would probably be nicest, to use pointers as reference to elements of arbitrary type instead of integers since the 32 bit limitations could be avoided. But then the user would have to provide a function which tests for equality, and I have no idea, how this could be done within the framework of pd.
I will probably end up using integers again internally (maybe 64 bits instead of 32) and will send a list for storing each element which is range checked, length checked and then converted into an integer. But if someone has another idea, how to implement this, it would be greatly appreciated. As I put in some work, I would really like, if the object is considered useful by a lot of people and this is the chance to have the object tailored to your own needs.
grüezi Orm