commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Performance optimization in the vector classes
Date Mon, 02 Nov 2009 21:29:34 GMT
Jake Mannix a écrit :
> On Mon, Nov 2, 2009 at 9:05 AM, Jake Mannix <> wrote:
>>> Also, why the special case for
>>>> ArithmeticExcption here, for the zero norm case?  Why not just let
>>>> java just
>>>> try to divide, and if it divides by zero, well, it'll throw an
>>>> ArithmeticException itself...  seems like the whole method should just
>>>> be
>>>> implemented as " return mapDivide(norm()); "
>>> No. A division by zero does not lead to ArithmeticException when dealing
>>> with double variables, it leads to a NaN being produced. ArithmeticException
>>> is triggered when an integer division by zero occurs.
>> Duh of course, right.
> So about this, actually... it seems that this is not done consistently
> throughout the vector classes - mapDivide could divide by zero, but does not
> explicitly throw ArithmeticException, so why does unitVector() ?

Because I am inconsistent with myself :-)
Well, unitVector comes from an old former implementation, in a previous
library that was written years ago and partly merged into commons-math
in 2007 (merging is not completed yet). Now, after more than 20 years
working in the science/computation/simulation/space/numerical analysis
field I finally trust IEEE754 and how it is implemented in modern
languages and processors. So I changed my mind and now let NaN occurs
automatically and do not check each and every division, just as I don't
check each square root for negative arguments or arc sines for arguments
 out of [-1; 1]. One drawback is that when a NaN occurs, you don't know
exactly where it started. You usually see a bunch of NaNs in the output
and have to reproduce the problem with a debugger to understand what
happened. If you explicitly checks an operation and throws an exception,
you immediately knows where it is triggered, but the drawback of this
choice is that code is slower (lots of tests and branching) and
difficult to read and maintain.

So the trade-off is to check only some important operations, and to let
other operations unchecked. There is no simple absolute solution, it is
only a compromise and depending on the mood of the day one specific
operation may be protected or not.

I feel unitVector is worth being checked and mapDivide is not, but it's
only one person's feelings.

> Similarly, projection doesn't bother to check if you're projecting onto the
> zero vector, and would end up with a vector of NaN which is just what
> unitVector() is avoiding.
> It actually looks like the isNaN() and isInfinite() methods aren't used
> anywhere except in unit tests.  Does this mean that they are not checked in
> any of the solvers?

I don't think they are used in solvers.
They will probably be used in eigen decomposition soon because one bug
recently raised should probably be handled with it.


>   -jake

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

View raw message