17 May 2013 14:18
[fortran, doc] Improve random_seed example
Janne Blomqvist <blomqvist.janne <at> gmail.com>
2013-05-17 12:18:01 GMT
2013-05-17 12:18:01 GMT
Hi,
the example we provide for the usage of the random_seed intrinsic
could be better. At least one user has already been tripped over by
the fact that on some targets the first call to system_clock returns
0, resulting in a poor seed. Below is an improved(?!) example program.
Ok for trunk/4.8/4.7? (Changelog + patch is of course trivial once
there is agreement on the code itself)
! Seed the random generator with some random input
module rseed_rand
contains
subroutine rseed()
implicit none
integer, allocatable :: seed(:)
integer :: i, n, un, istat, dt(8), pid, t(2), s
integer(8) :: count, tms
call random_seed(size = n)
allocate(seed(n))
! First try if the OS provides a random number generator
open(newunit=un, file="/dev/urandom", access="stream", &
form="unformatted", iostat=istat)
if (istat == 0) then
read(un) seed
close(un)
else
! Fallback to XOR:ing the current time and pid. The PID is
! useful in case one launches multiple instances of the same
(Continue reading)
* * *
I think the mvbits regressions are related to elem_len != sm, i.e. since
dtype's size (now: elem_len) no longer matches stride multiplier, it
fails. But maybe that's the wrong assessment.
TODO:
- Fix the 4 regressions
- Remove the "offset" field/component from the descriptor
- Set lower_bound == 0 for the args to a nonpointer/nonalloc dummy argument.
- Handle elem_len != n*stride throughout the code
- Audit the use of elem_len, stride/sm, ubound, type, attribute for
correctness and performance optimization (e.g. making use of the
lower_bound==0 knowledge)
RSS Feed