Re: randfunc in Config

[BrowserUk]

Is there some other method besides using %Config to check that Perl uses its own drand48 function?

I would have thought the simplest test would be to seed (srand) with a known value (say 1) and test the first value that rand() returns. If it is the same PRNG you are expecting, then it will produce the same first (and sequence) of values.

That said, it does kind of lead to the question: what is it that you are testing that requires a specific PRNG in the first place?

It sounds like -- and given it is you, I'll not say it any more strongly than that -- you are testing the wrong thing. Ie. You appear to be testing for a specific implementation of a PRNG; rather than for the successful product of whatever your module that uses the PRNG is meant to produce.

What I'm getting at is: is it necessary to limit the use of your module to implementations that have one specific PRNG available?

[Corion]

Having a unified (drand48) rand() implementation is one of the features that came in with Perl 5.20.0, so testing in a sensible way for availability of drand48 (instead of testing for 5.20.0+) is the main goal for choroba I think.

[BrowserUk]

Having a unified (drand48) rand() implementation is one of the features that came in with Perl 5.20.0, so testing in a sensible way for availability of drand48 (instead of testing for 5.20.0+)

Besides that 5.20+ seems like a far simpler criteria to test for; even if the goal is "any perl with drand48 even if that's a linux build before 5.20"; that still suggests that he is insisting on a 48-bit PRNG, which without knowing what the module is doing, seems short-sighted.

Ie. Why does it need to be 48-bit? How would the modules functionality be affected if I wanted to use the 32-bit MT? Or the 64-bit MT? Or even the very fast simd implementation of the 64-bit MT? What if I chose to provide a 48-bit PRNG that isn't the drand48 implementation?

If he needs that particular implementation, then seeding to a known seed and testing the first return value will detect it, both if it is under a different name; and perhaps more importantly, fail if it has the right name but the implementation has been screwed up.

But still the nagging in the back my head says that any algorithm that uses random numbers but needs one very specific PRNG to operate, is badly designed.

I can see that TDD proponents would like to be able to specify they PRNG because then all their little OK/NOK tests can compare against known pre-calculated outputs; but if that is the purpose; as soon as you've detected that you have the right PRNG, all those comparisons against pre-calculated outputs become redundant.