commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <>
Subject Re: [math] Questions about the linear package
Date Wed, 14 Oct 2009 23:49:33 GMT
On Wed, Oct 14, 2009 at 11:07 AM, Luc Maisonobe <>wrote:

> Jake Mannix a écrit :
> > Hi Luc,
> >
> >
> > On Wed, Oct 14, 2009 at 3:01 AM, <> wrote:
> >
> >>>   * also for RealVector - No iterator methods?  So if the
> >>> implementation is
> >>> sparse, there's no way to just iterate over the non-zero entries?
> >>> What's
> >>> worse, you can't even subclass OpenMapVector and expose the iterator
> >>> on the
> >>> OpenIntToDoubleHashMap inner object, because it's private. :\
> >> Good idea. You can use JIRA <
> >
> >> to register a request for implementing this. Patches are of course
> welcome.
> >> There should probably be two iterators: one for all entries and one for
> the
> >> non-default entries (which may be non-zeroes or non-NaN or anything
> else).
> >>
> >
> > I'll open up a ticket and attach a patch (with tests, naturally) later
> > today.
> Very good. Thank you

Question about this: if RealVector is locked as an interface - no changes
3.0 - and the Matrix and Vector interfaces have method signatures which take
RealVector as an argument, how is adding new methods to an implementation
of RealVector (say AbstractRealVector) going to help anyone?

I mean, if I make a patch, for example, where AbstractRealVector has:

  public interface Entry {
    double getValue();
    int index();
    void setValue(double d);

  Iterator<AbstractRealVector.Entry> iterator();
  Iterator<AbstractRealVector.Entry> nonDefaultIterator();

  RealVector map(UnaryFunction func);
// more like that
  double collect(BinaryCollector collector, RealVector otherVector);

then only code which knows it's using an AbstractRealVector can use
these methods, while most methods return RealVector.

I suppose if the patch refactors ArrayRealVector and OpenMapRealVector to
extend AbstractRealVector, then people can always fairly safely try to cast
their RealVector to AbstractRealVector to use these methods...

I guess that's all one can do - test to see if you have an
and if you do, you can use these new methods, if not, do something the old
or slower way (or throw UnsupportedOperationException if you really can't
do it properly).

It's just sad if there were then nice new abstractions, like VectorMetric,
defines an innerProduct between vectors, which would want to be implemented
as AbstractRealVector.collect(MetricCollector mColl, RealVector vector),
with a
suitably defined BinaryCollector - then this would only make sense to take
AbstractRealVector instances, but defining an interface like:

interface VectorMetric {
  double innerProduct(AbstractRealVector v1, AbstractRealVector v2);

is lame - we would want them to be RealVectors - but then coding the
implementation requires a split code path: one for RealVectors which aren't
descendents of AbstractRealVector, and one for those which are.

Any thoughts on the right way to approach the idea of adding methods
to RealVector without, you know, actually breaking backward compatibility?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message