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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org