>> >> 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
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 optimize. 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. -Konstantin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
