[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