commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: svn commit: r1348721 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math3/linear/OpenMapRealVector.java test/java/org/apache/commons/math3/linear/SparseRealVectorTest.java
Date Mon, 18 Jun 2012 05:37:04 GMT
Hello,

2012/6/16 Sébastien Brisard <sebastien.brisard@m4x.org>:
> Hi Gilles,
> and thanks for your time spent on this issue!
>
> 2012/6/16 Gilles Sadowski <gilles@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

well, I was hoping that we could close this issue, but I have realized
that the problem is more wide-spread. Because the subject of this
thread is not very explicit, I'm afraid not everyone is aware of these
discussions. I'll create a new thread.

Amitiés,
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message