Re: [math] RealMatrixPreservingVisitor and RealMatrixChangingVisitor the same?

[Gilles <gi...@harfang.homelinux.org>]

On Wed, 30 Dec 2015 10:55:44 +0100, Luc Maisonobe wrote:
> Le 30/12/2015 06:18, Ole Ersoy a écrit :
>> Hi,
>
> Hi Ole,
>
>>
>> RealMatrixPreservingVisitor and RealMatrixChangingVisitor files look
>> identical with the exception of a single @see Default... annotation
>> (Which I think is redundant...same as > All known implementing
>> classes...?).  Would it make sense to remove the annotation and have 
>> one
>> RealMatrixChangingVisitor extend RealMatrixPreservingVisitor?
>
> No. They are different and used for different things.
> The visit method returns void in one case and double in another
> case. When it returns double, this double is used to update
> the matrix that is visited, hence the "Changing" nature of the
> visitor.

The "visitor" itself is not "preserving" or "changing" anything.
It can't even know that its computation is related to a matrix
(it's only in the caller's mind that its 3 inputs are row, column,
and corresponding entry of a matrix).
It's the matrix that decides what it wants to do with the result
of the "visitor" instance.
So the interfaces' names are somewhat misleading.

IIUC, the current design is based on the fact that only the matrix
class at hand knows the best way to iterate over its elements.
Hence the loop for visiting entries must be located there, at least
for "walkInOptimizedOrder".

There is a single usage of this "visitor" functionality within CM.
Hence I wonder how useful all the repetitive code (in all the other
"walk..." methods) really is.
I'd leave them out from the refactored matrix implementations.
I recall that there was a "complaint" that the CM matrix interface
was much too heavy for some usage, as it requires the implementation
of many methods that are useless in some applications (e.g. geometry
IIRC).

I'd advise that you have a look at other libraries if you want to
try to improve this area of CM (others have tried...).


Regards,
Gilles

> best regards,
> Luc
>
>>
>> Cheers,
>> Ole


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org