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 Sun, 30 Dec 2012 19:26:49 GMT

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

> 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

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


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