Hello Gilles,
2012/6/11 Gilles Sadowski <gil...@harfang.homelinux.org>:
> Hello Sébastien.
>
>> >> + /*
>> >> + * 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?
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?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
