Fixed random seed generator to generate unsigned integers instead of … #577
Conversation
|
@JoeJimFlood do you want to take a stab at writing a test to run in our continuous integration testing, that confirms this change works as expected? I envision one easy way would be setting the seed to None on to an existing test example and running to check that the final results to NOT exactly match the "expected" results with a zero seed. |
|
@jpn-- I had opened this pull request before Version 1.1 was released. Would it be better if I closed it and created a new one with the same changes applied to the v1.1 code? |
Infrastructure changes
Release instructions
need checkout
JoeJimFlood
force-pushed
the
fix_gen_random_seed
branch
from
18ae872 to
1e4ffc5
Compare
… test configuration to get example to pass automated test
…edited core_tests.yaml to call it
…ead of just settings.yaml
… it already exists
|
I added a test of the random number generator to the tests in actions. To test that I ran it using a version of the software that has that test but not the random generator bug fix, meaning that the random seed generator test should fail due to the seed always being zero. The results of that are here, where the random seed test failed and all the others passed. I guess that would mean... |
|
Looks good to me, thanks Joe! |
The value of
_MAX_SEEDin random.py is currently set to the maximum 32-bit unsigned integer, but the default data type fornp.random.RandomState().randint()is at 32-bit signed integer. This was causing an error when the default random seed was set to beNoneand triggering the random seed generation.To test this, I ran the SANDAG 1-zone examples twice and the 3-zone example once, all of which were set to use random seeds. All runs completed successfully. I compared the mode share from the two 1-zone runs. They weren't exactly the same but at most were within 0.3%, which is what I would expect if the random seed generator worked correctly.