[GRASS-dev] [GRASS GIS] #2272: Improve consistency in random generator usage

[GRASS GIS]

#2272: Improve  consistency in random generator usage
-------------------------+--------------------------------------------------
 Reporter:  neteler      |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  blocker      |   Milestone:  7.0.0                    
Component:  Default      |     Version:  svn-releasebranch70      
 Keywords:  random       |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by neteler):

 For the record, from grass-dev:

 On Sun, Jul 27, 2014 at 1:58 AM, Glynn Clements wrote:
 > 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>.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2272#comment:3>
GRASS GIS <http://grass.osgeo.org>