[Haskell-cafe] Re[2]: Why Haskell?

[SevenThunders]

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 at 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.