in reply to Re^14: PDL and srand puzzle - PDL non-thread testing
in thread PDL and srand puzzle

This exposes a PDL bug. That is PDL::srand/srandom has no effect and must call CORE::srand(N) instead for predictable output.
Uh, no: 
$ perl -Mblib -MPDL -E 'say $PDL::VERSION'
2.089_01

$ perl -Mblib -MPDL -E 'CORE::srand(4); say PDL->random'
0.437817146098168
$ perl -Mblib -MPDL -E 'CORE::srand(4); say PDL->random'
0.0596849513730282
$ perl -Mblib -MPDL -E 'CORE::srand(4); say PDL->random'
0.876085322091164
$ perl -Mblib -MPDL -E 'CORE::srand(4); say PDL->random'
0.0193676520337621

$ perl -Mblib -MPDL -E 'srandom(4); say PDL->random'
0.923230081572141
$ perl -Mblib -MPDL -E 'srandom(4); say PDL->random'
0.923230081572141
$ perl -Mblib -MPDL -E 'srandom(4); say PDL->random'
0.923230081572141
$ perl -Mblib -MPDL -E 'srandom(4); say PDL->random'
0.923230081572141

[download]

Replies are listed 'Best First'.
Re^16: PDL and srand puzzle - PDL non-thread testing
by marioroy (Prior) on Jun 09, 2024 at 16:25 UTC
    Uh, no:

    I'm referring to the parallel non-thread demonstration. It does not produce predictable results unless calling CORE::rand.

    Edit 1: MCE checks for PDL::Primitive->can('srand'), but missed checking PDL::Primitive->can('srandom'). I will release MCE 1.894 and MCE::Shared 1.889.

    From here: Calling srand cannot be a workaround for this, because there is no interaction between Perl's RNG and PDL's. They are separate systems.

    I was hoping for PDL::srandom to work before spinning non-threads and output predictable results.

    Edit 2: MCE may not know or assume the srand or setter function used by the application. Therefore, I reverted back to CORE::random() for MCE's internal seed. Releasing MCE 1.895 and MCE::Shared 1.890. Update: The parallel demonstration processes a sequence of numbers, consuming lesser memory consumption. See also, Predictability Summary.

    From here: I have just realised that Perl's "threads" functionality might clash with this, if it uses POSIX threads: PDL's RNG has a global vector of n seeds, in a global C variable. PDL's code will, if it is being used in what it thinks is single-threaded mode, use the 0th offset in that. If multiple POSIX threads are accessing that single seed (which gets updated on each RNG generation), there will be a race condition, hence less uniqueness.

    Thank you for clarity with regards to spinning threads.

[reply]
[d/l]
[select]
      I'm referring to the parallel non-thread demonstration. It does not produce predictable results unless calling CORE::rand.
      So you described the situation wrong? You can have predictable results with PDL if you call random() to generate data before creating threads.
[reply]

In Section Seekers of Perl Wisdom