[GRASS-dev] r.mapcalc addition

[Glynn Clements]

Hamish wrote:

> > > It'd be great if someone could commit the attached addition to
> > > r.mapcalc
> > > 
> > > It basically allows one to specify the seed for random number
> > > generation by adding a new function "erand(a,b,s)" which takes a and
> > > b as the lower and upper limit, and s is a seed that is used to
> > > initiate the pseudo random number generator.
> > > 
> > > This is useful in modelling and simulation so that particular
> > > replicates can be rerun exactly.
> > > 
> > > If it needs any extra work let me know and I'll make the changes.
> > 
> > I consider this to be the wrong approach. At a minimum, setting the
> > seed should be decoupled from the generation of random numbers;
> > there's no reason to have what is essentially another copy of
> > f_rand().
> > 
> > Also, it's debatable whether an r.mapcalc function is the correct
> > mechanism for setting an operating parameter. An environment variable
> > might be more suitable.
> > 
> > Finally, even if f_erand() was the correct interface, having it call
> > f_rand() once the seed has been set is preferable to including a clone
> > of f_rand() in the body of f_erand().
> 
> what if r.mapcalc's rand(a,b) fn had an optional third argument? ie the
> seed. rand(a,b) would work as it currently does, but rand(a,b,seed)
> would be available if you wanted it.

That could be problematic if you have more than one call to rand(). We
don't actually specify the evaluation order (GRASS functions don't
have side effects).

If r.mapcalc used G_parser(), a seed=... option would be the obvious
choice, but it doesn't, and that can't easily be changed. An
environment variable is probably the next best thing. For scripts,
setting an environment variable is typically easier than substituting
into an r.mapcalc expression (particularly if you are reading the
expression from a file).

-- 
Glynn Clements <glynn at gclements.plus.com>