Bug#537952: Use more random random seed than localtime

[Jonathan Yu]

Hi Don:

On Tue, Jul 28, 2009 at 12:26 PM, Don Armstrong<don at donarmstrong.com> wrote:
> On Tue, 28 Jul 2009, gregor herrmann wrote:
>> On Tue, 21 Jul 2009 16:03:48 -0700, Don Armstrong wrote:
>> > Math::Random has its random number only based on localtime:
>>
>> I'm a bit confused about the state of this bug/package; Don has
>> provided a patch, Jonathan has committed it with, there was a
>> discussion about some aspects of the patch between Don, Jonathan, and
>> Damyan -- is there any consensus on how to proceed?
>
> From where I sit, the prefered method to proceed is to:
>
> 1) Fix the test failures from the patch that I provided originally. [I
> ran the tests, and it doesn't fail for me on amd64, ppc, or i386 so
> I've no idea what failed.]

I figured as much. Really, I don't know what failed either. You can
check out the first attempt at patching, it's revision 40493. I
decided to have another crack at it and figure out exactly what the
errors were:

svn export -r 40493 svn://svn.debian.org/pkg-perl/trunk/libmath-random-perl

I end up getting this:
1..16
 a, m, s out of order in mltmod - ABORT!
 a =   2082007225 s =            0 m =   2147483563
 mltmod requires: 0 < a < m; 0 < s < m
>
> 2) Require 5.8.1
>
> alternatively, instead of #2, provide a fallback method to less-random
> data in cases where Perl_seed isn't implemented as detailed in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537952#60 point #3
> along with a warning (or use the implementation in
> List::Util::shuffle()).
>
> The current use of salph is suboptimal because it wastes entropy (and
> does non-obvious things to the input data, which in the case of data
> which is known to be uniform can be shoved directly into the two seeds
> of rand.c.)
Hm. I really don't know how the internals are done, all I know is that
the Perl module by default uses salph, so I figured replicating that
but with a better seed than localtime ought to be Good Enough (tm).
>
> That said, I'm personally not too concerned if a different method is
> chosen, as after examining the underlying code quality I plan on
> migrating my code to GSL instead.
That sounds like a good plan, given that upstream doesn't seem very
responsive. There's lots of better algorithms (in particular the
Mersenne Twister is pretty fast) that provide stronger (cryptographic)
random number generation.

For reference, here's some tests I did on a few modules.. Note they
are very basic, but anyway, shows things like uniformity of the data
produced, and their relative benchmarked speeds:
http://jawnsy.wordpress.com/2009/06/04/performance-of-mathrandomisaac/
>
>
> Don Armstrong
>
> --
> S: Make me a sandwich
> B: What? Make it yourself.
> S: sudo make me a sandwich
> B: Okay.
>  -- xkcd http://xkcd.com/c149.html
>
> http://www.donarmstrong.com              http://rzlab.ucr.edu
>
>
>
> _______________________________________________
> pkg-perl-maintainers mailing list
> pkg-perl-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers
>