What methods do you need?
Maybe an interface with:
public interface SimpleRealVector {
double getEntry(int i);
int getDimension();
}
will do?
Am Donnerstag, den 11.08.2011, 05:36 +0200 schrieb Sébastien Brisard:
> Hello,
> this is an idea I've had while thinking about Iterative Linear
> Solvers, but I think it is much more general. I don't know whether
> what I'm going to describe is a known pattern, or a very dirty trick I
> should forget about. So any advice would be greatly appreciated.
>
> For the sake of the argument, let us stick with iterative linear
> solvers. Most of them modify in-place the current estimate of the
> solution, x (which is a RealVector). In view of observing the state of
> the solver during the iterations, I'd like to provide a method
> RealVector getCurrentSolution()
>
> As modifying the current solution outside the solver would ruin the
> iterations, it is imperative to return a deep copy of x. This can take
> time, if the vector is large. Also, it can be memory consuming. So I
> was wondering: would it be possible to design a ReadOnlyRealVector
> class, which would be final, have a unique constructor
> ReadOnlyRealVector(RealVector v)
> and extend AbstractRealVector
>
> I would keep a reference to the underlying RealVector used to
> construct the ReadOnlyRealVector, so that any call to a standard
> RealVector method would be delegated to the same method in v. EXCEPT
> when the method in question would normally modify the
> ReadOnlyRealVector, in which case an UnsupportedException would be
> thrown. For example
>
> v = new RealVector();
> ...
> vro = new ReadOnlyRealVector(v);
> vro.map(f); // Returns v.map(f)
> vro.mapToSelf(f); // Throws an exception
>
> Note that "Read-Only" does not mean "Immutable", since a modification
> of v would modify vro. This would suit my requirements, but it should
> be made clear in the Javadoc.
> Is it clean code, or should I throw it away?
> In the former case, would a ReadOnly tagging interface make sense?
>
> Thanks for your comments/corrections,
> Sebastien
>
> ---------------------------------------------------------------------
> 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
