[GRASS-dev] using rand(x,y) in r.mapcalc (grass7)

[Glynn Clements]

Glynn Clements wrote:

> > I wonder if there are any modules in core or addons which need to be
> > updated.
> 
> The following are candidates for conversion:

Most uses of rand, random, lrand48, etc have been replaced in r61415
and r61416.

Many of these modules seeded the RNG from either the clock or the PID,
with no way to provide an explicit seed. In such cases, the use of
G_srand48_auto() has been marked with a "FIXME" comment.

It would be possible to modify G_srand48_auto() to allow the use of an
environment variable, but this has problems of its own (e.g. setting
the variable manually then forgetting about it).

r.li.daemon/daemon.c uses a hard-coded seed of zero.

r61416 changes readcell.c in r.proj, i.rectify, and i.ortho.rectify. 
These all used rand() to select a random cache block for ejection.

While this wouldn't have affected the result, only the first RAND_MAX
cache blocks would have been used. RAND_MAX is only guaranteed to be
at least 32767, which would limit the effective cache size to 1 GiB
(each block is 64 * 64 = 4096 "double"s = 32kiB).

Cases which haven't been changed are:

lib/raster3d/test/test_put_get_value_large_file.c. This appears to be
a test case; does it matter?

include/iostream/quicksort.h uses random() or rand() to select a pivot
for the quicksort algorithm. That file has no dependency on lib/gis
(or anything else, except for <stdlib.h> for random/rand), and I
didn't want to add one unnecessarily.

Again, this shouldn't affect the result, but there may be performance
issues if the size of the array being sorted is significantly larger
than RAND_MAX (in this situation, the algorithm will be O(n^2) even in
the best case).

Unless there's a specific reason not to, it may be better to simply
replace all uses of that file with std::sort() from <algorithm>.

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