commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] new pseudo random number generators
Date Tue, 21 Sep 2010 07:22:38 GMT
Le 20/09/2010 14:40, Phil Steitz a écrit :
> On 9/20/10 6:30 AM, wrote:

>> The paper does not put any restriction on the algorithm. The
>> reference implementation in C on the other hand is limited to
>> non-commercial use only. In my implementation, I did not refer to
>> this C implementation at all. I only compiled it on my personal
>> computer to generate reference values and copied the values in
>> the test cases. So this implementation is completely independent
>> (and in fact the code is rather different since I used an
>> abstract class for the global algorithm and one derived class for
>> each specific generator. I rely on the JVM optimizer to do all
>> the inlining and constants simplification that they did manually
>> in the reference implementation.
> Sounds OK, but we should verify somehow that the algorithm itself is not
> patented.  Does the C source say anything about that?  Might be good to
> ask about this on legal-discuss or ask one of the authors. I know this
> could apply to any of the algorithms we implement, but the ones that are
>>100 yrs old are a little safer ;)

Here is an extract from the answer from Pierre L'Ecuyer:

  Our code can be released under either a GPL or a commercial license.
  There is also a Java implementation with multiple streams and
  substreams in SSJ: see the package rng:
  If you reimplement the code, this is a gray zone, but we do not have
  a patent on the algorithm.

So as I reimplemented from the paper itself (taking the erratas in <>
into account) and use different optimization techniques (precomputed
indices tables), I would consider it is safe to publish this home-grown

>> Another difference with the reference implementation is that our
>> BitStreamGenerator abstract class requires the generator to
>> provide only bits blocks and not double, and it computes the
>> double by itself. This computation uses the full IEEE754 width
>> for the doubles, i.e. it uses 53 bits. The generators are
>> guaranteed to be equidistributed on large vectors of 32 bits (up
>> to dimension 1390 for the 44497 version, since 1390 * 32<
>> 44497). I guess this should work well also using chunks of 53
>> bits (but of course with smaller dimensions), but it is not
>> mathematically proven.

Pierre L'Ecuyer confirmed me we could do that despite equidistribution
is not mathematically proven in this case. In fact, he wrote me they do
the same ...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message