Edge case conversions, exceptions to IEEE FPA
On (Mon, 17 Nov 2008 13:31:27 +0100) Sylvain Pion wrote:
> I am a bit reluctant to rely on a property of IEEE754 NaNs which is new
> to me, probably not used a lot, and which may have some portability issues
Yes, that concern is justified. But IA is new ground, and if 754-20xx
ever gets an official IA-friendly attribute (e.g. to modify the rules
for directed rounding), it could at the same time tighten rules for NaN
definition and propagation. 754-2008 had to remain compatible with the
previous 754-1985 in cases where different existing implementations would
otherwise have become non-compliant. For DFP the rules are somewhat more
precise -- but not much, unfortunately. (Finishing the standard was a
much higher priority!)
> Further thinking about this, I am now of the opinion that
> intval(1e309) = Empty is not safe enough.
Indeed, Empty is NOT propagated by convexHull, and probably not by max
and min either (as these are supposedly defined in terms of IEEE 754-2008
maxNum and minNum, which ignore NaNs), so that max(xx, EMpty) would be xx.
> I would definitely prefer it to return Entire.
Perhaps we should explore this alternative more -- as well as NaI. Should
there be several versions of floatToInterval (Arnold already introduced
the realHull(x,x) alternative to his Interval(x) for float x), or one
version with a second conversion-type operand?
Note that NaI does not invalidate the position that IA is exception-free,
because it can only appear at the edge of IA, and (unlike Empty) would
have to be guaranteed to propagate, so that deferred error detection can
be reliable.
Of course, having both Empty and NaI raises issues of efficient encoding,
by which I mean the ability to implement IA operations without too many
case distinctions on common paths.
Michel.
Sent: 2008-11-17 15:53:39 UTC