for i, v in pairs table1 do

I have no understanding of what this function does. I have tried reading the Lua manual as well, still no luck. If anybody could help me out, I would appreciate it a lot.

That simply iterates over each key/value pair in a table.

For example, say you have a table with three elements:

local some_table = {
  ["key1"] = "value1",
  ["key2"] = "value2",
  ["key3"] = "value3"
}

If you wanted to iterate over each value in that table, you would use the pairs loop:

for key, value in pairs(some_table) do
  print("Key: " .. key)
  print("Value: " .. value)
end

This would output:
Key: key1
Value: value1
Key: key2
Value: value2
Key: key3
Value: value3

Keep in mind that there is no guarantee as to the order things will be output when using a pairs loop unless you are using sequential numbers as the indexes.

Can I also add to this and ask, in the lua manuals it says in pairs can be not in order, why is that so? Does it cycle through all values alphanumerically instead of iterating or what?

EDIT: Just incase if anyone get's it wrong, I said in pairs, not in ipairs.

Because there's no defined "correct order" when you iterate through all of the keys a table has. With ipairs, it will iterate starting at 1, returning a series of all non-nil values at whole number keys. With pairs, there's no reasonable way to put the entries in any sort of order by key, so it is better to simply iterate the table in the simplest manner possible.

You know of any situations where it would return incorrect order with regular pairs?

I can't answer that question because you have not provided sufficient definition for what the "correct" order would be. I have a feeling you are thinking of a table with only numeric keys, or perhaps a table with only numeric or string keys. What is the "correct" order for a table with a boolean key and a function key?

Well, the manual says ipairs is guaranteed to give you the right order, and pairs isn't, any situation that proves this specific difference between pairs and ipairs?

EDIT: Nvm, it's lua users that says this, and the main point being that pairs can give you not numerical order or something. I'm just trying to get a situation where using pairs can be a disadvantageous. And not because it uses more computer speed / power but specifically the results of the for loop.

Try this out, I think it will show the out-of-order nature of pairs:

local t = {1, nil, 3}
t[2] = 2

for k, v in pairs(t) do
  print(tostring(k))
end

"pairs" will give you any order, but iterate over EVERY item.

"ipairs" will give you key-value pairs with NUMERIC keys only, starting at 1 and incrementing once until there is no value with the next key.

When you say any order, it makes me think of math.random, and I'm sure it doesn't use math.random, it does use some kind of order best suited for itself, it would just seem ridiculous if it did use math.random. Perhaps it has a list of orders from which to choose from which are best suited for it's situation. Are pairs and ipairs defined with lua scripting language or are they like part of the lua tools that are like integrated. Can I find out what kind of algorithm does pairs use?

Regards
Augustas

Pairs uses the core lua function next, which does the heavy lifting

function pairs( _t )
local typeT = type( _t )
if typeT ~= "table" then
  error( "bad argument #1 to pairs (table expected, got "..typeT..")", 2 )
end
return next, _t, nil
end
function ipairs( _t )
local typeT = type( _t )
if typeT ~= "table" then
  error( "bad argument #1 to ipairs (table expected, got "..typeT..")", 2 )
end
return function( t, var )
  var = var + 1
  local value = t[var]
  if value == nil then
   return
  end
  return var, value
end, _t, 0
end

–from the cc bios

The idea is that when data is indexed against non-numeric table keys, a hash is taken of the key names, and the data is stored in memory against those hashes (which are essentially treated as numbers).

Thus when you attempt to pull data out of the table "in order", you get it in the order defined by the values of those hashes. As opposed to, say, in the order in which the data was put into the table, or in alphabetical order.

Since the hashes aren't practically predictable, the end effect comes off as random. Obviously it isn't (and nor is math.random() for that matter), but as in any case where it's more effort to predict than is worthwhile, it may as well be.