[GRASS5] dalloc.c, svd.c ?? linked list code ??

[Glynn Clements]

Eric G. Miller wrote:

> > > 1) Anybody know anything about dalloc.c and svd.c in the gis library?
> > > Seems the dalloc.c functions should be documented with the other memory
> > > management routines.  I don't know what svd.c is about.  There are
> > > virtually no comments in the code, nothing in the programming manual
> > > that I could find.  It'd be good to get these items documented.  
> > 
> > FWIW, the functions in svd.c are used by m.svfit, which has the
> > description:
> > 
> >        m.svfit - Semivariogram model fitting.
> > 
> > Both svd.c and dalloc.c appear to overlap with the plans for the gmath
> > library.
> 
> I already went ahead and put minimal documentation for the dalloc
> routines in the programmer manual.  Should, I back those out?

Probably not. Those functions allocate the type of matrix which is
actually used by most of the existing matrix-related functions. OTOH,
the gmath library is, in practical terms, still on the drawing board.

> If they
> aren't going to stick around, we probably don't want people to use
> them.  If there are similar memory routines for gmath, maybe we could
> harmonize the bunch?

gmath defines its own matrix/vector structure (in la.h), but currently
nothing uses them (i.e. the only functions which do use them are
themselves unused).

In any case, I'm far from convinced that the gmath structure is the
right answer. E.g. it assumes more flexibility than many of the
underlying functions are likely to provide (e.g. stride != width).

> And, if svd.c is only used by m.svfit, and there
> is/will be similar functionality in gmath, I don't see a good reason
> for it being stuck in libgis.

svd.c, lu.c and eigen_tools.c probably belong in libgmath, possibly
along with dalloc.c and ialloc.c.

-- 
Glynn Clements <glynn.clements at virgin.net>