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

[Isaac Dupree]

Bryan, you could very well be right, I'm just asking to see if you have 
more evidence at your fingertips that I can look at:

On 09/15/10 01:39, Bryan O'Sullivan wrote:
> Actually, it's worse than that: there's no statistical basis for believing
> that the split operation is sound. It is sure to introduce correlations
> between the forked generators,  [...]

Citation/argument for "It is sure to introduce correlations between the 
forked generators"?  Did someone prove that for all possible PRNGs?  Or 
are you just claiming a lack of anyone having proved it to be sound?

> While I understand the appeal of split, it is completely unsafe to use as it
> stands. [...]

Split on StdGen worked fine for me displaying random smoke.  The only 
effect of the random numbers here is how it looks.  And it looked fine. 
  Actually I re-implemented that with a linear congruential generator in 
C for speed.  Just saying, *some* uses of random numbers don't need them 
to have very good properties.

> [...] where the Integer term returned is an approximation to the period of the
> newly split PRNGs. At that point, you at least get some sort of caveat
> emptor that you're rapidly running out of entropy when you perform repeated
> splits,  [...]

Are you saying that 'split' on a PRNG, such as StdGen, causes the two 
"splitted" result StdGens to each have a shorter period than the 
original StdGen?  I've looked at the implementation of StdGen and its 
split, and although I'm not an advanced mathematician, it doesn't seem 
to me that "split" reduces the period in any predictable way.  (Perhaps 
it reduces the entropy?--that's a concept I'm fuzzier about its 
definition--but it doesn't seem to me that it would reduce the period.) 
  Elaborate if you please :-)

-Isaac