commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <jake.man...@gmail.com>
Subject Re: [math] Performance optimization in the vector classes
Date Mon, 02 Nov 2009 22:11:52 GMT
Er, there already is, right?  RealVector#isNaN() and RealVector#isInfinite()
- they're
just not used anywhere except for as verification purposes in the unit
tests.  No
actual internal use as of yet.

  -jake

On Mon, Nov 2, 2009 at 1:58 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> This makes me think that we need to have containsNan and containsInfinite
> methods on vectors and matrices so that it is easy to check.
>
> On Mon, Nov 2, 2009 at 1:46 PM, Jake Mannix <jake.mannix@gmail.com> wrote:
>
> > ... Yeah, in my own libraries, I tend to say that either don't force
> checks
> >  ever 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
> > runtime
> > exception, as should FunctionEvaluationException when calling
> > UnivariateRealFunction.
> >
> >  -jake
> >
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>

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