0MB).
Interestingly, on GHCi, the program shows the elements which are constructed
from the first row of the matrix, "rests awhile" and then stack
overflows (n >= 600) or continues fine (n <= 500).
With the improved definition of rmat I wrote in my last mail (Subject: listAr
> GHCi didn't have any problem even with the original code.
mine didn't either, until I increased the "200" to around "1500"...it's
probably OS/memory specific.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haske
I did some experiments and now suspect that the culprit is the infinite list.
When I replace rmat with
> rmat n = listArray ((1,1),(n,n)) [1..] -- no longer random
,
> print (m ! (300, 300)) where m = rmat 800
fails again.
However, if I use a finite list as the second argument of listArray:
> rm
It seems the problem is indeed in rmat:
> rmat n =listArray ((1,1),(n,n)) $ map ct (randoms (mkStdGen 1) ::[Bool])
> where ct True = Unknown
> ct False = Dead
To be more precise, the problem is in randoms. If you replace rmat
with the following
rmat n =
e III | [EMAIL PROTECTED]
"Arrest this man, he talks in maths." | www.isi.edu/~hdaume
> -Original Message-
> From: Koji Nakahara [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 7:41 PM
> To: Hal Daume; [EMAIL PROTECTED]
> Subject: Re:
On Wed, 18 Jun 2003 17:36:28 -0700
"Hal Daume" <[EMAIL PROTECTED]> wrote:
> Note that there is essentially no difference between f1 and f2. When
> you $! in f2, all it does is ensure that the argument isn't undefined.
> It doesn't evaluate any of the list. Try $!! from the DeepSeq module or
> wr
Note that there is essentially no difference between f1 and f2. When
you $! in f2, all it does is ensure that the argument isn't undefined.
It doesn't evaluate any of the list. Try $!! from the DeepSeq module or
write your own list-forcing function.
For me, the following works:
f1 0 l = l
f1 n
