Sebastian Sylvan-2 wrote:
Well, why would you want a huge array of random numbers? In Haskell there are two big ways to gain efficiency, strictness and laziness. In this case I think laziness is a big candidate (the "huge array" part gives it away). Also there is no reason generating random numbers should be in the IO monad - in fact the built-ins for random numbers are mainly regular pure functions. You only need IO in the very beginning to get a seed.
So basically, try to use the extra modularity options that Haskell gives you to separate things that *need* to be IO and things that can just be regular lazy structures (like an infinite list of random numbers occupying memory the size of a pointer). In your case you'd use newStdGen in the IO monad to get a generator, and then produce a "huge" (e.g. infinite) list of random numbers using that (in a pure non-side-effect way), where only the numbers actually needed will ever be computed.
If however you do need to do actual IO actions and you find it takes too much space, you can add some extra laziness using unsafeIntereaveIO. It basically just postpones an action until its result is needed. This is what readFile uses, btw, to get lazy IO. I think that's the way to go (rather than unsafePerformIO) because it's still IO so you don't end up in the situation where you have a pure function returning different results everytime you call it, and you still get laziness. Be careful, though, that your particular IO action won't behave strangely if it gets called at some random time or not at all.
/S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
This kind of sidesteps my question concerning the efficiency of sequence (which it seems could be improved.) You are however correct about how I generate my random numbers. I could have used randomR and stayed out of the IO monad altogether. Also you do bring up an interesting point with regards to whether laziness buys you something with regards to the use of random numbers in a simulation such as mine. The answer is rather complicated. What is going on is that physical processes are being modeled as random processes, which requires the generation of a noise field, which is usually added to the real data of interest. This sort of thing happens all the time in physics and engineering and even numerical computations (e.g. Monte Carlo integration or Markov Chain Monte Carlo evaluation of Bayesian posteriors.). In my case, I have matrix statistics that will be computed after averaging over large amounts of data. Those computations will have to be performed; lazy evaluation won't make them go away. Moreover, to gain efficiency it is usually better to exercise the numerical libraries, such as BLAS over large matrices. Hence I believe it is more efficient to generate all my statistics in advance if possible. In some cases it is possible to reason about the process analytically and thereby mitigate the need to actually generate the random numbers, or to at least generate the final answer as a 'compressed' result, with smaller amounts of data being generated. However in most cases this is intractable and so the brute force approach is the only practical alternative. -- View this message in context: http://www.nabble.com/Why-Haskell--tf1986013.html#a5527728 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.