Help with a special problem

[Brooks_Van_Horn]

I've attached a pseudo-random number generator that I helped convert a few years ago. It is extremely fast and passes a multitude of randomness tests. There is a data file that need be present when it is run because it keeps the generator from cycling too often. The reason I'm opening up this code is because I have run into a weird problem.  When I run it in a CMD prompt window all is wonderful but when I put it into my MSVS 2013 program (both 32-bit and 64 bit modes I get flakey results. Specifically I get all my pseudo-random numbers lying very close to 0 or 1. I have the most current IVF 2016 R2 compiler and I get no warnings nor errors during builds. If you help me find out what's wrong, I grant you unlimited access to the file.

Thanks Very Much!

Brooks V

[mecej4]

The Values argument of the Date_And_Time() intrinsic function should be of type Integer. You have declared it as Integer(2). That is probably one cause of the flaky behavior that you saw.

There could also be problems with how the subroutine is called and what argument values are passed to it. You have only shown the source code for the subroutine, so we are missing a complete "reproducer".

[jimdempseyatthecove]

A potential issue (potential due to information not provided, but would be provided with a reproducer)
is the code is not thread safe. If you were to use this in a multi-threaded program you would get unexpected results.

Jim Dempsey

[Brooks_Van_Horn]

You invoke the routine as:

real(8):: x
   x = Ranf(1)

as far as the threading, I will check on that. Thanks for both the integer and threading comments.
Brooks V.

[jimdempseyatthecove]

For a thread-safe implementation, you must specify how you wish the generator to behave. Your implementation will depend on this question.

Most "standard" thread-safe random number generators are deterministic by picking order and protected with a critical section. Note, each thread may, in different program starts, end up with differing picking orders. Therefore, while picking order is deterministic, thread picking order is non-deterministic. The critical section generally protects the seed generations from being corrupted (which may run it to 0).

If you want to implement thread deterministic, then each thread should maintain a context of what is currently in your SAVE variables and you may wish to initialize each context at a very far separation in what would happen with sequential picking order. An alternative would be to provide each thread with a repeatably reproducible (thread 0 always gets x0, thread 1 x1, etc,,,), and all start with the same seeds. While each thread in there sequence, generates the same sequence, the returned value can get xor'ed with the thread's xn value. It would be your responsibility to choose an appropriate set of numbers for each thread. Note, this requires each thread to pass in a private context.

x = Ran(MyRNGcontext,1)

Jim Dempsey