Random numbers

[Richard Lobb]

At 3:05 PM 12/13/95, Ron Wichers Schreur wrote:
>Torsten Will <itwill@TechFak.Uni-Bielefeld.DE> wrote:
>[..]
>> The problem is here, where to get the initial state ?
>> I'd need a little help from Clean.
>
>> // Something like
>> getIniState::*WORLD -> (Int,*WORLD)
>> // would be sufficient.
>
>This would indeed be an useful function. We may consider adding
>it to a future release, perhaps together with a predefined
>pseudo random generator.
>> The best for applications I don't need the 'pseudo-random'
>> features would be something like a standard function (variable).
>> [...]
>> where the rand would be weird in that, that it would be evaluated
>> to different real/int/... numbers.
>
>Such a function did exist in earlier versions of Clean. We decided
>to drop it, because we want to maintain referential transparency.

I am not a functional languague theorist -- I use Clean for practical
graphics programming work, and have been very impressed by it. However, I
was mildy peeved when the Random function vanished in the transition from
version 0.8 to 1.0. In several places I had used Monte Carlo methods deep
down in low level code, e.g. for integration. The idea of getting random
numbers via the program state in order to maintain referential transparency
doesn't really solve my problems. I would have to pass a seed value from
the i/o level functions down through routines that really shouldn't need to
know about detail like integration methods to be used at low levels.

Similar problems occur when debugging or when tuning . For example, if I
try to add a statistics-gathering facility to record in a file every time a
shadow testing ray encounters some particular object, I am faced with
passing additional i/o parameters down through intermediate routines that
shouldn't need to be modified. Of course I realise that the purist would
argue that by altering the specs to include statistics gathering I have
forced a new requirement on the high level routines that should be
reflected in their parameter lists. This is fine in theory, but the
practical truth is that it's a massive hassle, and enough to turn many of
my students off functional programming.

I don't claim to have an answer to this -- I realise how much debate there
has been on the topic. But I'd just like to remind purists that the notion
of referential transparency does have major shortcomings in practical
program development.

But, hey, keep up the good work guys. Clean is a most impressive product.
Many thanks for making it available.


-- Richard
----------------------------------------------------------
Richard Lobb
Senior Lecturer, Department of Computer Science
University of Auckland
e:mail: richard@cs.auckland.ac.nz  or r.lobb@cs.auckland.ac.nz
www: http://www.cs.auckland.ac.nz/~richard
----------------------------------------------------------