Two things:
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.
2) Wondering if people would find it useful to add a generic doubly
linked list to the gis library? I don't see such a thing, and they
come in handy from time to time. I've got a implementation that
works pretty well, with some useful functions (copy, sort, filter,
uniquify). It probably doesn't do everthing everyone would want it
to do, but it can easily be extended. If you want to look at it,
it can be read/retrieved from http://pweb.jps.net/~egm2.
--
Eric G. Miller <egm2@jps.net>
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.
--
Glynn Clements <glynn.clements@virgin.net>
On Sun, Feb 24, 2002 at 05:17:14AM +0000, Glynn Clements wrote:
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? 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? 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.
--
Eric G. Miller <egm2@jps.net>
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@virgin.net>
Eric G. Miller wrote:
[...]
2) Wondering if people would find it useful to add a generic doubly
linked list to the gis library? I don't see such a thing, and they
come in handy from time to time. I've got a implementation that
works pretty well, with some useful functions (copy, sort, filter,
uniquify). It probably doesn't do everthing everyone would want it
to do, but it can easily be extended. If you want to look at it,
it can be read/retrieved from http://pweb.jps.net/~egm2.
Eric
I am preparing a graph -like thing, as part of the import filter, and maybe for other purposes. It is doubly linked so would do for a doubl-linked list, by just using n_vertices = 2. It doesn't have any functions other than the linking, but other things could be added. There is already an example in v.in.shape/mif, but it's sort of hard-wired into these functions so not much use for general-purpose.
David
On Sun, Feb 24, 2002 at 10:24:49PM +0000, David D Gray wrote:
Eric G. Miller wrote:
>[...]
>2) Wondering if people would find it useful to add a generic doubly
>linked list to the gis library? I don't see such a thing, and they
>come in handy from time to time. I've got a implementation that
>works pretty well, with some useful functions (copy, sort, filter,
>uniquify). It probably doesn't do everthing everyone would want it
>to do, but it can easily be extended. If you want to look at it,
>it can be read/retrieved from http://pweb.jps.net/~egm2.
>
>
Eric
I am preparing a graph -like thing, as part of the import filter, and
maybe for other purposes. It is doubly linked so would do for a
doubl-linked list, by just using n_vertices = 2. It doesn't have any
functions other than the linking, but other things could be added. There
is already an example in v.in.shape/mif, but it's sort of hard-wired
into these functions so not much use for general-purpose.
A graph is a bit different from a run of the mill linked list. I think
it'd be useful to have both.
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
On Sun, Feb 24, 2002 at 10:24:49PM +0000, David D Gray wrote:
[...]
Eric
I am preparing a graph -like thing, as part of the import filter, and maybe for other purposes. It is doubly linked so would do for a doubl-linked list, by just using n_vertices = 2. It doesn't have any functions other than the linking, but other things could be added. There is already an example in v.in.shape/mif, but it's sort of hard-wired into these functions so not much use for general-purpose.
A graph is a bit different from a run of the mill linked list. I think
it'd be useful to have both.
Yes. It would be useful to build up a full set of standard containers in C.
David