commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] Read-only RealVector
Date Thu, 11 Aug 2011 10:01:53 GMT
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 ?

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?


2011/8/11 Luc Maisonobe <>:
> Le 11/08/2011 10:55, Sébastien Brisard a écrit :
>> 2011/8/11 Arne Ploese<>:
>>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message