The following code:
RNG_reset(0);
bvec bits = randb(2500);
produces different results on different machines with same OS (openSUSE 12.1 x86_64).
Could you confirm this behavior ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SSE2 can be an issue. __SSE2__ instruction set can be used on some machines to speed things up. Check if you have __SSE2__ defined. I do not see any other reasons for such behavior.
PS there can unpredictable things happen if you call rng functions simultaneously from several threads.
Last edit: andy_panov 2012-11-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just finished testing the RNG core. Doubles are within 5*epsilon range from the original implementation by Mutsuo Saito, Makoto Matsumoto (They provide some test vectors)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The following code:
RNG_reset(0);
bvec bits = randb(2500);
produces different results on different machines with same OS (openSUSE 12.1 x86_64).
Could you confirm this behavior ?
PS there can unpredictable things happen if you call rng functions simultaneously from several threads.
Last edit: andy_panov 2012-11-10
I've just finished testing the RNG core. Doubles are within 5*epsilon range from the original implementation by Mutsuo Saito, Makoto Matsumoto (They provide some test vectors)
One more thing - SSE2 support seems to be broken (test fails with SSE2 enabled on msvc). I'll try to look into it and provide a fix.
I've managed to test the SSE2 code with msvc and updated my patch (see feature request #90). Results are coincide with generic implementation without SSE2 support. Unfortunately we still can not enable SSE2 support for msvc since it has problems with data alignment in thread-local storage (see http://connect.microsoft.com/VisualStudio/feedback/details/764676/c-data-doesnt-get-aligned-on-thread-local-store).