Hello,
2012/12/28 Konstantin Berlin <kber...@gmail.com> > > > > 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 > > I'm not sure about that. If I understand correctly, this would mean that the _user_ has to provide the solver with a so-called InPlaceVector. I don't think it should be the responsibility of the user to chose whether or not a solver performs in place operations. As I said previously visitors are a good way to do that without cluttering the interface. For example, we could define a Multiply visitor, which scales all components of a vector. A nice idiom would be to have a factory method Multiply.by(double) instead of a constructor new Multiply(double). This way, scaling a vector in place would read v.walkInDefaultOrder(Multiply.by(double)) What do you think? Sébastien
