Hi,
2010/9/20 <luc.maison...@free.fr>:
>
> ----- "Mikkel Meyer Andersen" <m...@mikl.dk> a écrit :
>
>> Hi,
>>
>> I think it sounds interesting.
>>
>> A few comments:
>> 1) Does it support paralleled generation?
>
> No, it updates its bits pool using an iterative formula.
No worries - I was just curious. But maybe we should keep in mind that
if we see a PRNG working in parallel it might be an interesting
addition to the library.
>
>> 2) In regards to the user, which should be the default for e.g.
>> sampling from probability distributions?
>
> For simple sampling, I guess WELL1024a could be sufficient. For Monte-Carlo
> simulations with more than 32 independent variables (i.e. dimensions), it
> would probably be insufficient so WELL19937c or WELL44497b would be better.
> See also answer to the following point.
I reckon this should be documented so the user is aware of the
different PRNG and their pros and cons. In addition, reasonable
defaults are necessary. Would it be a good idea to keep the current
PRNG as default for now, but include your new ones for the user to use
if she wants to. Just until we get some more experience with the new
PRNGs?
>
>> 3) How is the performance compared to the existing algorithms in
>> Commons Math?
>
> I did not check yet, but the paper shows benchmark with performances of the
> same order of magnitude as the MersenneTwister. All these are really fast
> generators (between 30 and 40 seconds to generate one billion numbers on a
> 2006 computer). These benchmark also show all generators ("short" periods
> like 2^1024-1 and long periods like 2^44497-1) have similar performances in
> term of generation rate. There is a difference in memory consumption, but
> this size is not a real concern unless you use hundreds of thousands of
> generators at the same time. The pool size of WELL44497b is 44497 bits stored
> in a 1391 elements integer array, so less than 6 kilobytes ...
I would like to see/try a comparison between the default and new PRNG
under different conditions. Just to get an idea of how they perform.
>
> Beware my implementation is really different and relies a lot on JVM
> optimizations (mainly inlining since there is a two-levels indirection for
> each of the 7 basic transforms t0 to t6). We may have a huge performance drop
> compared to the reference implementation if I did something wrong!
>
> Although I forgot to point one important thing: these generators, just like
> our existing MersenneTwister are NOT suitable for cryptography. They are
> devoted to simulation, and to generate very long series with strong
> properties on the series as a whole (equidistribution, no correlation ...).
> They do not attempt to create small series but with very strong properties of
> unpredictability (does this word exist ?). So by adding these generators to
> our library we do not change its status with respect to exportation laws that
> apply in the US (well, and I developed them in France too).
>
> Luc
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
