On Dec 30, 2012, at 2:26 PM, Sébastien Brisard <sebastien.bris...@m4x.org> wrote:
> Hello, > > Using the visitor pattern as a way to implement in-place basic linear > algebra operations was only a suggestion, I am not sure it's the best > option, even if I do think it's a simple and elegant option. However... > > > I think we might have a misunderstanding. What I am discussing is not the >> general implementation for a matrix, but the base interface that would be >> required for input into optimizers. I was saying that there should not be a >> burden of implementing visitor pattern for users creating a custom class >> for optimization input, if it is not used internally by the optimizers. > > > > There would be no burden on the user's side: the visitor pattern has been > implemented for RealVectors in version 3.1. Besides, we could provide all > the relevant visitors (addition, scaling, …) There is an additional burden to the user, since if you require implementation of the full RealVector or RealMatrix interface, which includes a large set of functions not need for the optimizer, since the user has no idea which function you will use inside the optimizer and which he can leave blank. For example, if a user needs to create their own implementation of a vector multiplication, because they have a special case which can be handled faster, or because they use a GPU, they are still burdened with implementing unnecessary support for the dozens of others functions which will never be used. For a GPU example, like Ted has pointed out, they can implement a GPU version for basic operations (add, multi, etc), but to guarantee general support for any Java function using the visitor pattern the user would also need to implement a Java version of the visitor pattern. > . > > >> It should only consist of the most general and yet basic set of function >> that are required. While visitor pattern can probably be used to implement >> all the functionality required for optimization, it would not be the most >> general formulation, > > > why? I thought that this pattern aimed at generality? I must be missing > something. You need to account for the cases when the actual vector addition (multiplication, etc) is offloaded to some black-box module. > > >> and hence preclude vector based process operations, such as you would find >> on a GPU. So if the user wanted to speed up the computation using a GPU >> they would not be able to do it, if we base it on a single element at a >> time visitor pattern. >> >> > I fail to see how the GPU could not be used. I am no expert on GPU > programming, but I can easily imagine a new implementation of RealVector, > say GpuBasedRealVector, where the walkInDefaultOrder method would send > multiple values at a time to the GPU. I've already done that for multi-core > machines (using fork/join), and the visitor pattern was certainly not a > limitation. > > Thanks, >> Konstantin >> >> > Again, I'm not saying that the visitor pattern is THE solution. I'm only > saying that we should not discard it for wrong reasons. Also, I do think > that the other proposed solution (duplicate all current implementations of > RealVector with in-place operations) is very *dangerous*. > > Indeed, depending on x being an instance of ArrayRealVector or > InPlaceArrayRealVector, x.add(y) would have very different side effects (x > is or is not changed). This means that any algorithm taking a RealVector as > an input can no longer make the assumption that the vectors are unchanged. > In some cases, this would lead to copies of the vector on which some basic > linear algebra operations must be performed, "just in case". So we're back > to square one, since the initial motivation for in-place operations is > limitation of memory footprint. > > If we do not want to go for the visitor pattern (which, again, I'm happy > with), I think the only option is to hard code *new* methods addToSelf and > the likes. > > Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
