[GRASS-dev] r.univar -e

[Hamish]

Martin:
> > > 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...).
Hamish:
> > I have merged your patch locally with a few minor changes:

now in 6.3-CVS.


> > A few comments/questions before putting it in CVS:
> 
> > * qsort() comparison functions are declared as static int. 
> > a) shouldn't they just be int?
Brad:
> static is the best declaration.  Declaring the function static means
> it is "bound" to that file.  As long as qsort() is called [only] from
> that file, it will work as designed.
Glynn:
> 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.

ok, I was thinking about the "global variable" use of that memory space.
I guess the multi-file thing precludes qisort.c becoming a fast G_qsort()?

fwiw, r.terraflow defines comparison functions in a similar way.

 
> > 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.

Martin:
real    0m0.817s
..
real    0m0.532s

But I suppose the gcc/glibc people have their [good] reasons..........


> > * Are there any issues with having shell variables (-g flag) which
> > start with a number?
> 
> Yes; at least, bash doesn't allow them.

ok, changed 1st_quartile= to first_quartile=, etc.



I have updated i.landsat.rgb in CVS to use the new r.univar. For my
sample imagery, processing now takes 4.0 seconds instead of 31.5! 8x win!



Hamish