commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: svn commit: r1348721 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/linear/OpenMapRealVector.java test/java/org/apache/commons/math3/linear/SparseRealVectorTest.java
Date Mon, 11 Jun 2012 20:46:17 GMT
Hi.

> >> >> +         * MATH-803: it is not sufficient to loop through non
zero entries of
> >> >> +         * this only. Indeed, if this[i] = 0d and v[i] = 0d, then
> >> >> +         * this[i] / v[i] = NaN, and not 0d.
> >> >> +         */
> >> >> +        final int n = getDimension();
> >> >> +        for (int i = 0; i < n; i++) {
> >> >> +            res.setEntry(i, this.getEntry(i) / v.getEntry(i));
> >> >>          }
> >> >>          return res;
> >> >>      }
> >> >
> >> > I think that this renders the class potentially useless, if we assume that
> >> > it is used when "large" vectors are needed.
> >> > Indeed, after this operation, all the entries will be stored; thus
> >> > cancelling the memory efficiency of the class, and probably making the
> >> > returned value slower than an "ArrayRealVector" instance for subsequent
> >> > operations.
> >> >
> >> I'm not sure that all entries would be stored (except if setEntry does
> >> not distinguish between zero values and non-zero values).
> >
> > The problem is when the common values are not the default one, like ...
> >
> >>
> >> > For every method that a "RealVector" argument, there should be a specialized
> >> > implementation that take an "OpenMapRealVector".
> >> >
> >> > Also, couldn't we solve some of these problems if the value of the default
> >> > entry was stored and mutable? E.g. if the default for "v" and "w" is zero,
> >> > then the default for "v / w" will be "NaN".
> >
> > ... in this example.
> >
> Ooops, missed this one!
> Yes that was an improvement I was thinking of (in fact, the unit tests
> are already implemented with this idea in mind).
>  This would allow efficient implementation of the cosine for example.
> I didn't think about the application you suggest, but I like this idea
> very much.
> 
> How about we leave it as is for the time being, and we open a JIRA
> ticket for this improvement, explicitely mentioning that ebeDivide()
> and ebeMultiply() should be revisited in order to improve their
> efficiency?

I agree.

> 
> This does not solve the whole issue, however, because if the default
> entry is zero, its sign is lost, and {finite value} / {zero} is of
> undetermined sign. Any idea regarding this point?

I guess that we could also keep a flag for the sign.

Best regards,
Gilles

P.S. Maybe that we should also have a look at how other libraries handle
     this kind of issues.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message