[
https://issues.apache.org/jira/browse/RNG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868539#comment-16868539
]
Alex D Herbert commented on RNG-16:
-----------------------------------
The reference LCG implementations listed on wikipedia from many libraries are
legacy generators designed when 64-bit arithmetic was expensive. Many output
only 16-bits from a 32-bit state so avoiding the lower bits which have a period
of 2^n where n is the bit index from the least significant upward.
Adding matching implementations of these generators to the Commons RNG library
to match exactly the output of those generators would fail to satisfy the
contract of the UniformRandomProvider interface. For example the nextInt()
method should output a full 32-bit integer (positive and negative). To satisfy
theses requirements means breaking the compatibility with the primary output
from the reference. Consequently these generators would be unsuitable for
general purpose use for any code expecting a functional UniformRandomProvider.
It seems odd to add such restricted generators to satisfy a requirement of a
standard cross platform generator. Which one should be the standard? If we
match them all in Java then you have a situation where your client can be
written in Java and the other language where the generator is standard. But you
may be limited to 2 languages which share a generator.
In addition the term 'standard' is loosely applied. If the language does not
provide explicitly the formula for the LCG then it is subject to change without
notice. They are only standard if the language defines them as such.
The hypothetical situation given is:
* A client is to be written by a third party in a language of their choice
* The client must be able to generate the same random events
This situation seems to be better satisfied by defining the generator that a
client must implement using pseudocode and providing an example output given a
chosen seed. The producer of the client is responsible for writing the
generator. The writing of a generator is a small piece of the total code to
create a client.
It seems to be out of scope for Commons RNG to implement legacy generators from
multiple platforms given their failings under modern standards for randomness
([Dieharder|https://webhome.phy.duke.edu/~rgb/General/dieharder.php] and
[BigCrush|http://simul.iro.umontreal.ca/testu01/tu01.html]).
Of the reference LCGs listed some use long arithmetic and output 32-bits of the
state per cycle. These generators are candidates for addition to the library as
they may produce acceptable random output. Implementations are being developed
and tested using Dieharder and BigCrush to determine if the performance is
comparable to the LCG implemented in Java's own java.util.Random.
Results of quality (randomness) and performance (speed) tests will be posted
here to determine if these generators have merit.
> Linear congruential generators
> ------------------------------
>
> Key: RNG-16
> URL: https://issues.apache.org/jira/browse/RNG-16
> Project: Commons RNG
> Issue Type: Sub-task
> Reporter: Emmanuel Bourg
> Priority: Minor
> Labels: gsoc2019
>
> This is a RFE for implementing linear congruential generators:
> https://en.wikipedia.org/wiki/Linear_congruential_generator
> This type of random generator is often used in language runtimes (Borland C,
> GCC, Delphi, VB and even Java). Preconfigured generators using the same
> parameters as these languages would be convenient for reproducing the same
> number sequences in Java.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
