Arrays: new and old keys, i

[Brian Yennie]

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.

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.

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

> You enter the keys into the list while you enter real data stored  
> behind these keys that are the individual containers. It was in my  
> previous post, kind of. I just left out the process.
>
> Let's assume that there is no sort function for keys added or order  
> of entry
> set controls.
>
> put chars 4000 to 5000 of zigzag into myArray[4]["4000to5000"]
> -- this is the data being stored
> -- It received the key "4000to5000"
>
> -- I then created a layer/zone - whatever, (a list) that is appended  
> as I add more and more data with keys added to the layer myArray[4].  
> Now that I think of it, and keeping with the illusion that I'm  
> always going to keep any dimensional layer's (key registry) in  
> ["keyReg"]. There might be a time when I want to use layer [9].
>
> put "4000to5000," after myArray[4]["keyReg"]["sorted"] -- sort this
> put "4000to5000," after myArray[4]["keyReg"]["notSorted"]
> put "4000to5000," after myArray[4]["keyReg"]["entryOrder"]
> put "4000to5000," after myArray[4]["keyReg"]["globalEntryOrder"]
>
>
> Later you can sort the list of keys in myArray[4]["keyReg"]["sorted"]
>
> Do you see it yet. "4000to5000" is the key to those 1000 characters  
> that were stored in the dimensional array.
>
> You want at it in the order that it was entered:
> put myArray[4][ item 2 of myArray[4]["keyReg"]["entryOrder"] ] into  
> hThis
>
> You want at it in the order that it was sorted:
> put myArray[4][ item 1 of myArray[4]["keyReg"]["Sorted"] ] into hThis
>
> You want at it in the order that it was entered anywhere in the  
> array, any layer:
> put the number of items in myArray[4]["keyReg"]["globalEntryOrder"]  
> into tNum
> put myArray[4][ item tNum of myArray[4]["keyReg"] 
> ["globalEntryOrder"] ] into hThis
>
> I don't see the need for the engine to physically move the data if  
> the keys are sorted or custom arranged.
>
> Does that help?
>
> P.S. Those calls to the array within the calls to the array are  
> untested.
>
>
> Mark