WoWInterface (
-   Lua/XML Help (
-   -   Tables again... (

doofus 12-18-19 03:19 AM

Tables again...
Could someone please help me with this :

t = { };

t["a"] = "alpha"

This means key is string "a" and value is string "alpha". This will never change unless I assign another value to it explicitly.

Now we do,
t[1] = 100

This means the key is unknown, the value is the number 100 (or is it a string?).

If we pairs(t) now we get
k:1, v:100
k:a, v:alpha

Then we do
table.insert(t, 1, 500)

If we pairs(t) now we get

k:1, v:500
k:2, v:100
k:a, v:alpha

So it appears keys 1 and 2 are not immutable keys but positions disguised as keys ? It is all so confusing.

Kanegasi 12-18-19 05:43 AM

When dealing with sequential numbers as keys, the table is an array. Using table.insert and table.remove shifts the array to accommodate what you inserted or removed. The number 100 (not string) was at index 1, but when you inserted 500 at that position, it moved 100 to index 2. Anything dealing with arrays ignores keys that aren't sequential up from 1, which also means index 0 and negative indexes are also ignored.

The #t operation counts the array part of the table. The last part of your example makes #t == 2, since "a" is ignored.

Seerah 12-18-19 05:06 PM

To add to what Kanegasi said...

When you did t[1]=100 you assigned the number 100 to the first index of the table. (You can assign a value to any index, and you don't even have to do it sequentially.) 1 and 100 are then an index, value pair. (Keys are strings, indices are numbers.)

Here is more information on table basics and how to work with tables:
Here is a more in depth tutorial on tables and the table library:

doofus 12-19-19 05:15 PM

I am more confused now :)

t[1] = 100
t[2] = 200
t["hello"] = "goodbye"

which is a data structure where:

k:1 v=100
k:2 v=200
k:hello v="goodbye"

Naturally we take 1, 2, "hello" to be "keys" in the traditional sense of sets/maps

Then we do:


and this gives

k:1 v=500
k:2 v=100
k:3 v=200
k:hello v="goodbye"

So even though t["hello"] does not change, t[1], t[2], t[3] etc might all change if I do table.insert() ??

This is not at all how sets or maps work, so I find this data structure weird... I am confused.

Nimhfree 12-19-19 06:58 PM

The "key" to understanding this is that in your example, 1 and 2 are not keys. They are indexes. If you want them to be keys they need to be strings like "1" and "2". The table data structure at the same time handles data accessed via index and key. Tables are also sparse in that the indexes do not have to be contiguous. E.g., you can have t[1], t[7] and t[13] without the expected t[2], t[3], etc. values. And as you have seen you have have arbitrary keys like "hello" and "a".

doofus 12-20-19 02:04 AM

I do not think this is right. t[1] is not an integer index, there is NO "position 1" in the table, unless, and only if, I define k[n], where n is an integer, either by k[n]=value or by table.insert(t,n,value).

Otherwise there is no "position 1" in the table. eg

t = { };
t["hello"] = "goodbye";

t does not have position 1.


Does not do anything, there is no "position 1" and t["hello"], even though the only element in the table, is NOT considered to be position 1, or ANY position at all.

t[2] = "day"

Now t does have a position 1.


now we have position 1 = "night" and position 2 = "day"

All the while t["hello"] has not been affected, it is like independent...

The way to understand this is that a table has two types of keys and accessing mechanisms, string keys and integer keys. Integer key/value pairs can be affected by table.insert / remove but string key/value pairs are not.

This is what I have fathomed by running tests all in between wiping in M+10 because we do not know the strats...

Vrul 12-20-19 11:38 AM

Think of Lua tables as maps that can also be treated as arrays. The array behavior is only for the portion of the map that starts with the key of integer 1 and continues until a nil value is reached for sequential integer keys.

ipairs, #table, and the functions found in table (such as table.insert) only apply to the array portion of the map.

Think of #table as:

local function GetArraySize(table)
    local index = 1
    while table[index] ~= nil do
        index = index + 1
    return index - 1

Think of table.insert as:

local function InsertIntoArray(table, index, value)
    for i = #table, index, - 1 do
        table[i + 1] = table[i]
    table[index] = value

Think of table.remove as:

local function RemoveFromArray(table, index)
    local value = table[index]
    for i = index, #table - 1 do
        table[i] = table[i + 1]
    table[#table] = nil
    return value

Seerah 12-20-19 12:27 PM


Originally Posted by doofus (Post 334816)
I do not think this is right.

You don't understand it, but we're wrong?

Did you go through the tutorials I suggested?

Here also is the chapter on tables from Programming in Lua:

SDPhantom 12-21-19 09:06 AM

Quoting the Lua 5.1 manual too.

The type table implements associative arrays, that is, arrays that can be indexed not only with numbers, but with any value (except nil). Tables can be heterogeneous; that is, they can contain values of all types (except nil). Tables are the sole data structuring mechanism in Lua; they can be used to represent ordinary arrays, symbol tables, sets, records, graphs, trees, etc. To represent records, Lua uses the field name as an index. The language supports this representation by providing as syntactic sugar for a["name"]. There are several convenient ways to create tables in Lua (see 2.5.7).

I'd also go over the Table Manipulation section of the function references.

Roeshambo 12-25-19 11:02 PM

Tables are basically arrays (but a bit more complex if you start manipulating meta tables etc). To break it down dummy style, you have indexed arrays (1, 2, 3, 4 as keys) and associative arrays (custom keys such as t["key1"]. ipairs will only cycle through the indexed keys (hence the I in it) and ignores the associative portion of the table. pairs covers all of it. It's really not confusing once you realize that if it's just a number, it's an indexed key. If it's got words, it's an associative key. But when you do ipairs, it will only cycle until it finds a nil value. So if you create keys 1, 2, 3 and 5, it will only cycle through 3 (since 4 is nil). Once you get that basic understanding down it gets really easy to see how they can be manipulated. Of course, they are NOT arrays. But you can very easily swap the concepts to get a basic understanding of them.

When you do table.insert(t, 1, 500), you're not replacing the 1 key's value. You're essentially pushing a new key value pair into the first position which pushes all other keys down one position. The point of an indexed table is they can be sorted and can be manipulated in that order (the keys don't remain constant). Where as in an associative array, if you sort it, you're going to have to use "next" or "for k,v" to cycle through it in the proper order.

SDPhantom 12-26-19 12:28 AM


Originally Posted by Roeshambo (Post 334841)
Where as in an associative array, if you sort it, you're going to have to use "next" or "for k,v" to cycle through it in the proper order.

table.sort() doesn't work on associative keys. It only works on the sequential portion of the table. The order of key/value pairs iterated from next() and pairs() are completely random. Even among sequential keys. This is why ipairs() exists instead of using pairs() for that too.

All times are GMT -6. The time now is 10:08 AM.

vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI