On Thu, Dec 24, 2015 at 12:29:02AM +0200, Janne Blomqvist wrote: > > the GFortran random number generator (RANDOM_NUMBER and RANDOM_SEED > intrinsics) has a number of issues that the attached preliminary patch > tries to address. >
First, I think your effort to retool random numbers is a nice enhancement for gfortran. But, ... > - When RANDOM_SEED is called without arguments, the master_seed and > current thread seed is set to random data read from the OS > /dev/urandom device. Otherwise like above. Doesn't this break backwards compatibility with the current implementation. In the following program, the call to random_seed resets the stream. If an OS has /dev/urandom, then the two streamsr won't match? program prngtest real x integer i do i = 1, 5 call random_number(x) print *, x end do call random_seed print * do i = 1, 5 call random_number(x) print *, x end do end program prngtest % gfc -o z r.f90 && ./z 0.997559547 0.566824675 0.965915322 0.747927666 0.367390871 0.997559547 0.566824675 0.965915322 0.747927666 0.367390871 I realize that the above behavior and (if I understand correctly) your newly implemented behavior are both conforming. We'll definitely need to put this in the release notes. > Note that the patch is preliminary, it works so one can evaluate > performance but there are bugs (e.g. njumps is never incremented, so > all threads generate the same stream), documentation needs to be > updated, RANDOM_SEED is not tested, the fronted check for the seed > size needs to be updated, etc. Two questions. 1) Does the patch deal with PR 52879? 2) Does it maintain the correspondence between a REAL(4) and REAL(8) stream if the same seeds are used? For example, program foo integer, parameter :: seed(12) = [1, 12, 123, 1234, 12345, 123456, & & 654321, 54321, 4321, 321, 21, 1] real(4) x real(8) y call random_seed(put=seed) call random_number(x) call random_seed(put=seed) call random_number(y) print *, x, y end program foo % gfc -o z r.f90 && ./z 0.181959510 0.18195952290401995 I'll install and play with your patch shortly. -- Steve