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 <gil...@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 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 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.]
Regards,
Gilles
>
> Is "ebeDivide" a (mathematical) "vector" operation?
> IMHO, it's an operation on 2 lists of values.
>
> >
> >
> > > 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-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
