[GRASS-dev] BLAS/LAPACK (Part II)

[Brad Douglas]

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
> it.
> 
> 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
compiled in?

> > 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
BLAS/LAPACK:

G_matrix_product ()
G_matrix_LU_solve ()
G_vector_norm_euclid ()
G_matrix_inverse () -- calls G_matrix_LU_solve ()

v.generalize solves:
G_matrix_product ()
G_matrix_inverse ()
G_matrix_LU_solve ()

So what's the point of having BLAS/LAPACK?


-- 
73, de Brad KB8UYR/6 <rez touchofmadness com>