Re: Unexpected table.remove behaviour.
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Unexpected table.remove behaviour.
- From: Doug Currie <doug.currie@...>
- Date: 2009年6月24日 17:22:28 -0400
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