[GRASS5] Re: Numercial stuff in GRASS

Markus Neteler neteler at geog.uni-hannover.de
Thu Jul 5 09:51:39 EDT 2001


(cc to grass5)

as your improvements and comments may be of further interest,
I cc it to grass5.

Hi all: Glynn is currently improving the "gmath" lib to add further
maxtrix/vector functionality:

On Thu, Jul 05, 2001 at 12:08:22PM +0100, Glynn Clements wrote:
> Glynn Clements wrote:
> > I'll look at egvorder() and transpose() next (the latter should be
> > trivial). The FFT stuff may be less straightforward.
> G_matrix_transpose() already existed. I've added
> G_matrix_eigen_sort(), which uses qsort() rather than an O(n^2)
> algorithm.
> I have a few comments about la.c generally:
> 1. It might be worth providing G_vector_{get,set}_element() functions. 
> The accessors for vectors are actually more involved than for
> matrices, due to the need to handle both row and column vectors and
> the v_indx field. OTOH, using such functions would typically impair
> efficiency.
> 2. While G_matrix_init() and G_vector_init() have corresponding
> G_matrix_free() and G_vector_free() functions, there aren't any
> equivalents for G_matrix_set() and G_vector_set().
> 3. Passing in an existing vector (or matrix) to receive output is
> potentially messy, due to the possibility of conflicts between the
> provided and required dimensions, and the issue of whether the caller
> or the function is responsible for initialisation. Returning a
> dynamically-allocated vector (or matrix) is simpler.
> 4. There are a number of cases where "const" should be used in
> parameter declarations. This is an issue with GRASS generally,
> although performance might be more relevant with the gmath library.
> -- 
> Glynn Clements <glynn.clements at virgin.net>

Please let us know your thoughts,


More information about the grass-dev mailing list