[Haskell] Re: About Random Integer without IO

[Jerzy Karczmarczuk]

This is my *last* word, promised...

Keean Schupke wrote:

> Hmm... It is impossible to write a purely functional program to 
> generate random numbers. Not only that it is impossible for a computer 
> to generate random numbers (except using hardware like a noise 
> generator). Pseudo random numbers require a seed. Functional programs 
> by definition only depend on their inputs - therefore the seed is 
> either fixed (same numbers each run) or one of the inputs (which means 
> it must be IO).

Will some of you, folks, finally *will to understand* what the issue is 
about?

First, we don't care about 'real random' numbers, actually there are 
problems even with their
definition. We need sequences which *behave* randomly, from the point of 
view of feasible
tests, spectral/statistical; correlational, etc.  RN generators work 
well, and that's it. Stop with
that slogans that computers don't do anything random. It reminds me some 
discussion on
other lists, where people for three months discuss whether the brain is 
a computer, or if
the Universe can be assimilated to a Turing machine. I wish them and you 
all the best...

Second, as the example of the ergodic function I told you about before 
demonstrates, there
exist plenty of functions which are pure, don't propagate any 'seed', 
and which behave
"wildly", which *can* be used as a pure "random function". I hate to do 
this, but you will find
such a definition and even the plot thereof  in my recent paper abount 
sound synthesis:
 http://users.info.unicaen.fr/~karczma/arpap/cleasyn.pdf
Clive Brettingham-Moore points out very correctly that a Chaos is not 
the same as the
Randomness. But, still, unstable dynamical systems, hardware and 
simulated, are used to
make noise,  "random" sequences with adequate properties. Continuous 
systems produce
quasi-regular functions: Lorenz equations, Chua circuit, etc., but if 
discretized, the results
of, say, Hénon system, etc. may be used as weakly correlated random 
generators.


Third, OK, let's assume we need a seed, and we use a standard RN gen. 
which propagates it.
Now, of course everybody knows that if you launch a functional program 
57686514 times, you
will get 57686514 identical results. My goodness, what a tragic 
perspective, what horror!!
Of course everybody launches the same program several times just in 
order to get different
results, no?
Seriously, if somebody has a computational problem which is <<par 
excellence>> stateful,
let him use Monads, or whatever. Haskell conceptors put a lot of effort 
into it. But,
conceptually, I thought that Haskell is mainly for people who elaborate 
functional programs
in functional style, using functional design patterns and thinking 
functionally.
And, personally I use random streams. Or, once constructed Perlin noise, 
and then used
in different program instances with different initializations. I provide 
these initializations
manually, outside any 'random' context, since I still think that Georg 
Martius is really wrong
writing

> I think automatic random initialisation is very important and handy in 
> programs that run non-deterministic simulations. 


This is perhaps my own idiosyncrasy, but I taught simulation for some 
years, I am not a
speculator. The first slogan I tried to convey to my students is:
 -- The FIRST thing you should learn is that a good simulation should 
share one common
    property with a good experiment: that you be able to REPRODUCE IT. --

People who do Monte-Carlo requiring many weeks of computing, and who 
break their
program in temporal slices: Two days now, let's see, then continue for a 
week more...
never, repeat *never* initialize their RNG automatically. The first run 
outputs the result
together with the current value of the seed, and this value is 
reinjected into the next
run,in order to prevent the improbable, but possible repetition of the 
sequence, which
would invalidate the soundness of the gathering of statistical data.

Thank you for your interest (if you got down to here...)

Jerzy Karczmarczuk