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 Tue, 12 Jun 2012 18:26:50 GMT
Hello Gilles,

> [...]
>> I fully agree. We could also opt for a less correct, but more
>> efficient solution: we do not store the sign of zero, and return NaN
>> each time v / zero occurs. The result should be NaN anyway, because
>> its sign is undecidable. This specificity would be clearly stated in
>> the javadoc. What do you think?
> We had this sort of discussion with the "Complex" class, where there are
> such issues as "standard" vs "correct" vs "documented" etc. E.g. some
> computations return "NaN" where it should be "infinity" (or vice-versa, I
> don't remember exactly). See MATH-667:
> Maybe that we must be guided with some use-cases for this class.
> Maybe in actual uses, the problems discussed here do not appear, and any
> additional check would destroy the usefulness of this class in such cases
> (just a wild guess). Maybe that we should drop support for sparse vectors!
I fully agree with you. Speaking quite honestly as a user of the
linear package, even if I know that IEEE floats handle infinite values
well, I tend to dish results that contain those values, and try to
cure the cause of these unwanted values. So, as a user, whether the
method returns NaN of infinity does not matter to me (as long as it
does not return zero --or any normal value-- quietly): in any case, I
would do a computation again, this time with "correct" values.

I also think that in this case, strict adherence to IEEE standards
(which were written for scalar values, not vectors) should not
compromise the performance of the class.

I would be more cautious with your suggestion about getting rid of
sparse vectors. I think it's nice to have them, even if the support is
limited (we should of course concentrate on array-based vectors
first). As long as we clearly document these limits, I'd like to keep
them. Besides, with the new set of abstract tests being constructed
for any vector class, it should be possible in the future to propose
and test a better implementation. The problem we have is clearly lack
of feedback on these features (remember the debates we had on the
"sparseIterators"-- not perfect, but experience only can tell how to

Best regards,


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

View raw message