We want to make the Lua sandbox deterministic. It means that when you run the same Lua code (with identical input variables too), you always get the same results.

Some functions are deterministic by default, for example math.ceil(). It always gives the same result for the same input.

It turns out that most functions are that way. Computers are a deterministic appliance, after all. Only those functions concerned with I/O or random numbers are not deterministic.

So we now collect all the non-deterministic functions in the API and wrap them properly so we get a fully deterministic sandbox environment. This is a very important feature that TinyBrain offers - full repeatability of any computation!

So here's the current Lua API of TinyBrain (marked as DET, NON or OK if issue is not applicable to element; MAR = NON and already marked as non-det in source code):

DET assert (function)
DET error (function)
DET extractFromSnippet (function) if loadSnippet is marked NON
DET fromSystem (function) - the way it is right now anyways
DET get (function) if loadSnippet is NON
MAR getSnippet (function)
DET getmetatable (function) - but make sure it does not access things it shouldn't
DET go (function) if loadSnippet is NON
DET grab (function) see go
DET ipairs (function)
DET load (function)
MAR loadSnippet (function)
DET log (function)
NON math (table) - math.random is probably non-det
DET newCleanEnv (function)
DET next (function)
MAR os (table)
DET pairs (function)
DET pcall (function)
DET print (function)
DET rawget (function)
DET rawset (function)
DET select (function)
DET setmetatable (function) - but make sure... etc.
OK  state (table) -- ("state" is a simple empty table provided by the sandbox for convenience in certain scenarios...)
DET string (table)
DET table (table)
DET tonumber (function)
DET tostring (function)
DET type (function)
DET unpack (function)
DET want (function) see go

So if everything is OK, DET or MAR above (no "NON"s), we're fine.

One general question: What about hashcodes of objects or tables? Are those deterministic? If they're pure Java object hash codes: then they're not and we have to solve that problem too.
Edit: Solved in current code base (manual counting for hash codes). Should edit Sandbox to reset the counter for thread to make it perfect. Right now it should work anyways because we have a new coroutine (which equals a Java thread) per calculation anyways.