Hi Gilles,
and thanks for your time spent on this issue!
2012/6/16 Gilles Sadowski <gil...@harfang.homelinux.org>:
>> [...]
>>
>> >>
>> >> > Maybe that we could also impose that it is forbidden to divide by a
>> >> > sparse
>> >> > vector whose default value is zero. This will avoid a check on all
>> >> > entries
>> >> > (at the expense of forbidding legitimate divisions, when all the entries
>> >> > have a non-default value; but then one would wonder why using a sparse
>> >> > vector...).
>> >
>> > [...]
>>
>> Gilles, I have the feeling that your prefered option is to store the
>> sign of the default value.
>
> Not really; if there are no obvious drawbacks, I'd prefer the above option.
> I.e. something like
>
> public OpenMapRealVector ebeDivide(OpenMapRealVector v) {
> if (v.getDefaultEntry() == 0) {
> throw new ZeroException();
> }
>
> // ...
> }
>
>> In theory, that would solve the problem. I
>> see two objections
>> 1. sparse vectors would be less sparse (most users do not care about
>> the sign of the zero entries!)
>
> I agree; division by zero is in most (all?) cases a bug. So thoses users
> won't care about the above solution (or will be happy that their code fails
> early instead of propagating NaNs).
>
Yes, I think it's a good point (I would be glad if *any* calculation
could be stored when NaNs occured...).
What I can do is add some details in the javadoc, stating that we
opted for the exception option for robustness reasons, which leads to
less efficient code. I can suggest to use visitors if a more efficient
(and fragile !) solution is seeked.
>> 2. there is a threshold to decided whether or not an entry is actually
>> zero. So the current implementation already assumes the sign is lost.
>
> That's why the unit test fails. I think that it is more robust to make it
> explicit (by throwing an exception) that division by zero is not supported.
>
>> I'm really confused about the best solution to adopt.
>
> So am I.
> But my preference is to be more robust even if less efficient and not
> supporting corner cases.
>
I will implement the exception option, and alter the unit tests accordingly.
Best regards, and thanks again for your help on this issue. That was
an interesting discussion!
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
