[GRASS-dev] r.univar -e

Glynn Clements glynn at gclements.plus.com
Wed Sep 6 03:59:46 EDT 2006


Hamish wrote:

> > I have added '-e' flag to r.univar according to r.univar.sh. See the
> > attached patch. Please look at the code, any comments welcomed...
> > (before committing to CVS - if desired...).
> 
> Nice work!
> 
> I have merged your patch locally with a few minor changes:
>   http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.c
>     or if you prefer,
>   http://bambi.otago.ac.nz/hamish/grass/r.univar_ext.diff
> 
> 
> A few comments/questions before putting it in CVS:

> * qsort() comparison functions are declared as static int. 
> a) shouldn't they just be int?

They aren't used from outside the file in which they are defined, so
they should be declared "static".

Note that "static" is a storage specifier; it isn't part of the type.

> b) could/should these fns be inlined for speed?

Indirect function calls (e.g. qsort() callbacks) cannot be inlined.

> * GRASS 5's s.cellstats uses something called qisort() instead of
> qsort(), which claims to be faster. Comments from the crowd?
>  http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/sites/s.cellstats/qisort.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

It claims to be faster than some specific qsort() implementations on a
specific system for specific test cases.

Unless there is empirical evidence that qisort() beats the system's
qsort() on the majority of systems with representative test data, I
would recommend sticking with the system's qsort() routine.

> * Are there any issues with having shell variables (-g flag) which start
> with a number?

Yes; at least, bash doesn't allow them.

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




More information about the grass-dev mailing list