System.Random - bugs? or am I just confused?

Hi all, I have been digging into the System.Random module lately. Initially, I was concerned about the split method, but trying to understand the code and algorithm, there are a couple of other issues that bother me. I hope this is the right forum to ask about them ... I think at least some of them are bugs, but then, there may be some deliberate design choices which I don't see. If there aren't, I guess I will propose a patch. Any opinions? 1. The range of the Standard Generator. stdRange gives a lower bound of 0. As far as I can see, 0 is an impossible value. Should the range not start at 1? 2. randomIvalInteger. One error has already been noted in the comment. Is it not trivial to calculate b based on genRange? Is there some drawback which has prevented such a change? 3. randomIvalInteger again. The drawing of n random numbers, multiplying the ith one by b^i, before summing them all, would make sense to me if the n random numbers had range 0..b-1, and we started the sum at acc=0. As far as I can see, the pseudo-random have range 1..b+1 (assuming the standard generator), and the acc parameter to f starts at 1. Is this a bug? Or what am I missing? 4. A possible error is also indicated by a comment in iLogBase, where iLogBase b b = 2. Should the if-condition i < b be changed to i <= b? Or is it more tricky? Thanks a lot in advance, :-- George

On 17 July 2013 19:00, Hans Georg Schaathun
Hi all,
I have been digging into the System.Random module lately. Initially, I was concerned about the split method, but trying to understand the code and algorithm, there are a couple of other issues that bother me. I hope this is the right forum to ask about them ...
Hi Hans, no comments on your issues yet. I just wanted to report an issue in random I discovered 3 months ago. This is the message I send to Ryan:
My colleague (Utkarsh Upadhyay) got a stack-overflow in a program he was working on. Thomas Schilling and me traced it down to randomRs being to lazy which causes the following to generate a stack-overflow exception:
g <- getStdGen randomRs (0,10::Int) g !! 1000000
The attached patch fixes the bug. I also included a patch to UNPACK the Int32 fields into the StdGen constructor.
I added the patches to the following gist: https://gist.github.com/basvandijk/6032630 Cheers, Bas

I definitely agree that the StdGen fields should be unpacked.
The slightly stricter evaluation of the randomRs generator seems like the
right solution as well.
-Edward
On Thu, Jul 18, 2013 at 4:16 PM, Bas van Dijk
On 17 July 2013 19:00, Hans Georg Schaathun
wrote: Hi all,
I have been digging into the System.Random module lately. Initially, I was concerned about the split method, but trying to understand the code and algorithm, there are a couple of other issues that bother me. I hope this is the right forum to ask about them ...
Hi Hans, no comments on your issues yet. I just wanted to report an issue in random I discovered 3 months ago. This is the message I send to Ryan:
My colleague (Utkarsh Upadhyay) got a stack-overflow in a program he was working on. Thomas Schilling and me traced it down to randomRs being to lazy which causes the following to generate a stack-overflow exception:
g <- getStdGen randomRs (0,10::Int) g !! 1000000
The attached patch fixes the bug. I also included a patch to UNPACK the Int32 fields into the StdGen constructor.
I added the patches to the following gist:
https://gist.github.com/basvandijk/6032630
Cheers,
Bas
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (3)
-
Bas van Dijk
-
Edward Kmett
-
Hans Georg Schaathun