Tables again... - WoWInterface
12-18-19, 03:19 AM   #1
doofus
A Flamescale Wyrmkin
Join Date: Feb 2018
Posts: 126
Tables again...

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.

Last edited by doofus : 12-18-19 at 03:37 AM.

12-18-19, 05:43 AM   #2
Kanegasi
A Firelord

Join Date: Apr 2007
Posts: 487
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.

Last edited by Kanegasi : 12-18-19 at 05:45 AM.

12-18-19, 05:06 PM   #3
Seerah
Fishing Trainer

Join Date: Oct 2006
Posts: 10,733
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: http://lua-users.org/wiki/TablesTutorial
Here is a more in depth tutorial on tables and the table library: http://lua-users.org/wiki/TableLibraryTutorial
__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh

12-19-19, 05:15 PM   #4
doofus
A Flamescale Wyrmkin
Join Date: Feb 2018
Posts: 126
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:

table.insert(t,1,500)

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.

12-19-19, 06:58 PM   #5
Nimhfree
A Frostmaul Preserver
Join Date: Aug 2006
Posts: 264
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".

12-20-19, 02:04 AM   #6
doofus
A Flamescale Wyrmkin
Join Date: Feb 2018
Posts: 126
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.

table.remove(t,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.

table.insert(t,1,"night")

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

12-20-19, 11:38 AM   #7
Vrul
An Onyxian Warder

Join Date: Nov 2007
Posts: 353
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:
Code:
```local function GetArraySize(table)
local index = 1
while table[index] ~= nil do
index = index + 1
end
return index - 1
end```
Think of table.insert as:
Code:
```local function InsertIntoArray(table, index, value)
for i = #table, index, - 1 do
table[i + 1] = table[i]
end
table[index] = value
end```
Think of table.remove as:
Code:
```local function RemoveFromArray(table, index)
local value = table[index]
for i = index, #table - 1 do
table[i] = table[i + 1]
end
table[#table] = nil
return value
end```

12-20-19, 12:27 PM   #8
Seerah
Fishing Trainer

Join Date: Oct 2006
Posts: 10,733
 Originally Posted by doofus 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: http://www.lua.org/pil/2.5.html
__________________
"You'd be surprised how many people violate this simple principle every day of their lives and try to fit square pegs into round holes, ignoring the clear reality that Things Are As They Are." -Benjamin Hoff, The Tao of Pooh

12-21-19, 09:06 AM   #9
SDPhantom
A Pyroguard Emberseer

Join Date: Jul 2006
Posts: 1,924
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 a.name as syntactic sugar for a["name"]. There are several convenient ways to create tables in Lua (see §2.5.7). http://www.lua.org/manual/5.1/manual.html#2.2
I'd also go over the Table Manipulation section of the function references.
http://www.lua.org/manual/5.1/manual.html#5.5
__________________
 "All I want is a pretty girl, a decent meal, and the right to shoot lightning at fools." -Anders (Dragon Age: Origins - Awakening)

12-25-19, 11:02 PM   #10
Roeshambo
A Murloc Raider
Join Date: Jul 2019
Posts: 5
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.

Last edited by Roeshambo : 12-25-19 at 11:13 PM.

12-26-19, 12:28 AM   #11
SDPhantom
A Pyroguard Emberseer

Join Date: Jul 2006
Posts: 1,924
 Originally Posted by Roeshambo 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.
https://www.lua.org/manual/5.1/manua...pdf-table.sort
__________________