commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] major problem with new released version 3.1
Date Sat, 29 Dec 2012 09:12:15 GMT

2012/12/28 Konstantin Berlin <>

> >
> > 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:
> For additional commands, e-mail:
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 instead of
a constructor new Multiply(double). This way, scaling a vector in place
would read

What do you think?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message