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, ...). > 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. > 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
