[GRASS-dev] r.univar: allow multiple rasters to be processed

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

[...]

 > Is there some fundamental reason why r.univar has separate cases for
 > CELL/FCELL/DCELL types, rather than just working in DCELL throughout?

 > Most of the time, there's no value to having separate CELL/FCELL
 > cases. There's hardly ever a reason to have a separate FCELL case,
 > and a separate CELL case is only really useful if you specifically
 > need integer-specific operations (e.g. integer division, bitwise
 > operations etc).

 > I'm aware that r.univar was already like this, but if there isn't a
 > valid reason, this would be a good time to simplify it.

	I don't know for sure, but apparently the distinction is only
	effective when gathering extended statistics (percentiles,
	median.)

	Since the extended statistics code temporarily stores all the
	values from the raster(s) being processed, using native types
	may lead to reduced memory usage and processing time.

 > Apart from anything else, the calculation of the square:

 >>  	    if (map_type == CELL_TYPE) {
 >> -		val_i = *((CELL *) ptr);
 >> +		const int val_i = *((CELL *) ptr);

 >>  		stats->sum += val_i;
 >>  		stats->sumsq += (val_i * val_i);

 > will wrap if abs(val_i) > 46340 (sqrt(2^31) = 46340.95).

 > If the three separate cases are to be kept, the last line above
 > should be:

 > 		stats->sumsq += (double) val_i * val_i;

	Agreed.