Arrays: new and old keys, i

[Mark Brownell]

-----Original Message-----
>From: Brian Yennie <briany at qldlearning.com>
\>
>This is all very clever (seriously!), but I think this thread is  
>simply talking about two different things. It is one thing to maintain  
>your own sorting information in arrays. It's another to pull the data  
>out of arrays, then sort it. But it's another entirely to have  
>sortable array. When your data gets really large, you don't want to  
>have to maintain your own indices for sorting. You can, but it would  
>be way more efficient to keep it in the engine.
>

Actually, in talking to you, I discovered that you can sort the list inside the array without taking it out of the array to do it. I liked discovering that.

>The latter is what, I think, some would like to see. The workarounds  
>are great, and if they work for your needs, then you probably don't  
>need native support. I love resourceful solutions =). But I have to  
>agree -- native support would be a nice addition.
>

Actually, for me, I go back to the cube illusion. I prefer numerical data structures that don't need sorting. myArray[3][2][4][1] is what I almost always do. The keys never get meaningful names. I'm just storing data in logical containers. It's like having a cube of variables. It's a three dimensional hash table in my mind.

>One point of speculation which would make a huge difference is how Rev  
>is actually implementing the arrays. If it is truly a hash table,  
>providing any sort of in-order traversal of the array elements won't  
>be happening any time soon. A hash table is an unordered piece of  
>data, and so to provide any sort of built-in sorting, RunRev would  
>have to implement workarounds under the hood similar to what people  
>are already scripting. On the other hand, if they are using something  
>more like red-black trees, it is trivial to walk the tree in order and  
>return the elements. Or backwards. Or "next" and "prev" functionality.  
>But... I have no idea what data structure they are using.
>
>FWIW.
>
>- Brian


This is all very interesting because it forces me to think outside my usual uses for containers. I'm now forced to acknowledge that a parallel image map, of all data kept in my cube, could have meaningful names, in a parallel structure that is a mirror of my containers. I just need to store data in myArray[2][3][1] and the names (keys) in myKeys[2][3][1]. I would never give the array keys. I would just imply them in my parallel array. But that does not address sorting.

For that matter I could parse the cube (illusion) by keeping the map as items in a single list.

Example: 2~3~1 Rat~Boy~Juice, 4~32~880 The~Waterboy, etc...

I could then sort items of myListArray by word 2 of each. 

You can have almost instant access to your data with offset and a few tests of the local items found in a smaller chunk of the larger list. A local items function. Gads, you could index a book this way.

There must be all kinds of things beyond sort for associating keys.

I'm saying that you can structure it as like red-black trees yourself. Then you can walk it yourself for the elements, at least I think you can.

Thank you Brian. You have just made me see more uses for this.

Mark