OK, this I also think would be useful. But my initial question
remains, if the object I want to protect is not a RealVector, what do
you think of my solution ?
Sébastien
PS : the problem is likely to occur when listening to other Iterative
Processes (not only linear solvers). For example, in o.a.c.m.genetics,
has a StoppingCondition.isSatisfied(Population),
and Population.addChromosome() would enable the StoppingCondition to
actually modify the ongoing simulation. Whether it is harmfull, I do
not know, though.
So of course, we could come up with a ImmutablePopulation as well, but
maybe it starts to get complicated?
Sébastien
2011/8/11 Luc Maisonobe <luc.maison...@free.fr>:
> Le 11/08/2011 10:55, Sébastien Brisard a écrit :
>>
>> 2011/8/11 Arne Ploese<aplo...@gmx.de>:
>>>
>>> So you not only want to observe the result, but you want a read only
>>> RealVector.
>>>
>> That's right. I'm sorry, my first message was not clear, especially if
>> you did not follow the thread on iterative solvers.
>> I want to observe the *solver*, and the current state of the solver is
>> a *RealVector*, which should by no means be modified by the observer.
>> The safest way to do that would be for the solver to have a method
>> like
>> public RealVector getCurrentSolution(){
>> return x.copy();
>> }
>> but that takes both time and memory. So I was thinking of something more
>> like
>> public RealVector getCurrentSolution(){
>> return new ReadOnlyRealVector(x);
>> }
>> which takes virtually no additional memory (and presumably very little
>> time). The two advantages of this approach are
>> * it does not jeopardize the whole hierarchy tree, since you do not
>> have to create a new interface,
>> * it is quite general, and could be adopted for any base object (not
>> only RealVector).
>> The downside is that some methods throw exceptions, which might be
>> deemed dirty. I don't really know.
>
> Well, in fact I would very much like to have immutable vectors too.
> Immutability is really a way to simplify implementations. Surprisingly it
> sometimes also decrease time and memory consumption, because defensive
> copies littering user code can be avoided.
>
> Jeopardizing the hierarchy tree is not a problem IMHO.
>
> Luc
>
>> S
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
