commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: svn commit: r1348721 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/linear/ test/java/org/apache/commons/math3/linear/
Date Sat, 16 Jun 2012 18:13:20 GMT
Hi Gilles,
and thanks for your time spent on this issue!

2012/6/16 Gilles Sadowski <>:
>> [...]
>> >>
>> >> > Maybe that we could also impose that it is forbidden to divide by a
>> >> > vector whose default value is zero. This will avoid a check on all
>> >> > (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!


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message