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 <[email protected]> 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
