[m-rev.] RNGs

[Julien Fischer]

Hi Mark,

On Tue, 27 Aug 2019, Mark Brown wrote:

> For the generic predicates in the top module, I've gone for the following:
>
>    uniform_int_in_range
>    uniform_uint_in_range
>    uniform_float_in_range
>    uniform_float_around_mid
>    uniform_float_in_01
>    normal_floats
>
> I've left out the ones that generate full integer ranges because, on
> consideration, I'm not sure they would be generally useful enough.
> I've also only included uniform_*_in_range for the native integer
> sizes, not all integer sizes (in other modules, we don't usually have
> all of these variations when something returns an integer).

That's fine for now.

Aside: nearly all of the modules in the stdlib predate the addition of
non-int integer types.  Also, the implementation of other integer types
is still incomplete in some respects, so I haven't really pushed for
their adoption throughout the stdlib very strongly.

> On Mon, Aug 19, 2019 at 4:44 PM Julien Fischer <jfischer at opturion.com> wrote:
>> An alternative would be for each generator to export methods for
>> generating each fixed size unsigned integer types.  That is, add the
>> following to the type class(es):
>>
>>      next_uint8
>>      next_uint16
>>      next_uint32
>>      next_uint64
>>
>> That seems more flexible and uniform so far as callers are concerned, if
>> a little more work for implementors.
>
> Not too much, it turns out. If the generator natively produces, say,
> 32-bits, we implement the 8- and 16-bit methods by calling the
> generator once and throwing away unneeded bits, and the 64-bit method
> by calling the generator twice and pasting results together.

Exactly.

> This means calling the 8-bit method twice is not the same as calling
> the 16-bit method once. As such, I found the name "next" to be a bit
> misleading as it implied that the generator acts like a fixed stream
> of bytes.

So far as the user is concerned repeated to calls to next_uint8 *are*
a fixed stream of bytes!

>  Are the names "gen_uint8", etc, okay instead?

I would prefer "generate_uint8" etc to the abbrevated form.  Rationale:
we already have array.generate and I don't want to add to the situation
we already have in the stdlib with "rev" and "reverse".

Cheers,
Julien.