Hi Gilles,
2012/11/27 Gilles Sadowski <gil...@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 <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 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-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
>
>
