hi Orm,
much of what follows is my guesswork, hope it is not completely off target...
there is no real need for any coding of the elements, except to speed up the comparisons. If this is not a bottleneck, then just store the elements as arrays of floats packed into a standard struct _elem { struct _elem *next; float data[1]; }. The markov class would accept list messages, and would be instantiated like [markov <ndimensions>]. The main struct of the class would have ``ndimen'' field (and probably also elemsize field added for speed and convenience).
real-time performance input without quantizing (possibly vector quantizing) could be useful -- with too broad a sample space one needs huge amount of ``training'' data to start with. And if there is to be quantizing, then I would rather do it in separate externals or abstractions tuned for any particular domain, not in a generic markov external. It may occur, that in most cases such a generic object works best on a small one-dimensional sample space (obtained after vector quantizing), that will fit into undistorted floats...
Krzysztof
Orm Finnendahl wrote: ...
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.