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