Dear 1788 members,
My vote is NO on motion 7.
I do not want a unique NaI and would vote yes if the motion allowed multiple **well defined** ones (represented as we might decide later either as decorated empty intervals or specific NaI with payloads or whatever).
My reasons are due to my position as a professor teaching hardware implementations of computer arithmetic (integer and floating point, I am still learning IA from all of you). Arithmetic on computers is different from the one a human does on paper. A computer is faced with some challenges that we need to address in our standard. For example, the following trivial code sample
interval xx;
yy = xx + [1,3];
uses xx without initializing it. This might be acceptable in a declarative language that will keep moving through the program till it finds a value for either yy or xx and derive one from the other. However, for an imperative language this code is problematic. I argue that in our standard, we must specify a "non-initialized" datum for xx till it is really initialized by the programmer. If such a "non-initialized" datum is used in a calculation, the standard should specify how the system (whether done in hardware or SW) will handle this case. A human doing interval arithmetic on paper will not face this problem, but a computer does.
This "non-initialized" datum is different from the "invalid construction" datum proposed as the unique NaI. Both are different from what we might decide to define for a piece of HW to return if the user insists on giving it something like [3,8]/[0,0] which is a different kind of invalid operation. Note that the HW must give some answer to **every** possible bit pattern. We either specify that answer in our standard or we must live with varying implementations later on.
In IEEE754-1985 these different uses were all under the NaN umbrella possibly with different payloads but the payloads were not specified, so the differentiantion was not consistently implemented, and hence not reliable for use. IEEE754-2008 had to inherit this behavior. I prefer that in 1788 we think about the different alternatives and let the standard mature a little bit before we make a decision to have a unique NaI, follow what 754 did (to allow payloads but not specify them), or to allow a well defined set of NaI and leave some room for implementations to define yet extra ones if we deem so (I prefer this latter approach although it is really a big headache for implementers such as myself).
Just my 2 cents.
If I made any mistakes in the above, please correct me so that I can teach my students better :)
--
Hossam A. H. Fahmy
Assistant Professor
Electronics and Communications Department
Cairo University
Egypt