[GRASS-dev] r.mapcalc addition

[Glynn Clements]

Joel Pitt wrote:

> > > > 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).
> >
> > if you have more than one call to rand() and both are seeded with the
> > same value (GRASS_RND_SEED or whatever), won't you get the same "random"
> > number both times?
> >
> > should the seed be read on startup in main.c, not xrand.c ..?
> 
> I implemented a static variable in rand function, so that it will only
> be read the first time rand() is called - independent of how many
> rand() occurences are in the expression.

Note that this is necessary even if rand() only occurs once in the
expression, as the function (f_rand()) gets called once per row. You
don't want the PRNG to get re-seeded at the beginning of each row ;)

> However, I'll follow Glynn's suggestion and read the seed in the
> evaluate() function. This will be more robust if other functions are
> implemented that call the RNG.
> 
> On this topic, would there be any call for implementing more
> complicated probability distribution functions? Or is the philosophy
> of mapcalc to have the simplest elements necessary?

A Gaussian distribution might be useful, as you can't readily
implement that using existing r.mapcalc functions (the usual
implementation uses iteration, which r.mapcalc doesn't support).

For enhancements which might be useful to other users, I'd suggest
posting an announcement (or the code itself) to the list. If enough
people express an interest in having the functionality built in, we
can add it.

Adding new functions is quite straightforward; OTOH, we don't want to
bloat r.mapcalc with code which is unlikely to be used by anyone but
its author.

For more complex tasks, there's always R/GRASS. r.mapcalc will always
be bound by its structural limitations (row-by-row processing,
inability to define new functions, etc).

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