Child Tables confusion

[The_Lemon]

hmm it seems when i try and print tx from this bit of code there is an error but otherwise its fine, am i missing something

local tiles = {nil,nil,nil,nil} for i = 1,4 do     tiles[i] = {nil,nil,nil,nil} end local function makeTile (x,y,n)     local tile = display.newRoundedRect( 0, 0, 64, 64, 10 )     tile:setFillColor( 0,0,1 )     tile.x = tilex(x)     tile.y = tiley(y)     tile.tx = x     tile.ty = y     tile.level = n     tile:scale( 0.01, 0.01 )     transition.to(tile, {time=300, xScale=1, yScale=1})     tiles[y][x] = {tx = x,ty = y } end print( tiles[1][1].tx ) makeTile(1,1,1)

[rob]

You’re calling your print before you set the value.  Call makeTile() first.

[jonjonsson]

[lua]

local tiles = {nil,nil,nil,nil}

print(#tiles, “Size of table”)

[/lua]

You can’t really define tables like that in Lua. That code produces “0 Size of table” because nil does not create a new entry. It’s unnecessary to define the length beforehand.

I would do at the top: 

[lua]local tiles = {}[/lua]

Then inside the loop:

[lua]tiles[y] = {}

tiles[y][x] = {tx = x, ty = y }

[/lua]

Edit, you probably want to do a check if tiles[y] exists so you don’t overwrite your other X tiles (if any)

[lua]if not tiles[y] then

    tiles[y] = {}

end

tiles[y][x] = {tx = x,ty = y }

[/lua]

[davebollinger]

as per jonjonson’s reply.

and fwiw, i like to separate the “grid” maker from the “cell” maker, fe

local funciton makeCell(col,row)   local c = display.newWhatever(...   c.col = col   c.row = row   .. whatever else (derive xy from col/row, scale, transition, etc)..   return c end   local function makeGrid(ncols,nrows,makecellfn)   local g = {}   for row = 1,nrows do -- just habit that i prefer row-major     g[row] = {}     for col = 1,ncols do -- swap loops if you'd prefer col-major       g[row][col] = makecellfn(col,row)     end   end   return g end   local grid = makeGrid(4,4,makeCell)

[paulscottrobson]

Your understanding of tables is basically wrong. They aren’t arrays like in C - they are associative arrays or dictionaries. So the ‘array index’ has no real sense of order or structure - the index can be anything.

The use as ‘classical’ arrays e.g. fred = { 1,3,4,6 } is really just syntactic sugar. What it does is create a dictionary where key1 has 1, key 2 has 3, key 3 has 4 and key 4 has 6. 

Lua tables use ‘nil’ in the value for no value - so fred = { 1,3,nil,6 } actually creates only three values - with keys 1,2 and 4 as you can see by typing

for k,v in pairs(fred) do print(k,v) end 

which dumps all the keys and values in a table.

[davebollinger]

@paul:  all true, with the caveat that lua is pretty clever wrt performance – if your keys are numeric, and “dense” enough to appear to be used as a classic array, then lua will do an array-like lookup internally.

you can see the difference if you benchmark two tables:  one filled with first 100 integers and looped “for 1=1,100”; the other filled with first 100 primes and looped “for k,v in pairs”.

so even though they’re not “classic flat arrays”, that use-case has been optimized for.  (aside, random history:  my “life.lua” in older (circa 2001) lua source distros was for benchmarking the new array indexing :D)

[The_Lemon]

ok thanks for the help guys, the reason i put those nil values in was a force of habit, even though it doesn’t do anything. The thing is i read in a lua manual that by pre-decalring table values ie

local bob = {1,2,3,4}

is quicker (less heavy on the processor) than

local bob = {} bob[1] = 1 bob[2] = 2 bob[3] = 3 bob[4] = 4  

[rob]

You’re calling your print before you set the value.  Call makeTile() first.

[jonjonsson]

[lua]

local tiles = {nil,nil,nil,nil}

print(#tiles, “Size of table”)

[/lua]

You can’t really define tables like that in Lua. That code produces “0 Size of table” because nil does not create a new entry. It’s unnecessary to define the length beforehand.

I would do at the top: 

[lua]local tiles = {}[/lua]

Then inside the loop:

[lua]tiles[y] = {}

tiles[y][x] = {tx = x, ty = y }

[/lua]

Edit, you probably want to do a check if tiles[y] exists so you don’t overwrite your other X tiles (if any)

[lua]if not tiles[y] then

    tiles[y] = {}

end

tiles[y][x] = {tx = x,ty = y }

[/lua]

[davebollinger]

as per jonjonson’s reply.

and fwiw, i like to separate the “grid” maker from the “cell” maker, fe

local funciton makeCell(col,row)   local c = display.newWhatever(...   c.col = col   c.row = row   .. whatever else (derive xy from col/row, scale, transition, etc)..   return c end   local function makeGrid(ncols,nrows,makecellfn)   local g = {}   for row = 1,nrows do -- just habit that i prefer row-major     g[row] = {}     for col = 1,ncols do -- swap loops if you'd prefer col-major       g[row][col] = makecellfn(col,row)     end   end   return g end   local grid = makeGrid(4,4,makeCell)

[paulscottrobson]

Your understanding of tables is basically wrong. They aren’t arrays like in C - they are associative arrays or dictionaries. So the ‘array index’ has no real sense of order or structure - the index can be anything.

The use as ‘classical’ arrays e.g. fred = { 1,3,4,6 } is really just syntactic sugar. What it does is create a dictionary where key1 has 1, key 2 has 3, key 3 has 4 and key 4 has 6. 

Lua tables use ‘nil’ in the value for no value - so fred = { 1,3,nil,6 } actually creates only three values - with keys 1,2 and 4 as you can see by typing

for k,v in pairs(fred) do print(k,v) end 

which dumps all the keys and values in a table.

[davebollinger]

@paul:  all true, with the caveat that lua is pretty clever wrt performance – if your keys are numeric, and “dense” enough to appear to be used as a classic array, then lua will do an array-like lookup internally.

you can see the difference if you benchmark two tables:  one filled with first 100 integers and looped “for 1=1,100”; the other filled with first 100 primes and looped “for k,v in pairs”.

so even though they’re not “classic flat arrays”, that use-case has been optimized for.  (aside, random history:  my “life.lua” in older (circa 2001) lua source distros was for benchmarking the new array indexing :D)

[The_Lemon]

ok thanks for the help guys, the reason i put those nil values in was a force of habit, even though it doesn’t do anything. The thing is i read in a lua manual that by pre-decalring table values ie

local bob = {1,2,3,4}

is quicker (less heavy on the processor) than

local bob = {} bob[1] = 1 bob[2] = 2 bob[3] = 3 bob[4] = 4