Actually, I need to clarify what I mean by “deterministic”. I don’t mean to run the same code multiple times onto the same state.
I have 2 machines, running the exact same code (both Lua and C). They both start from a clean state. The order of insertions is identical and the data being inserted is also identical.
Is there a set of limitations (like – “keys can only be strings”) that if I follow them, pairs() will produce identical iteration order?
For example this post: http://lua-users.org/lists/lua-l/2010-01/msg00199.html claims that “In environments that demand deterministic code execution, you can either disable pointer objects as scannable keys, or enforce an order upon them.”
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On Behalf Of Tim Mensch
Sent: Friday, February 08, 2013 12:47 PM
To: Lua mailing list
Subject: Re: Deterministic table iteration
On 2/8/2013 1:37 PM, Ivo Beltchev wrote:
I’d like to know in what cases I can count on deterministic order of table iteration. I’m pretty sure if the keys are objects that are stored in memory (like tables, threads, closures, or full user data), the order is not deterministic. But what if the keys are limited to simple types, like numbers, strings, booleans, light user data? Is the order going to be always the same?
The order isn't defined unless you use contiguous integer keys starting from 1 AND you use ipairs() to iterate. Relying on a deterministic order otherwise is asking for trouble.
In reality, the order isn't going to change if the table doesn't change. But if you insert a key, the new order could be completely different.
And I've also seen the order for the exact same set of simple keys be different depending on the order of insertion into a table -- but my first point stands, that it's UNDEFINED behavior, and shouldn't be relied on.
Tim
