Le 20/09/2010 14:40, Phil Steitz a écrit : > On 9/20/10 6:30 AM, luc.maison...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
