From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2006-05-17 04:26:45
> My basis for citing this is page 122 of "The C++ Progamming Language"
> by Stroustrup, copyright 2000, reprinted May 2003 with corrections.
> It says, "In particular, underflow, overflow and division by zero do
> throw standard exceptions". If that's wrong, incomplete or out
> of date, I would be curious to know about it. It seems to comport
> with my personal experience with C++ numeric operations. Feel free
> to expand upon this.
C++PL is not the standard. A conforming implementation could throw a
standard exception on divide-by-zero (although I don't think any
> The kind of situation I'm thinking of is more like the following.
> I've got
> a program which among its operations is a matrix inversion. The
> correctly implements the chosen algorithm. Now I load a near-singular
> matrix and invoke the matrix inversion operation. The sequence of
> operatons results in over/under flows in some intermediate results.
Nit: underflow usually results in zero, overflow in Inf. Neither of
these are NaN. On the other hand, 0/0 and Inf/Inf _are_ NaN.
> No exception
> is thrown but some NaN's are propagated through the calculations. The
> final result Matrix may or may not have one or many Nan's. So now I
> have a result that is wrong but do not know it and have no way of
Given that NaNs are very persistant, if you generated NaNs in your
intermediate calculations, then there will be NaNs in your inverted
You can know it, by looking for those NaNs.
Of course that won't work on implementations which don't support quiet
NaNs (or don't generate them for eg 0/0), but if your implementation
happens to be one which /does/, why would you care?
> In FORTRAN this was never a problem as the program aborts at the
> first overflow/underflow or whatever.
Really? Can you point to the standard requirement for this. It may
well be true for the implementation you were using, but I would be
surprised if the standard required it (but I could be wrong).
> What am I expected to do here? I could recode the matrix inversion to
> check each intermediate result to see if its a NaN? I can't imagine
> that's what I'm expected to do. How do people handle this now?
Matrix inversion algorithms usually include checks for detecting
-- Martin Bonner Martin.Bonner_at_[hidden] Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk