commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <>
Subject Re: [math] Performance optimization in the vector classes
Date Mon, 02 Nov 2009 21:46:48 GMT
On Mon, Nov 2, 2009 at 1:29 PM, Luc Maisonobe <> wrote:

> 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.

Yeah, in my own libraries, I tend to say that either don't force checks
and at most throw unchecked exceptions that people can choose to only
catch at the top level (if at all, if they consider it a "fatal" bug then
they can
crash if they want to), or else if they've got ways of dealing with NaN/Inf,
they can explicitly catch the runtime exception.

The other alternative is, as you say, to throw the exceptions on method
calls which *aren't* in an inner loop.  But then I'd say that unitVector()
falls into the same category with mapXXX and ebeXXX - before doing
the O(n) loop, do one check at the beginning for NaN/Inf on the doubles
and isNaN or isInf on the vectors, and throw a MathException at this
point if that's the contract.  Of course, I still think this should be a
exception, as should FunctionEvaluationException when calling


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message