commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.
Date Tue, 27 Nov 2012 22:14:03 GMT
Hi Gilles,



2012/11/27 Gilles Sadowski <gilles@harfang.homelinux.org>

> On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
> > On Tue, Nov 27, 2012 at 04:44:27AM +0100, S├ębastien Brisard wrote:
> > > Hi,
> > >
> > >
> > > 2012/11/27 Gilles Sadowski <gilles@harfang.homelinux.org>
> > >
> > > > Hello.
> > > >
> > > > > > > in MATH-803 [1] it was decided to deprecate
> > > > > > RealVector.ebeMultiply/Divide,
> > > > > > > because these methods were difficult to support with sparse
> vectors.
> > > > > > > However, in MATH-870, we decided to deprecate sparse vectors
> > > > altogether.
> > > > > > >
> > > > > > > I'm therefore having second thoughts on MATH-803. Since
the
> > > > problematic
> > > > > > > implementations of RealVector are removed, why not keep
these
> quite
> > > > handy
> > > > > > > methods?
> > > >
> > > > The goal was also to "clean up" the matrix and vector
> implementations.
> > > >
> > > > True, but all good scientific packages (matlab, scilab, numpy) have
> these
> > > operations. If we do not keep them in the interface of RealVector
> (which
> > > I'm OK about), we need to provide a clean alternative. At the moment,
> > > visitors are not clean.
>
> I also agree with that. It's not necessarily conflicting with what I
> propose
> to solve MATH-895.
>
> Replacing the current RealMatrix visitor interface is not obvious, partly
> because we wish to have the same API for RealVector and RealMatrix (2
> different types). [AFAICS, in Python for example, the arguments are just
> "lists of (lists of) numbers".]
>
> An alternative (to try and mimic what exists in those other languages)
> would
> be to stick with the current CM design and add methods similar to "map":
>
>   public static RealVector map(UnivariateFunction f,
>                                RealVector v)
>   public static RealVector map(BivariateFunction f,
>                                RealVector v1,
>                                RealVector v2)
>   public static RealVector map(TrivariateFunction f,
>                                RealVector v1,
>                                RealVector v2,
>                                RealVector v3)
>   public static RealVector map(MultivariateFunction f,
>                                RealVector... vectors)
>
>
> I like that.


> [I also think that this is actually not the same as the "visitor" pattern
> (where the antries can be visisted in any order) whereas in the above
> cases,
> the assumption is that iterating on each vector is done similarly to
> looping
> over the index of the "getEntry(int index)" method.]
>
> It would be good if we could come up with a design which would exploit the
data structure (ie map over 2/3 ArrayRealVector should use the underlying
arrays).

> It also might make more sense to add these feature in "MathArrays":

>
>   public static double[] map(UnivariateFunction f,
>                              double[] v)
>   public static double[] map(BivariateFunction f,
>                              double[] v1,
>                              double[] v2)
>   public static double[] map(TrivariateFunction f,
>                              double[] v1,
>                              double[] v2,
>                              double[] v3)
>   public static double[] map(MultivariateFunction f,
>                              double[][] vectors)
>
> [Where the assumption which I referred to above is trivially verified.]
>
> +1


> Regards,
> Gilles
>
> >
> > Is "ebeDivide" a (mathematical) "vector" operation?
> > IMHO, it's an operation on 2 lists of values.
> >
>
I agree, but it's still useful to have it on vectors... But I'm happy with
map.

> > >
> > >
> > > > I'd rather suggest to add such features in the "MathArrays" class:
> > > > -----
> > > > public static double[] ebeDivide(double[] numer,
> > > >                                  double[] denom) {
> > > >   if (numer.length != denom.length) {
> > > >     throw new DimensionMismatchException(numer.length, denom.length);
> > > >   }
> > > >
> > > >   final double[] result = numer.clone();
> > > >   for (int i = 0; i < numer.length; i++) {
> > > >     result[i] /= denom[i];
> > > >   }
> > > >
> > > >   return result;
> > > > }
> > > > -----
> > > >
> > >
> > > I'm not adverse to the idea, but actually, cleaning recently took
> place the
> > > other way round. In RealVector, we removed all methods which took an
> array
> > > in place of a vector, since constructing an ArrayRealVector from an
> array
> > > is almost costless (using the right constructor).
> >
> > So?
> > This method is to be placed in "MathArrays", not "RealVector". Then, it
> > would be used (e.g. in "JacobiPreconditioner") as:
> > -----
> > public RealVector operate(final RealVector x) {
> >   // Dimension check is carried out by ebeDivide
> >   // return x.ebeDivide(diag); // XXX deprecated.
> >   return new ArrayRealVector(MathArrays.ebeDivide(x.toArray(),
> >                                                   diag.toArray()),
> >                              false);
> > }
> > -----
> >
> >
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message