Am 19.01.21, 17:20 schrieb "Nikita Popov" <nikita....@gmail.com>:
* 64-bit: I looked over your implementation, and I think your approach to
handling 64-bits is correct. You only call next64() if the requested range
is larger than 32-bit, and that can only happen on 64-bit systems, thus
guaranteeing consistency of results (where they can be consistent at all).
What I'm unsure about is the way this gets exposed to userland via next()
and next64() methods. I think fetching of 64-bit values is mainly
interesting as an internal optimization, and not so much important to be
part of the RNGInterface API. The user is intended to get numbers via
rng_rand(), not by directly calling next(). A possibility here would be to
drop the RNG64Interface and next64() method, have next() always return
32-bit, but retain the internal next64 API. For this to make sense, we'd
need two subsequent internal next() calls to return the same data as a
single next64() call (i.e. store the result and first return one half then
the other). Would this make sense to you?
Wouldn't it make more sense to provide different classes for the algorithm
instead of two next/64 methods or limiting it?
Like:
* class MT19937 (system depending)
* class MT19937_32 (32bit version)
* class MT19937_64 (64bit version - not available on 32bit)
This way the user can take the algorithm that matches best his requirements.
Marc
Regards,
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
