commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <kber...@gmail.com>
Subject Re: [math] major problem with new released version 3.1
Date Fri, 28 Dec 2012 22:35:36 GMT
> 
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message