[GRASS-dev] r.univar -e

[Hamish]

> Hamish wrote:
> > I guess the multi-file thing precludes qisort.c becoming a
> > fast G_qsort()?
> 
> No. In my comments above, "used" refers to the point where the
> variable's name appears.
> 
> If you have e.g. G_qsort(..., cmp_int), cmp_int is "used" in the file
> in which the call occurs, not the file where G_qsort() is defined. So
> long as the call occurs in the file where cmp_int is defined, it
> doesn't matter if it is declared "static".

ok.

> The libc qsort() needs to work over a wide range of cases, in terms of
> element size, number of elements, and whether the data is almost
> sorted, unsorted almost reverse-sorted etc.
> 
> Some approaches do better for almost-sorted data at the expense of the
> general case (or vice-versa), or have better worst-case behaviour at
> the expense of the general case (or vice-versa).
> 
> In general terms, a sorting algorithm optimised for specific cases
> will do better than a general-case one. If we were to add a single
> G_qsort() function, we would need to consider all use cases rather
> than choosing an algorithm based upon a specific case. OTOH, if we
> were to add a selection of sorting functions, each case would need to
> determine the correct one to use.


I suppose our general case is cells which are not fully random. Usually
raster data will be clumped, or at least cells will be part of a
continous function (nearby cells won't be far off). Highly random raster
data is probably pretty unusual.


Hamish