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

[Brad Douglas]

On Mon, 2007-08-20 at 22:08 +0200, Daniel Bundala wrote:
> Guys,
> 
> It is quite interesting, but I have had plans to replace v.generalize
> matrix code by "yours" library code. I have not studied G_matrix_*
> code carefully, but it seems to me that it is superior.

BLAS/LAPACK are vastly superior.

I have a couple modules I'm working on that I've either used or in
process of converting to use G_matrix_*()/G_vector_*() functions that
call BLAS/LAPACK.  I would also like to expand the usage of BLAS/LAPACK
by making additional functions available (I suspect this may be
beneficial to you, also).

> Firstly, Soeren wrote that the current code is multithreaded.

Soeren's code does not use BLAS/LAPACK.  It probably should.

> Secondly, someone mentioned, that it supports the sparse matrices.
> Support of sparse matrices would increase the efficiency of
> v.generalize since it uses only the sparse matrices.
> Thirdly, Soeren mentioned that the current code supports many methods
> my code doesnt support. To tell the truth, I have never heard about
> many of them (Well, I am still (young) student...)
> 
> The only thing I am missing in the current code is the direct access
> to the elements of a matrix. But, this is quite dangerous and I really
> doubt whether this is a good API-desing.
> 
> On the other hand, it is true that the current code is quite obscure,
> say. Also, it is tempting to replace fortran code by C code.
> Therefore, my suggestons are: clean library code and replace the
> current code by v.generalize code only if it is really faster. Some
> benchmarks are probably required, but I doubt that my code beats
> (optimized) library code.

One way or the other, it doesn't really matter to me.  I just don't want
to have modules with dependency requirements that others do not.  

BLAS/LAPACK are superior, but there's no since having it around if
nobody is going to use it.  It just becomes clutter at that point.  IMO,
few will compile it into their build if only a few obscure modules use
it; leaving those with more specific needs at a disadvantage.


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