commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <>
Subject Re: [math] major problem with new released version 3.1
Date Sat, 29 Dec 2012 23:22:03 GMT
>> 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
> v.walkInDefaultOrder(
> What do you think?
> S├ębastien

The user would not have to do anything, since any RealMatrix implementation would implement
the InPlace interface. The user is free to just pass in a standard RealMatrix class, it will
just (temporarily) not actually perform an in place operation, so it would waste memory, but
otherwise would provide correct behavior. The choice of InPlace operation (and any other required
operation) is controlled by the implementation of the optimization solver, not the user. I
think design wise it's better, since the optimization function does not require anything more
basic than some class that implements a few vector operations. It does not need to rely on
something as heavy as a RealMatrix, or as limiting as a double[][], and this would allow for
the user to implement their own version, if they have some large problem that they want to

While visitor pattern is a good abstraction, I think it would make for terrible linear algebra
performance. All operations should be based on basic vector operations, which internally can
take advantage of sequential memory access. For large problems it makes a difference. The
visitor pattern is a nice add on, but it should not be the engine driving the package under
the hood, in my opinion.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message