What I mean about that is that in nearly every tutorial I've read about functional languages, is that one of the great things about functions, is that if you call a function with the same parameters twice, you'll always end up with the same result.
How on earth do you then make a function that takes a seed as a parameter, and then returns a random number based on that seed?
I mean this would seem to go against one of the things that are so good about functions, right? Or am I completely missing something here?
Best Answer
You can't create a pure function called
random
that will give a different result every time it is called. In fact, you can't even "call" pure functions. You apply them. So you aren't missing anything, but this doesn't mean that random numbers are off-limits in functional programming. Allow me to demonstrate, I'll use Haskell syntax throughout.Coming from an imperative background, you may initially expect random to have a type like this:
But this has already been ruled out because random cannot be a pure function.
Consider the idea of a value. A value is an immutable thing. It never changes and every observation that you can make about it is consistent for all time.
Clearly, random can't produce a Integer value. Instead, it produces a Integer random variable. It's type might look like this:
Except that passing an argument is completely unnecessary, functions are pure, so one
random ()
is as good as anotherrandom ()
. I'll give random, from here on, this type:Which is all well and fine, but not very useful. You may expect to be able to write expressions like
random + 42
, but you can't, because it won't typecheck. You can't do anything with random variables, yet.This raises an interesting question. What functions should exist to manipulate random variables?
This function can't exist:
in any useful way, because then you could write:
Which introduces an inconsistency. badRandom is supposedly a value, but it is also a random number; a contradiction.
Maybe we should add this function:
But this just a special case of a more general pattern. You should be able to apply any function to random thing in order to get other random things like so:
Instead of writing
random + 42
, we can now writerandomMap (+42) random
.If all you had was randomMap, you wouldn't be able to combine random variables together. You couldn't write this function for instance:
You might try to write it like this:
But it has the wrong type. Instead of ending up with a
Random (a, b)
, we end up with aRandom (Random (a, b))
This can be fixed by adding another function:
But, for reasons that may eventually become clear, I'm not going to do that. Instead I'm going to add this:
It's not immediately obvious that this actually solves the problem, but it does:
In fact, it's possible to write randomBind in terms of randomJoin and randomMap. It's also possible to write randomJoin in terms of randomBind. But, I'll leave doing this as an exercise.
We could simplify this a little. Allow me to define this function:
randomUnit turns a value into a random variable. This means that we can have random variables that aren't actually random. This was always the case though; we could have done
randomMap (const 4) random
before. The reason defining randomUnit is a good idea is that now we can define randomMap in terms of randomUnit and randomBind:Ok, now we are getting somewhere. We have random variables that we can manipulate. However:
Implementation
I'll tackle pseudo random numbers. It is possible implement these functions for real random numbers, but this answer is already getting quite long.
Essentially, the way this is going to work is that we are going to pass a seed value around everywhere. Whenever we generate a new random value, we will produce a new seed. At the end, when we're done constructing a random variable, we will want to sample from it using this function:
I'm going to define the Random type like this:
Then, we just need to provide implementations of randomUnit, randomBind, runRandom and random which is quite straight-forward:
For random, I'm going to assume there's already a function of the type:
In which case random is just
Random psuedoRandom
.Making things less cumbersome
Haskell has syntactic sugar to make things like this nicer on the eyes. It's called do-notation and to use it all we have to do it create an instance of Monad for Random.
Done.
randomCombine
from before could now be written:If I was doing this for myself, I would even go one step further than this and create an instance of Applicative. (Don't worry if this makes no sense).
Then randomCombine could be written:
Now that we have these instances, we can use
>>=
instead of randomBind, join instead of randomJoin, fmap instead of randomMap, return instead of randomUnit. We also get a whole load of functions for free.Is it worth it? You could argue, that getting to this stage, where working with random numbers isn't completely horrendous was quite difficult and long-winded. What did we get in exchange for this effort?
The most immediate reward is that we can now see exactly which parts of our program are dependent on randomness and which parts are entirely deterministic. In my experience, forcing a strict separation like this simplifies things immensely.
We've assumed so far that we just want a single sample from each random variable that we generate, but if it turns out that in the future we'd actually like to see more of the distribution, this is trivial. You can just use runRandom lots of times on the same random variable with different seeds. This is, of course, possible in imperative languages, but in this case, we can be certain that we aren't going to perform unanticipated IO every time we sample a random variable and we don't have to be careful about initializing state.