commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
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, luc.maisonobe@free.fr 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:
  http://www.iro.umontreal.ca/~simardr/ssj/indexe.html
  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 <
http://www.iro.umontreal.ca/~lecuyer/myftp/papers/wellrng-errata.txt>
into account) and use different optimization techniques (precomputed
indices tables), I would consider it is safe to publish this home-grown
code.

> 
>>
>> 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 ...

Luc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message