Re: Mixed radix arithmetic

["Ivan Godard" <igodard@xxxxxxxxxxx>]

----- Original Message -----
From: "Joe Darcy" <Joe.Darcy@xxxxxxx>
To: <dan@xxxxxxxxx>; <igodard@xxxxxxxxxxx>
Cc: <stds-754@xxxxxxxx>
Sent: Thursday, March 27, 2003 3:48 PM
Subject: Re: Mixed radix arithmetic


\> >> 4) There should be a defined union set of NaNs, so that all NaNs are
> >> representable in either radix implementation, whether they can be
created in
> >> the native radix or not.
> >
> > The radix of a Not a Number.  An interesting concept, that.
> >
> > I believe I will disagree that this is necessary in any
> > meaningful way but bring it up at the next meeting.
> >
> > After all, I may be wrong.
>
> Preserving NaN bits through various conversions strikes me as more of a
quality
> of implementation issue rather than a spec issue since we have not
imparted any
> semantics to NaN bits other than a signaling/quiet distinction.
>
> -Joe
>

I feel that the bare minimum for NaN usability (QNaN that is) is that the
NaN should retain an indicator of the kind of condition which created it
(overflow, divzero, etc.) and that this indication should be preserved
through any subsequent operation including conversions. The indication
should be drawn from a Standard-define enumeration, which should include
entries for "not implemented", "unitialized", and one or more "other
implementation specific". As the possible causes may differ between the
radices, I think the enumeration should represent the union of the
conditions, so that the indication will survive radix conversion. In this
sense, that a NaN encodes a condition which may indicate the radix that
obtained when the condition occurred, yes, a Not a Number can have a radix,
despite Dan's amusement.

Note that this is a utility issue, not a correctness or performance issue.
The bulk of actual user interaction with NaNs will be in the context of a
debugger, and anything that can be done to make them less terrifying is a
Good Thing.

Ivan