[GRASS-dev] BLAS/LAPACK (Part II)
rez at touchofmadness.com
Fri Aug 17 07:54:38 CEST 2007
On Fri, 2007-08-17 at 17:12 +1200, Hamish wrote:
> Brad Douglas wrote:
> > I did not hear any response to my question of whether to continue
> > using BLAS/LAPACK.
> > This uncertainty has been particularly hard on me, being unable to
> > complete some work waiting for an answer one way or the other and not
> > wanting to implement my own version if not needed.
> > Currently, there is no code in the tree that makes use of either
> > library other than my own. In fact, others have implemented their own
> > versions.
> If having it there is not hurting anything, I'd say leave it as-is.
> It is less work to maintain the configure scripts than it is to stay
> current with the latest advancements in the library. ie 5 years from
> now we'd have an unmaintained stale copy distributed with our source.
? There's nothing to go stale. Or are you making my case for me?
> BLAS/LAPACK are in common use elsewhere, so it's not like a user would
> have to spend time hunting down and compiling obscure software to use
> Take pride in being the first to use it, we've been waiting a while for
> someone to. :)
And then having modules become useless when the libraries aren't
> > What I propose is moving the matrix code from v.generalize (in
> > particular, matrix_inverse() ) to lib/gmath and simplifying the
> > existing MATRIX structure.
> regardless of BLAS/LAPACK staying or going, consolidation, consistency,
> and anything else that makes the code easier to maintain is obviously a
> good thing. (but no idea about that specific code)
There are only a few functions in lib/gmath that make use of
G_matrix_inverse () -- calls G_matrix_LU_solve ()
So what's the point of having BLAS/LAPACK?
73, de Brad KB8UYR/6 <rez touchofmadness com>
More information about the grass-dev