Bug #121093 for Math-Random-MTwist: bad XS argument for 32-bit

Wed Apr 12 18:10:19 2017 DANAJ [...] cpan.org - Ticket created

Subject:

bad XS argument for 32-bit

Line 422 of MTwist.xs calls mt_lrand() with a state argument. The function does not take an argument. Originally this was going to be a bug report/fix around the behavior of irand on 32-bit Perls: perl -E 'say ~0; use Math::Random::MTwist qw/srand irand rand/; srand(42); say irand()' 4294967295 6.90904563742895e+18 where I would have expected: # Changed MTwist.xs:382 to #if defined(UINT64_MAX) && IVSIZE >= 8 perl -Iblib/lib -Iblib/arch -E 'say ~0; use Math::Random::MTwist qw/srand irand rand/; srand(42); say irand()' 4294967295 1608637542 but I see the documentation points out that irand is aliased to irand64 and it coerces the result to a double on 32-bit Perl. I find this behavior completely bizarre, but it's documented that way. Unfortunately every rand-type module has implemented these functions differently. However the MTwist module is very well written and blazingly fast (which has a lot to do with the module construction and not just the MTwist code).

Thu Apr 13 14:43:15 2017 CGPAN [...] cpan.org - Correspondence added

You're right, mt_lrand(state) is wrong. I'll see when I can get around to fixing it. Yes, irand() returning an NV despite its name might look bizarre but no more bizarre than Perl's int() returning an NV when called with an NV (this, too, is a documentation detail). So it's not actually wrong to call it an "integer" in the latter sense. It was a compromise to provide the full 64-bit range with a slightly reduced resolution (still better than 32-bit). Unfortunately, Perl does not have long integers like Python.

Thu Apr 13 14:43:15 2017 The RT System itself - Status changed from 'new' to 'open'

Thu Apr 13 17:02:16 2017 DANAJ [...] cpan.org - Correspondence added

On Thu Apr 13 14:43:15 2017, CGPAN wrote: Show quoted text

> > You're right, mt_lrand(state) is wrong. I'll see when I can get around > to fixing it.

It doesn't seem too critical given the time it's been out there, and I just found it in testing, so I'm in no hurry. Show quoted text

> Yes, irand() returning an NV despite its name might look bizarre but > no more bizarre than Perl's int() returning an NV when called with an > NV (this, too, is a documentation detail). So it's not actually wrong > to call it an "integer" in the latter sense. It was a compromise to > provide the full 64-bit range with a slightly reduced resolution > (still better than 32-bit). Unfortunately, Perl does not have long > integers like Python.

I agree that it's all making the best of a lousy situation. To me irand means 'integer', as I already have rand to get doubles. But I could always use irand32 / irand64 to get something more consistent. The semantics of irand / irand32 / irand64 varies a lot between modules. The way rand behaves also is surprisingly non-uniform (32-bit, 52-bit, 53-bit, all-NV-bit; closed vs. half-open interval -- at least two modules I see will return 1.0 from their rand()).

Thu Apr 20 02:57:59 2017 CGPAN [...] cpan.org - Correspondence added

I'm wondering if it would be a good idea to return a string instead of a double. What do you think?

Thu Apr 20 02:58:00 2017 CGPAN [...] cpan.org - Taken

Sat Jul 15 11:22:06 2017 CGPAN [...] cpan.org - Correspondence added

Fixed in 0.18.

Sat Jul 15 11:22:07 2017 CGPAN [...] cpan.org - Status changed from 'open' to 'resolved'