RE: Sorting table compares with nil

["Gavin Kistner" <gavin.kistner@...>]

From: Rici Lake
Sent: Monday, July 02, 2007 5:05 PM
> On 2-Jul-07, at 5:35 PM, Gavin Kistner wrote:
> 
> >
> > Given the presence of 00F08860 getting passed to my comparison 
> > function,
> > it seems that table.sort tries to sort all the integer keys in the
> > array, instead of the convential "from 1 up to the first 
> nil" view of 
> > an
> > array.
> 
> table.sort(t) sorts elements with keys from 1 to #t. #t is not
> uniquely determined for tables whose integer keys are sparse.

Ah, that'd do it, thanks. I guess I was thrown by some of Lua (e.g.
ipairs) being happy to treat a table as an array up until the first
hole. When I turn my head 180 degrees with the above and change my
mental model to say "arrays with holes are a bad idea in general", then
I feel much better about how table.sort behaves.


> > Is this behavior expected? Do I need to wipe out all the subsequent
> > values, instead of just inserting a nil marker?
> 
> Yes. Maybe you should just construct a new table instead of trying to
> recycle the old one. For example, as far as I can see, your current
> code leaves old reverse-lookup elements in place, which could create
> something which looks a lot like a memory leak.

Thanks for the advice, but I'm concerned that allocating a new table
each frame may be prohibitively expensive on game consoles where memory
coherency is king. It's possibly an uninformed, premature optimization,
but it seems to work acceptably as is, now that I'm tracking the old
length and wiping out the extra keys.

(And I do get the memory leak comment, but elements can never go away in
this particular system.)

Thanks again for your help, Rici!