Re: No on Motion P1788/M007.01_NaI
Are we standardizing interval computations at the language
level, are we standardizing the underlying arithmetic operations,
or are we standardizing the arithmetic and specifying bindings
to languages? It seems that, depending on the answer to this,
asking whether a datum is initialized or not may or may not
be within the scope of our discussion.
Sincerely,
Baker
Hossam A. H. Fahmy wrote:
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
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------