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:41:43 GMT
Hi Gilles,


2012/11/27 Sébastien Brisard <sebastien.brisard@m4x.org>

> 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 a to have it on vectors... But I'm happy with map.
>

In fact, you convinced me. It's not a linear algebra operation, and should
therefore not be in the RealVector interface. It's true that users are most
likely to invoke those methods on array-based vectors anyway.

Best regards,
Sébastien

>  > >
>> > >
>> > > > 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