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.dunn...@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.man...@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 >
