Re: Unexpected table.remove behaviour.

[lostgallifreyan <lostgallifreyan@...>]

Enrico Colombini <erix@erix.it> wrote:
(24/06/2009 20:24)

>Complexity is in the eye of the beholder :-)
>Some people (myself, for example) find the dual nature of Lua tables 
>simple, elegant and powerful.
>

Agreed.

>If you are not comfortable with it, just think of arrays and hash tables 
>as two different structures and use *either* one or the other. Don't 
>make holes in arrays (use 'false' or a special marker if you need) and 
>they won't make holes in your code :-)
>

Not entirely agreed. :)

Suppose you have a LONG table full of several thousand NMEA sentences or whatever.. If you need to thin data in place according to some rule, you need table.remove(). But if you use ipairs() you work forwards from index 1. I read that this can involve a lot of moving of elements to fill gaps, so the less you have to move, the better. So either you must populate a new table, or work in place, backwards, as that moves less data around, so is faster than forwards.

    X={0,0,0,0,0,1,1,1,1,2,2,3,4,5,5,5,5,5,6,6,6,6,6,6,6,6,7,8,8,8,8,8,8,8,8,8,9,9,9,9}
    Y={}
    for N=#X,1,-1 do
      Y[N]=N
      if X[N]==X[N+1] then  table.remove(X,N+1)  table.remove(Y,N+1)  end
    end
    print(unpack(X))
    print(unpack(Y))

That one, if translated for Lua v4, works, but currently #Y cannot be equal to #X because Y has holes in it (though note my other mails showing that in some conditions it CAN, uncontriollably, be bigger than the minimum contiguous array from index 1).

As setn is no more, we can't force a state that allows table.remove to sync these two tables either! The only workround is to first generate Y full of zeros, or something. That's clumsy. What I really want to see is something like #Y=n, bringing setn inline with the way n=#Y has replaced n=getn(Y), though I have no idea if this can be done easily and without conflict.