what about jit.submatrix -> jit.iter?

wes

hi wes

i've seen you use this technique before, it's a generally a good technique and I actually started out using it on a few projects, BUT I have found examples where this breaks badly under high stress. Unfortunately, I can't find any of them right now, as luck would have it. I will dig some more. I do remember that if you're constantly changing the jit.matrix at the top, the jit.submatrix may not update fast enough or in sync with your changes, whereas if you use getcell/ setcell you have a much better chance of getting the correct (for your purposes) data. Dang, I wish I could find that patch so I can illustrate this happening. It was not a bug but a timing issue that needed to be taken into account.

Also, I don't like jit.iter. Too easy to make it do horrible things to your computer. That, and I just find it conceptually opaque, by which I mean try explaining it properly to someone else. It does too much in a single object, for general purposes - an object that could get you a single cell, where you have exact control over which cell it points to (so you can iterate through it yourself) is generally much more useful to me than having to remember what jit.iter's outlets do and which I can ignore. Just my 2 cents (and I do use jit.iter a lot these days).

Now that you mention it, since jit.iter already does this, and its close cousin jit.spill has source code available in the Jitter dev kit, maybe I can (eventually) roll my own object.

Cheers Evan

On Dec 27, 2007, at 2:54 PM, Wesley Smith wrote:

> what about jit.submatrix -> jit.iter? > > wes > >

Not to deter you from making whatever object suits your needs in C, but the following sounds like it would be relatively simple to make as an abstraction using patcherargs. As for cell X X X val X X X X, to get the value will always be zl slice dimcount+2, where dimcount can be found using zl len on the output of the getdim message, or even simpler, zl ecils planecount.

-Joshua

On Dec 27, 2007, at 4:42 AM, evan.raskob [lists] wrote:

> Hi all, > > I've been really getting into using jitter matrices (matrixes? > never sure about the proper plural for those) as large-scale arrays > for data storage and retrieval. I was a bit hesitant at first, > because we need to send them messages like "getcell X X X" and then > parse out data of the form "cell X X X val X X X X", which may > change depending on the matrix dims/type (and I try to avoid regexp > whenever possible, just to stay sane). But I have to say, this is > a really nice way of storing and retrieving and manipulating large > amounts of data. Not that it can't be improved... > > What bothers me still are the messages I need to send. If a matrix > is a virtual object, referencing some hazy collection of memory > blocks somewhere in my mysterious computer, why can't the cells be > treated this way to? Why can't there be an object like > [jit.matrixcell myMatrix X X X] that refers to a single cell of a > matrix, and when banged, spits out the contents of that cell, or > when a list comes in, set the cell it refers to to the list > contents? It could have a few messages like "cell X X X" to update > the cell it referenced, and "refer MATRIX_NAME" to change the > matrix it pointed to, and spit out errors if that matrix didn't > exist. Really simple, no parsing necessary, unless it also had a > right outlet from which you could get all the usual matrix info > stuffs, like dims, type, name, etc. > > I'd do this, but a quick look at the jitter code is like peeking > inside a manhole cover in NYC. Lots of wires, pitfall, wet and > angry alligators... best not to muck about there unless you have > some time on your hands, and steel boots. > > So, is this a practical idea? > > > Happy Holidays! > > -Evan