MSallermann
commented
3 months ago Hi Daivik,
I don't think this had any influence on the simulations.
I think this was more of a cosmetic issue, since it's confusing for the user if the input config.toml file contains a large number as a string (large enough to make the internal representation as an int32 overflow) and, due to that, the logs contain a different seed than was entered in the input file. Effectively, the same seed in the input file (overflow or not) would still lead to the same simulation behaviour.
Regarding the choice of signed vs unsigned: Yeah, it would probably make sense to choose a uint64 as the internal representation of the rng_seed (which is the result type of std::mt19937_64 and would also, of course, cover std::mt19937). I am not sure the TOML spec defines unsigned integers though and how the library we use for parsing toml files behaves in the extremal cases. But yeah, good point and worth considering
Hello sir, I would like to know about how this affected the simulation? Also we, Rohit sir and me recently saw this as I also used it in the bindings, the random_device()() result type is unsigned int then again is using int64 a better choice or can we just use auto ?