[GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

[Vaclav Petras]

On Wed, Oct 7, 2015 at 7:00 PM, Glynn Clements <glynn at gclements.plus.com>
wrote:
>
> Vaclav Petras wrote:
>
> > I was not able to determine from svn why gmath.h contains la.h.
>
> AFAICT, it's because the functions are in lib/gmath. Of course, that
> then brings up the question why they're there, rather than in a
> separate library ...
>
> Incidentally, the whole of lib/gmath/la.c is conditionalised upon
>
>         #if defined(HAVE_LIBLAPACK) && defined(HAVE_LIBBLAS)
>
> but individual functions (and even sections of functions) are
> conditionalised as necessary.

I have seen this code before and I was not courageous enough to clean it up.

> And there are a few functions for which we could reasonably supply our
> own implementation if BLAS/LAPACK aren't available. E.g.
> G_matrix_product() and G_vector_norm_euclid() should be
> straightforward.

Perhaps this is the idea of having the functionality in gmath itself is
behind having it part of gmath. Then the question is if we actually want
this or we want to move it. If we will be able to provide our
implementations, it doesn't matter where the functions are.

I like the idea of a separate header but I would leave the implementation
in lib/gmath. Or is this going too much against how other libraries are
done? I'm also not sure how the prefixes should work, but these seems OK
since there are functions with same prefix (G_) in several libraries.

Having la.h as a separate header would conveniently hide the compilation
issue on that Debian server.

So, should I remove la.h from gmath.h?

> AFAICT, G_matrix_LU_solve() is the only function that's moderately
> complex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151011/ab14d837/attachment.html>