| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
On Nov 2 2010, Dan Zuras Intervals wrote:
Date: Tue, 2 Nov 2010 09:53:39 +0100 From: Vincent Lefevre <vincent@xxxxxxxxxx> I think you should forget this analogy, because it is incorrect. For instance, hypot(+inf,qNaN) gives +inf, not qNaN (Section 9.2.1).You are also correct in that there will be some minor exceptions. Some hypot cases are one. Some selection functions are another. ...
It should be pointed out that, given the approach to NaNs used in IEEE 754 and followers, that is mathematically inconsistent, and is widely regarded as a serious error. The point is that selecting the 'not a number' semantics in a patchwork fashion necessarily leads to circumstances under which an error state will get quietly lost, and replaced by a nonsensical but 'valid' value. hypot(+inf,qNaN) should be +inf ONLY if NaNs are interpreted as 'any valid value between -inf and +inf'. If they represent a genuine 'this is not a number' (including the result of a calculation that is not representable in the selected mathematical domain), then the result should be a qNaN. Regards, Nick Maclaren.