Hello,
2012/6/11 Gilles Sadowski <gil...@harfang.homelinux.org>:
> 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.
>
Do you mean that the default value would be +0 or -0, in some zero
entries would be stored? Or do you mean to store the sign of each zero
entry, which is slightly less efficient than the present
implementation, but would work OK? These signs could be stored in very
compact form (as bits), as they need only seldom be retrieved.
>
> Best regards,
> Gilles
>
> P.S. Maybe that we should also have a look at how other libraries handle
> this kind of issues.
>
Thanks for the suggestion, I will have a look.
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
