commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Ploese <aplo...@gmx.de>
Subject Re: [math] Read-only RealVector
Date Thu, 11 Aug 2011 07:42:41 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 



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


Mime
View raw message