- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am observing some unexpected behavior from RANDOM_NUMBER. I am getting differences between sequences generated by RANDOM_NUMBER after using RANDOM_SEED to set the seed. I am writing to see if anyone can confirm or deny that Intel RANDOM_NUMBER sequences only depend upon calls to either RANDOM_NUMBER or RANDOM_SEED, and there is no dependency, either on other Fortran routines or C/C++/C# libraries?
Regards,
Scott
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is not clear to me what you are doing. If you call RANDOM_SEED without any arguments, the Intel behavior is to set a "random" seed based on the date and time. However, if you are specifying seeds and are passing the correct number of seed values and the same values each time, you should get the identical sequence from RANDOM_NUMBER. There is no dependency on other libraries. You will need to first call RANDOM_SEED to get the SIZE value before allocating the seed array.
I'll comment that the "no-argument" behavior is not really defined by the standard, which is why Fortran 2015 adds a RANDOM_INIT intrinsic that lets you explicitly initialize the generator to "different" results (matching our behavior when you cal RANDOM_SEED with no arguments.)
If this doesn't explain the behavior, please provide us with a small test case and sample output showing the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here's a code sample,
subroutine SetSeed( seed ) integer(kind=4), intent(in) :: seed integer(kind=4), allocatable :: seedlist(:) integer(kind=4) :: size if (CheckValues()) then call RANDOM_SEED(size=size) allocate(seedlist(size)) seedlist(1)=seed seedlist(2:size)=1 call RANDOM_SEED(put=seedlist) init = 1 endif end subroutine SetSeed
I haven't been able to reproduce the problem with a small test case. In subsequent calls, RANDOM_NUMBER is called with a scalar REAL(4) argument. I am currently trying to confirm that there's not a hidden call to RANDOM_SEED elsewhere in the client's code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Or maybe another call to RANDOM_NUMBER. When you get a test case, let us know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Even a hidden call to RANDOM_NUMBER should produce the same results each time, given the same inputs (I think). I'm certain I'll find it, and your response about dependencies helps because it eliminates at least one possible cause that would have been more difficult to find.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok - I'll be interested in what you find. We implement our own random number generator, based on an algorithm by L'Ecuyer (1990).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> I am currently trying to confirm that there's not a hidden call to RANDOM_SEED elsewhere in the client's code.
You also have to confirm there isn't a hidden call to RANDOM_NUMBER (or that they haven't parallelized the code).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jim, that's a good point. I hadn't checked whether they're running multithreaded. Having a call to RANDOM_NUMBER doesn't seem to me to introduce variability, by itself. Running the code twice should produce the same result with the same inputs (including the seed). However, running in parallel could potentially change the order of operations from run to run. I'll check that as well.
Scott
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page