[m-rev.] time additions (was Re: for review: Add random.init/3)

[Mark Brown]

Hi Julien,

On Sun, May 29, 2016 at 7:55 PM, Julien Fischer <jfischer at opturion.com> wrote:
> On Sun, 29 May 2016, Mark Brown wrote:
>> On Sat, May 28, 2016 at 12:50 PM, Julien Fischer <jfischer at opturion.com>
>> wrote:
>>> My current thinking on this is that all random number generators should
>>> be required to have a unique state value threaded through their
>>> operations.
>>
>>
>> Agreed. Even when generators don't actually need the uniqueness, it's
>> good to stop users accidentally copying a generator when they don't
>> mean to. Making it unique will force them to explicitly duplicate a
>> generator if that's what they want to do.
>>
>>> That value would be required to be an instance of the
>>> standard library's store/1 type class
>>
>>
>> It would certainly be very nice to do this. But here's what happens when I
>> try:
>>
>>    % Random number generator G with store S
>> :- typeclass random(G, S) where [
>>    pred random(G::in, int::out, S::di, S::uo) is det
>> ].
>
>
> What I meant was that store should be a superclass of random:
>
>     :- typeclass random(G, S) <= store(S) where ...

I think that's really up to the person implementing the generator. For
a lot of implementations, a practical type to use for the state would
be an array or bitmap, or even just an integer. Somebody else can
write an adaptor instance that gives a store-like view on such
implementations (see attached).

>
>>    % This is the instance I want to write.
>> :- instance random(generic_mutvar(T, S), S) <= store(S).
>>
>> But it's not accepted because the second argument is a variable.
>
>
> And here we start crashing into problems ... :-(
>
>> I could instead try something like:
>>
>> :- instance random(io_mutvar(T), io) where ...
>> :- instance random(store_mutvar(T, S), store(S)) where ...
>>
>> But these can't be used in code which is already generic in the store
>> that is being threaded through. You need to write the same code out
>> twice, too.

In fact, if there is such an adaptor as the one I'm thinking of, only
the adaptor needs to be written out twice (again, see attached).

>
>
> Neither of those should work according to our current rules for instance
> heads.
> After you expand all the equivalence types, you would have:
>
>     :- instance random(generic_mutvar(T, io), io) where ...
>     :- instance random(generic_mutvar(T, store(S)), store(S)) where ...
>
> and both of those do not meet the requirement that each argument "must be
> either a type with no arguments, or a polymorphic type whose arguments are
> all
> type variables".
>
>> Anyone have any ideas?
>
>
> I don't think the above is a showstopper, for one thing the RNG "handle" type
> is unlikely to actually *be* a mutvar, although it may contain them.  This is
> actually fairly similar to instance of the stream type classes and we manage to
> (mostly) muddle through with them alright.

Yes, I cut some corners with the exposition: the "handle" are actually
no-tag types. I ought to have realised you would notice :)

>
>>> (i.e. the current RNG interface,
>>> such as it is, would be pretty much entirely thrown away).
>>
>>
>> No objections from me.
>>
>> Does your earlier removal of some of the restrictions help with any of
>> the above?
>
>
> Not enough, unfortunately.

See attached files for my attempt. It has two levels of interface, a
store-like one and an array/bitmap-like one, and I've also divided
each level into several typeclasses, so that generators only provide
the instances that make sense, and callers only have the constraints
they need. There's a few generator implementations, including a
version of tausworthe3 that's fixed for 64-bit. The random_binary
module is a program that outputs random binary data which can be used
with dieharder, for example.

Does this look suitable for the standard library? If so, should I
rename it random.m and include, but deprecate, the existing interface?

Any other comments?

Cheers,
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.m
Type: text/x-objcsrc
Size: 11384 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.binfile.m
Type: text/x-objcsrc
Size: 2636 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.state.m
Type: text/x-objcsrc
Size: 2505 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.tausworthe.m
Type: text/x-objcsrc
Size: 4564 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0009.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rng.xorshift.m
Type: text/x-objcsrc
Size: 6317 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: random_binary.m
Type: text/x-objcsrc
Size: 2681 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20160529/1ecc84e9/attachment-0011.bin>