Bug#537952: Use more random random seed than localtime

[Jonathan Yu]

On Thu, Jul 30, 2009 at 6:18 PM, Jonathan Yu<jonathan.i.yu at gmail.com> wrote:
> 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

I should also note that changing the patch to this:
+void
+set_default_seed(long time)
+       PREINIT:
+       long seed;
+       CODE:
+       seed = Perl_get_seed;
+       setall(seed, seed);

Yielded the same error. Am I missing something about how to use setall()?
>>
>> 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
>>
>