Concatenation of tables in Lua

Question

ORIGINAL POST

Given that there is no built in function in Lua, I am in search of a function that allows me to append tables together. I have googled quite a bit and have tried every solutions I stumbled across but none seem to work properly.

The scenario goes like this: I am using Lua embeded in an application. An internal command of the application returns a list of values in the form of a table.

What I am trying to do is call that command recursively in a loop and append the returned values, again in the form of a table, to the table from previous iterations.

---

EDIT

For those who come across this post in the future, please note what @gimf posted. Since Tables in Lua are as much like arrays than anything else (even in a list context), there is no real correct way to append one table to another. The closest concept is merging of tables. Please see the post, "Lua - merge tables?" for help in that regard.

Solution 1

Overcomplicated answers much?

Here is my implementation:

function TableConcat(t1,t2)
    for i=1,#t2 do
        t1[#t1+1] = t2[i]
    end
    return t1
end

Solution 2

If you want to concatenate an existing table to a new one, this is the most concise way to do it:

local t = {3, 4, 5}
local concatenation = {1, 2, table.unpack(t)}

Although I'm not sure how good this is performance-wise.

Solution 3

And one more way:

for _,v in ipairs(t2) do 
    table.insert(t1, v)
end

It seems to me the most readable one - it iterates over the 2nd table and appends its values to the 1st one, end of story. Curious how it fares in speed to the explicit indexing [] above

Solution 4

A simple way to do what you want:

local t1 = {1, 2, 3, 4, 5}
local t2 = {6, 7, 8, 9, 10}

local t3 = {unpack(t1)}
for I = 1,#t2 do
    t3[#t1+I] = t2[I]
end

Solution 5

To add two tables together do this

    ii=0
for i=#firsttable, #secondtable+#firsttable do
    ii=ii+1
    firsttable[i]=secondtable[ii]
end

use the first table as the variable you wanted to add as code adds the second one on to the end of the first table in order.

• i is the start number of the table or list.
• #secondtable+#firsttable is what to end at.

It starts at the end of the first table you want to add to, and ends at the end of the second table in a for loop so it works with any size table or list.

View more solutions

Comments

[gimpf]

Possible dupe: stackoverflow.com/questions/1283388/lua-merge-tables. You mention "recursivly in a loop". Do you search for a deep-copy + merge?

[John Mark Mitchell]

The following are the links I found that offered solutions: ardoris.wordpress.com/2008/08/10/… idevgames.com/forum/archive/index.php/t-10223.html Though I understand the approach of each, neither seem to work. Do you have a working solution?

[John Mark Mitchell]

gimpf, maybe I am not being completely clear. Merging tables and concatinating tables are similar but very different. I am interested in appending one table to another, thus the use of the word concatenate.

[gimpf]

Please see my edit; an example of what you want to do in the form of 3 lua tables (2 in, 1 out) would be very helpful.

[John Mark Mitchell]

gimf, you were right. I was misinterpreting the use of lists in Tables to think that they could simply be concatenated. Further testing led me to the conclusion that what I really needed to be doing was a merge. Thank you for your help and patience with a Lua newbie.

[gimpf]

+1 on the notion for "natural result of a function ... return a list of results". This is quite probable.

[RBerteig]

@John, we were all newbies once... coming from complex languages, it is sometimes surprising how much power is hiding inside Lua's simplicity. It can take a while to grok it.

[Joseph Kingry]

I think there is an error in this function, I think you need another select in there after the for to get the actual value out of .... lua-users.org/wiki/VarargTheSecondClassCitizen See Issue 8

[RBerteig]

Yup. Apparently I didn't test this code before posting, or that defect would have been obvious. More obvious in hindsight is the missing return t before the last end.

[scravy]

This is wrong. You have to start with i=(#firsttable+1), or you will munch over the last element in the first table. In case of the first table being empty you will even try to access firsttable[0], but arrays are indexed starting with 1 in lua.

[Nas Banov]

why the {unpack(t1)} ?! all it does i make copy of t1 but question implied updating in-place?

[Nas Banov]

wouldn't ipairs iteration with table.insert be better (more readable and/or faster)?

[Weeve Ferrelaine]

ipairs is barely more costly than normal, the reason not to use it is it doesn't guarantee order of items in the table. the reason not to use insert is it's dramatically more costly than a standard index set on a table, because insert will call a routine that pushes values in the table back from the index it was called on, while there are no values past [#t+1], the routine is still called, causing a performance issue, on a compiled language, there is no difference, but using an interpreted language, we have to be careful what all we ask the computer to do for us

[Nas Banov]

From what i know, ipairs guarantees iteration order be for i=1 ... till the first t[i]==nil, no? Which for non-degenerate cases is same as for i=1,#t. Re insert vs indexing set though, you are right - i measured and there is 5-6x performance difference

[Weeve Ferrelaine]

I'm pretty sure I read somewhere that pairs doesn't guarantee order, but you may be right, although it's most likely a safe assumption that it will be ordered, whether guaranteed or not- The code is correct, it should not be [#t1+i], because #t1 will increase as the table size goes up, leaving a sparse table (almost always a bad thing in Lua)

[Nas Banov]

NB: ipairs ~= pairs. There is a reason for the "i". pairs is disorderly, ipairs isn't

[warspyking]

@NasBanov He asked how to concatenate. When you concatenate strings you get a new string. I assumed he wanted something like that.

[Nas Banov]

hmm, you are right regarding the word "concatenation" in the title. But the question speaks about "appending", which is a mutator. Still { unpack(tbl) } is a neat trick for cloning a table - with limitations (something like 1M elements)

[warspyking]

@NasBanov However this contradiction in terms is the questioner's fault, so I see accepting either answer as valid and correct is fine.

[thomas]

@GermanK no bug. t1 is the table being inserted into, thus #t1+1 is the length of t1 plus 1 (i.e. where you should be inserting the next item).

[GermanK]

@thomas Right! Should I delete my comment to avoid confusion?

[thomas]

@GermanK might be an idea to update your comment to show its not a bug. If you can't then I'm not sure.

[GermanK]

@thomas Yeah, I couldn't, so I deleted it. Yet. this discussion remains as archeological evidence for its previous existence :) Thanks for catching that!

[Dave Yarwood]

Shouldn't the third line be t1[#t1+i] = t2[i]?

[detly]

The fact that this both mutates the first argument AND returns it is a little confusing, although I guess the OP didn't say what interface they wanted.

[G. B.]

the third line should be 't1[#t1+1] = t2[i]', otherwise in the 2nd iteration #t1 is 2 and i is 2 and the index 3 is skipped. I'll edit the answer

[user202729]

Just note that this only work if table.unpack is the last argument (unlike Python's *t or JavaScript's ...t), see stackoverflow.com/questions/37372182/…

[Admin]

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.