At the moment, requiring 'randomkit' multiple times will create multiple tables each with its own state, therefore causing potential problem if two subfiles both require 'randomkit' (as may almost surely happen when plenty of libraries are included). Of course, since all will be calling THRand(), the problem is not as huge as it could be, but we still have the problem of the dangling gaussian being different throughout all those versions of the package.
What I suggest: in init.lua, check if the table returned by getRNGState() already has a randomkit field in it, and if that's the case, use that as the state rather than creating a new one.
Downside: it will make thread-safe versions harder.
Solution: making require 'randomkit' return a function that can take options, e.g.
local rk = require 'randomkit'({useNewState=true})
and if no new state is required, then use the strategy above to use the common state.
jucor
commented
11 years ago
At the moment, requiring 'randomkit' multiple times will create multiple tables each with its own state, therefore causing potential problem if two subfiles both require 'randomkit' (as may almost surely happen when plenty of libraries are included). Of course, since all will be calling THRand(), the problem is not as huge as it could be, but we still have the problem of the dangling gaussian being different throughout all those versions of the package.
What I suggest: in init.lua, check if the table returned by getRNGState() already has a randomkit field in it, and if that's the case, use that as the state rather than creating a new one.
Downside: it will make thread-safe versions harder. Solution: making require 'randomkit' return a function that can take options, e.g.
and if no new state is required, then use the strategy above to use the common state.