Hi Gilles,
2012/11/27 Sébastien Brisard <sebastien.bris...@m4x.org>
> 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 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-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
>>
>>
>
