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