https://issues.apache.org/ooo/show_bug.cgi?id=121421
--- Comment #2 from Pedro Giffuni <[email protected]> --- (In reply to comment #1) > It appears, based on the problems that Excel had getting a correct > implementation of the Wichman-Hill algorithm, that one must be very careful > about attempting a literal transcription of the method. > > First, salting must ensure that the initial IX, IY, and IZ values are > positive nonzero values less than the corresponding modulus values (30269, > 30307, and 30323). > > In addition, the possibility of values <= 0 as the result of integer > multiplication overflows must be protected against. Note that an > intermediate product before any MOD is taken can be as large as 5,212,632 > and the division in the implementation of MOD must work with dividends that > large as well. > The FORTRAN comment states clearly that IX, IY and IZ must be values between 1 and 30000. > I'm also marginally suspicious of all of those floating-point divisions, > since the moduli are all relatively prime to 2 (and 5). The arithmetic in > the RANDOM line should all be in DOUBLE (if not greater) and it is not clear > how many bits of the AMOD result should be considered reliable, since > recurrence patterns will happen. > I would think the divisions are made precisely to make the remainders more random. One thing that where we will necessarily lose is speed though: on FreeBSD random(3) is 2/3 the speed of rand(3). This algorithm will be at least three times slower. > Also, before claiming DIEHARD, it is really important to actually run it on > the implemented code. I can't imagine that the defects noted in the Excel > implementation would not have been caught. > Since the implementation is in C we could actually take the C code for comparison purposes before importing it. I don't see myself running the Diehard tests as I am rather lazy to fill forms though ;). -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
