Re: convertFormat and signaling NaN
Date: Mon, 14 Mar 2011 00:22:03 +0100
From: Vincent Lefevre <vincent@xxxxxxxxxx>
Subject: convertFormat and signaling NaN
The convertFormat operation is under 5.4 (formatOf general-computational
operations), so that, according to 6.2, a signaling NaN shall signal the
invalid operation exception.
convertFormat doesn't preclude formatOf being the same format as source.
And the standard doesn't say that the behavior on signaling NaN should
So, what should the typical bindings be for casts and assignments in C,
assuming an implementation seeks to fully support the IEEE 754 standard?
double y, z;
/* ... */
z = (double) x; /* (1) */
z = (double) y; /* (2) */
z = y; /* (3) */
. . .
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
While it is true that convertFormat doesn't preclude
formatOf being the same format as source, it is also
true that it does not include it.
And, as 754 generally interprets an assignment as an
instance of a copy (with no exceptions) I would be
happy with either interpretation on the grounds that
the case is outside the stricts bounds of the
specifications of the standard. Or on the grounds
that it is up to the language how to map that syntax
onto 754 semantics.
Further, is it not in keeping with the character
of C that syntax that leads to null operations are
permitted to be interpreted as removed? Thus,
-(-x) == x, or -(x - y) == y - x, et al.
So, I would think that it would be in keeping with
that C notion that a null conversion be interpreted
as nothing more serious than a copy.
Still, I think you are free roll your own in this
case & face no criticism on 754 grounds.
IMHO, of course.