lua的表的一个有趣的现象(An Interesting phenomenon of Lua'

我是新来的Lua，和我正在学习表的使用这些天。从教程我知道Lua中把数字索引项和非数字索引的项目不同，所以我做了一些测试自己，今天我发现一个有趣的现象，我无法解释它：

代码

t = {1, 2, 3, a='a', b='b'}
print(#t)

得到

因为#运营商只计算数字索引项目。然后，我测试了下面的代码

t = {1, 2, 3, a='a', b='b'}
print(#t)

for i = 100,200 do
    t[i] = i
end
print(#t)

我得到

3
3

直到现在我认为Lua的对待后添加非数字索引那些那些不连续的项目。然而，当我更改代码一点点

t = {1, 2, 3, a='a', b='b'}
print(#t)

for i = 100,300 do
    t[i] = i
end
print(#t)

我得到

3
300

我被这种现象迷惑，没有人知道原因是什么？谢谢。

（这种现象可在再现http://www.lua.org/cgi-bin/demo ）

更新：

我想这个代码

t = {1, 2, 3, a='a', b='b'}
print(#t)

for i = 100,300 do
    t[i] = i
    print("add", i, #t)
end

for i = 100,300 do
    t[i] = nil
    print("del", i, #t)
end

我得到

3
add 100 3
add 101 3
add 102 3
...
add 223 3
add 224 3
add 225 3
add 226 226
add 227 227
add 228 228
...
add 298 298
add 299 299
add 300 300
del 100 300
del 101 300
del 102 300
...
del 253 300
del 254 300
del 255 300
del 256 3
del 257 3
del 258 3
...
del 298 3
del 299 3
del 300 3

这个例子说明，Lua中转换疏与密之间的表。

Answer 1:

我没有看过该怎么#运营商实现，但我敢打赌，这是怎么回事是通过添加额外的100个指数，你已经引起了范围1-300变得足够密集的指标100-300结束了在表执行而不是“哈希”部分的“阵列”的一部分。

更新：

好的，我看着源的原始表的长度。如果在阵列部分中的最后项是零，它的二进制搜索阵列找到最低“边界”（一个非零指数接着是零索引）。如果不是零，它决定了边界必须在散列并搜索它。

因此，与含表数值索引{1, 2, 3, 100..200}我假设它不是足够密集和阵列部分只包含{1, 2, 3} 但用含有表{1, 2, 3, 100..300}这是可能足够密集，阵列部分结束内的某处100..300部分（我认为阵列部分始终是一个功率的2，所以它不可能结束于300 ，但我不是100％肯定的）。

更新2：

当一个Lua表改头换面，它计算整数键的数量。然后，它走到这并不比整体按键数量的两倍多了两个一切权力，并找到两个最大功率是至少50％致密的（这意味着如果阵列部分是这个大的，至少50％的所有值将是非无）。

因此，与{1, 2, 3, 100..200}它走了

1: 100% dense; good
2: 100% dense; good
4: 75% dense; bad
8: 37.5% dense; bad
16: 18.75% dense; bad
32: 9.375% dense; bad
64: 4.6875% dense; bad
128: 25% dense; bad
256: 40.625% dense; bad

最好好的值是2，所以它最终与为2的数组大小由于2是非零，它搜索哈希为边界并且发现3 。

一旦你添加201..300最后一步变