For a long time, the lsst.afw.math.Random constructor has disallowed seed=0: the doxygen says:
Passing a seed-value of zero will cause the generator to be seeded with an algorithm specific default value.
although passing seed=0 actually results in a exception.
It is desirable to never use seed=0 when initialising the GSL random number generator underlying our implementation (because we want to know the seed we've used, which isn't possible when seed=0), but I don't think this restriction should be passed on to the user since it can be hidden, so it's an unnecessary burden on the user.
I propose changing lsst.afw.math.Random to allow seed=0 to be provided by the user. The proposed code change results in changes to the mapping between the seed provided to lsst.afw.math.Random and the seed used in GSL, which means that old seeds we've recorded will not produce the same set of random numbers. While this will necessitate updating the values in the Demo, I don't anticipate any further problems because:
- lsst.afw.math.Random is not used as often as numpy.random.
- Besides the Demo, we don't rely on getting the exact same set of random numbers anywhere that I'm aware of.
- If there is a need to get the exact same set of random numbers for some reason (e.g., comparing modern results to results obtained before the change for the sake of debugging), we can calculate the seed to provide to lsst.afw.math.Random that will produce the same GSL seed we used under the former scheme.