> > That's what I was going to write. At the moment, the current implementation > for sparse matrices and vector is deprecated, for lack of convincing fixes > for the bugs which have been found. These bugs are mainly related to the > fact that zero --the unstored value-- is signed, and the sign is lost in > sparse implementations. This might be considered as unimportant, but leads > to the fact that wa cannot achieve the same level of correctness in our > sparse impl as in our dense impls. > > As for data copying, I strongly agree, and it is not really related to the > implementation of sparse vectors/matrices. For example, our implementation > of the conjugate gradient only requires a linear operator --not a matrix--, > which can be as sparse as you want. The problem is that all implementations > of iterative linear solvers use basic vector operations (add, sub, etc...), > which cannot be carried out in-place in the current abstract class > RealVector. This leads to unnecessary memory allocations for very large > problems. I am currently facing this issue. My matrix is not a problem > (it's actually a so-called "matrix-free" problem), and the vectors are > dense. The only problem is the demand in RAM. We should really give a > thought to in-place linear operations, without cluttering too much the API! > A possible way would be to use visitors. > > Best regards, > Sébastien >
I think this issue can be overcome by proper OO design, and hacked on to the current interface for now. We can create an "InPlace" interface that all linear operators (including RealMatrix etc) would implement. For example in a hypothetical InPlaceMatrix class function InPlaceVector mult(InPlaceVector x), depending on implementation details, would either return back overwritten x in the return value, or a new value for multiplication leaving x in tact. This would allow the user to implement their more efficient version, while also allowing the usage of current linear algebra package if they don't care about performance. The idea is that the optimization classes would rely only on the InPlace interface for all their tasks. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
