On Wed, Oct 7, 2015 at 7:00 PM, Glynn Clements <gl...@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.
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
