-----Original Message----- >From: Brian Yennie <[EMAIL PROTECTED]> \> >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 _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution