Proposal: Move 'split' into a separate class in System.Random

Jan-Willem Maessen jmaessen at alum.mit.edu
Thu Oct 7 09:22:31 EDT 2010


> The "Clean Break" would involve removing "split" from the RandomGen
> class and making a new class "SplittableGen" for this operation.  The
> thought here is that not all generators can have a "split".  Users of
> "split" would have to be explicit of their need for a Splittable
> generator.
>
> The backward compatible change would keep "split" as a member of class
> "RandomGen" for which all instances would be constrained to also be
> instances of the "BasicRandomGen" class.  BasicRandomGen would contain
> the traditional routines (next, genRange).

Removing the Read and Show constraints for splittable generators would
be a Really Good Thing.  It turns out implementing splittable
generators efficiently (eg using Lennart's notion of splittable
supplies) doesn't work in the presence of these constraints ---- or
rather, one is faced with the choice of Read/Show yielding
irreproducible results, or using an inefficient implementation of
splittable supplies.

-Jan-Willem Maessen


More information about the Libraries mailing list