2007/8/17, Brad Douglas <[EMAIL PROTECTED]>: > 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.
Well, i was responding ... . > > > > > > 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? I think we shoudl keep the LAPACK/BLAS interface in GRASS, especially for high performance comnputing on cluster, the LAPACK interface makes much sense. I had a short look at matrix.c and matrix.h in v.generalize. Because of the similar implementation of the gpde library functionality, i am able to port the functionality of v.generalize/matrix stuff into the gpde library. And i will implement it multithreaded, like all the linear equation solvers within the gpde library. What do you think? Soeren > > > -- > 73, de Brad KB8UYR/6 <rez touchofmadness com> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
