System.Random StdGen read fails on some strings?
According to the documentation for System.Random (see <http:// haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html>):
In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties:
* It guarantees to succeed on any string. * ...
On the other hand, I get the following on the (admittedly stupid, spur-of-the-moment) String argument "whateva":
Hugs> :l System.Random System.Random> read "whateva" :: StdGen
Program error: Prelude.read: no parse
System.Random> map read $ words "this is a test of the System dot Random StdGen read, which seems to fail only on ... whateva" :: [StdGen] [4580 1,440 1,101 1,4584 1,445 1,1485 1,35261 1,1377 1,32825 1,34047 1,13422 1,14037 1,13637 1,469 1,4132 1,4514 1,453 1,626 1, Program error: Prelude.read: no parse
Am I missing something here? Or am I just being punished for the stupidity of my particular choice of String? :) -- Fritz PS: this happens with both Hugs Version: September 2006 and GHC Interactive, version 6.6, running on Mac/Tiger, for what that's worth.
On Tue, 13 Mar 2007 00:37:46 -0700, Fritz Ruehr <fruehr@willamette.edu> wrote:
According to the documentation for System.Random (see <http:// haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html>):
In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties:
* It guarantees to succeed on any string. * ...
On the other hand, I get the following on the (admittedly stupid, spur-of-the-moment) String argument "whateva":
Hugs> :l System.Random System.Random> read "whateva" :: StdGen
Program error: Prelude.read: no parse
System.Random> map read $ words "this is a test of the System dot Random StdGen read, which seems to fail only on ... whateva" :: [StdGen] [4580 1,440 1,101 1,4584 1,445 1,1485 1,35261 1,1377 1,32825 1,34047 1,13422 1,14037 1,13637 1,469 1,4132 1,4514 1,453 1,626 1, Program error: Prelude.read: no parse
Am I missing something here? Or am I just being punished for the stupidity of my particular choice of String? :)
-- Fritz
PS: this happens with both Hugs Version: September 2006 and GHC Interactive, version 6.6, running on Mac/Tiger, for what that's worth.
There seems to be a limit on 6 characters. Any string under 6 characters works nice, any over that limit will fail. test program: \begin{code} module Test where import Random rd :: String -> StdGen rd = read testit :: String -> [Int] testit [] = [] testit xt@(_:xs) = (testit xs) ++ [fst (randomR (1::Int,50) (rd xt))] \end{code} testit "thing" wotks nice, testit "morethanthing" stops after the sixth number in the list. Both in HUGS and GHC, last versions Best regards, Zara
On Tue, 13 Mar 2007 14:44:46 +0100, Zara <me_zara@dea.spamcon.org> wrote:
On Tue, 13 Mar 2007 00:37:46 -0700, Fritz Ruehr <fruehr@willamette.edu> wrote:
According to the documentation for System.Random (see <http:// haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html>):
In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties:
* It guarantees to succeed on any string. * ...
On the other hand, I get the following on the (admittedly stupid, spur-of-the-moment) String argument "whateva":
Hugs> :l System.Random System.Random> read "whateva" :: StdGen
Program error: Prelude.read: no parse <..>
There seems to be a limit on 6 characters. Any string under 6 characters works nice, any over that limit will fail.
test program:
\begin{code} module Test where
import Random
rd :: String -> StdGen rd = read
testit :: String -> [Int] testit [] = [] testit xt@(_:xs) = (testit xs) ++ [fst (randomR (1::Int,50) (rd xt))]
\end{code}
testit "thing" wotks nice,
testit "morethanthing" stops after the sixth number in the list.
Both in HUGS and GHC, last versions
The problem seems to lie in base/System/Random.hs: \begin{code} {- If we cannot unravel the StdGen from a string, create one based on the string given. -} stdFromString :: String -> (StdGen, String) stdFromString s = (mkStdGen num, rest) where (cs, rest) = splitAt 6 s num = foldl (\a x -> x + 3 * a) 1 (map ord cs) \end{code} If we change the number on splitAt, the string limit to give an error changes. I think that when we feed an arbitrary string to readsPrec of Random.StdGen, we should return nothing, that is, we should consume the whole string. So, I propose th change that function to be: \begin{code} {- If we cannot unravel the StdGen from a string, create one based on the string given. We consume it all. -} stdFromString :: String -> (StdGen, String) stdFromString s = (mkStdGenBis num, "") where num = foldl (\a x -> x + 3 * a) 1 (map ord s) \end{code} This solution solves *our* problem, but I would like to receive comments to it. Where may I find someone responsible for this library, to see if the change is adequate, or why not? Best regards, Zara
Zara Good point. It's a bit stupid that 'read' fails utterly on strings shorter than 6. I don't thin StdRandom has an "owner" at the moment. There's a process for proposing library changes, described under "guidelines for developers" here http://haskell.org/haskellwiki/Libraries_and_tools That's the way to get your change adopted. However, in this case the bug is in your code. The function 'read' (which you use) fails unless it consumes its entire input. That is not what you want here. The right thing to do is to use 'reads' instead. The wrong thing to do is to make reading a StdGen read the entire input string! Simon
On 3/19/07, Simon Peyton-Jones <simonpj@microsoft.com> wrote:
Zara
Good point. It's a bit stupid that 'read' fails utterly on strings shorter than 6.
I don't thin StdRandom has an "owner" at the moment. There's a process for proposing library changes, described under "guidelines for developers" here
http://haskell.org/haskellwiki/Libraries_and_tools
That's the way to get your change adopted.
There's already a thread about this on the libraries list: http://www.haskell.org/pipermail/libraries/2007-March/007052.html Ian commented with a proposal for fixing it, and no one has followed up yet. That would probably be a good place to direct any more discussion. Cheers, Kirsten
participants (4)
-
Fritz Ruehr -
Kirsten Chevalier -
Simon Peyton-Jones -
Zara