What is the difference between ipairs and paris?

Edit: What is the difference between ipairs and paris?

Remember ipairs work only with number indexes and number indexes should be order.

( 1,2,3,.. ) not (1,3,5,.. )

pairs work with all indexes.

for i,v in ipairs(table) do 

i = iteration number

v = value of the table, it equals table

for v in pairs(table) do 

v = value of the table. You can't get the iteration number here.

ipairs won't cause any lag

basically no, you won't find any difference.

for v in pairs(table) do 

v = value of the table. You can't get the iteration number here.

That's not true.

ipairs is for indexed tables, it means every item (value) in the table has it's own number: 1 is the index of the first value 2 is the index ot the second's and so on.

Example:

local indexedTable = { 2, "something", 8239713, "asd" } 
-- it's is equal to this: 
local indexedTable2 = {  
    [1] = 2,  
    [2] = "something",  
    [3] = 8239713,  
    [4] = "asd"  
} 
  
--both pairs and ipairs will work in those tables: 
for i, v in ipairs( indexedTable ) do 
-- i is the index and v is it's value 
-- this does the same as above: 
for i, v in pairs( indexedTable ) do 
  
  

pairs is for not-indexed tables, where instead of the index number can be anthing (numbers or strings) and they can be the same too.

--both pairs and ipairs will work in those tables: 
for i, v in ipairs( indexedTable ) do 
-- i is the index and v is it's value 
-- this does the same as above: 
for i, v in pairs( indexedTable ) do 
  
  
local table = {  
    ["string"] = 2,  
    [7] = "something",  
    ["lua"] = 8239713,  
    [2231] = "asd", 
    ["lua"] = "i have no idea what to write here...",    
} 
-- ipairs won't work in this case. 
for k, v in pairs( indexedTable ) do 
-- for pairs instead of "i" I usually use "k" wich means key (of the value). 
-- so, k will be the key( e.g. "string" at the first in this example ) 
-- and v will be it's value 

for v in pairs(table) do 

v = value of the table. You can't get the iteration number here.

That's not true.

ipairs is for indexed tables, it means every item (value) in the table has it's own number: 1 is the index of the first value 2 is the index ot the second's and so on.

Example:

local indexedTable = { 2, "something", 8239713, "asd" } 
-- it's is equal to this: 
local indexedTable2 = {  
    [1] = 2,  
    [2] = "something",  
    [3] = 8239713,  
    [4] = "asd"  
} 
  
--both pairs and ipairs will work in those tables: 
for i, v in ipairs( indexedTable ) do 
-- i is the index and v is it's value 
-- this does the same as above: 
for i, v in pairs( indexedTable ) do 
  
  

pairs is for not-indexed tables, where instead of the index number can be anthing (numbers or strings) and they can be the same too.

--both pairs and ipairs will work in those tables: 
for i, v in ipairs( indexedTable ) do 
-- i is the index and v is it's value 
-- this does the same as above: 
for i, v in pairs( indexedTable ) do 
  
  
local table = {  
    ["string"] = 2,  
    [7] = "something",  
    ["lua"] = 8239713,  
    [2231] = "asd", 
    ["lua"] = "i have no idea what to write here...",    
} 
-- ipairs won't work in this case. 
for k, v in pairs( indexedTable ) do 
-- for pairs instead of "i" I usually use "k" wich means key (of the value). 
-- so, k will be the key( e.g. "string" at the first in this example ) 
-- and v will be it's value 

Thanks a lot. Now I finally know the difference between them.

Just in case someone thinks that an array with only numbers as indexes is an indexed array too, no, it isn't. An array needs all indexes in the right order to be an indexed array.

for i,v in ipairs(table) do 

i = iteration number

Not really, "i" can be anything else, and it has the value of the index (example: table["example"] = "example_1"; --here, "example" is the index, and it IS NOT a number).

v = value of the table, it equals table

Not the best explanation, but you can say that.

I see. Is LUA multi-threaded?

You've got to control threads by yourself when loading LUA code in a software AFAIK (in this case, it's the MTASA). Not sure if this is what you're talking about.

You've got to control threads by yourself when loading LUA code in a software AFAIK (in this case, it's the MTASA). Not sure if this is what you're talking about.

For example if I have a code like this.

  
function doSomething() 
  
for 1, 1000000 do print("Did!") end 
  
end 
function doAnother() 
  
print("Did!") 
  
end 
  
doSomething() 
doAnother() 
  

Will it prints the doAnother first or wait for doSomething to complete then move onto doAnother?

It will wait for 'doSomething' to finish and then call the next. You can use coroutines to "bypass" that, though (it's like a threading library, built into LUA).

function doSomething() 
  
for i=0, 1000000 do print("Did!") end 
  
end 
function doAnother() 
  
print("Did!") 
  
end 
  
doSomething() 
doAnother() 
  

function doSomething() 
  
for i=0, 1000000 do print("Did!") end 
  
end 
function doAnother() 
  
print("Did!") 
  
end 
  
doSomething() 
doAnother() 
  

for index = 1, 1000000 do 
    print ( "Did!" ); 
end 

Arrays in LUA start in index 1, not 0