Re: Unexpected table.remove behaviour.

[Doug Currie <doug.currie@...>]

On Jun 24, 2009, at 4:15 PM, lostgallifreyan wrote:

> 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.

Your solution(s) using table.remove do a quadratic number of table  
moves. Here's an approach that's linear, scans in the forward  
direction, and doesn't leave any holes in X or Y:

function t2()
    local  
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 
}
    local Y={}
    local k = #X -- initial size
    local i = 1  -- insert point
    for n = 1, k do
        local e = X[n]
        X[n] = nil
        if e ~= X[i-1] then Y[i] = n; X[i] = e; i = i + 1 end
    end
    print(i-1)
    print(unpack(X))
    print(unpack(Y))
end

-- e