Hello,
2012/6/16 Sébastien Brisard <sebastien.bris...@m4x.org>:
> 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
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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
