LIA comments

[Fred Tydeman]

Date: January 3, 1994
 
To:   X3 Secretariat
      Attn.: Deborah J. Greco
      1250 Eye Street, NW
      Suite 200
      Washington, DC 20005, USA
 
cc:   American National Standards Institute
      Attn.: BSR Center
      11 West 42nd St, 13th Floor
      New York, NY 10036, USA
 
cc:   John Sharp
      X3T2 Chair
      Sandia National Laboratories
      P. O. Box 5800, Org. 4400
      Albuquerque, NM  87185, USA
 
cc:   Craig Schaffert
      LIA Editor
      Digital Equipment Corporation
      Cambridge Research Lab
      One Kendall Square, Bldg 700
      Cambridge, MA 02139, USA
      schaffertacrl.dec.com
 
From: Fred Tydeman
      3711 Del Robles Road
      Austin, Texas 78727-1814, USA
      (512) 838-3322
      tydemanaibmpa.awdpa.ibm.com
 
Re:   ISO/IEC DIS 10967-1:1993
      Language Independent Arithmetic (LIA) --
      Part 1:  Integer and floating point arithmetic.
      JTC1/SC22/WG11 N364R, August 4, 1993, version 4.1.
 
I have several comments on LIA.
 
Page vi, Introduction, The aims.
Page 61, Annex B, Partial conformity.
"These semantics need to be precise enough for numerical analysis, but
not so restrictive as to prevent efficient implementation of the
language on a wide range of platforms."  Testing for integer overflow, a
requirement of LIA, cannot be done efficiently on many processors.  In
particular, the Intel 80*86 family, the most popular architecture of all
computers, requires additional code after each and every signed
arithmetic operation to detect overflow.  This makes the code both
larger and slower.  So, I disagree that the LIA can be implemented
efficiently on a wide range of platforms.  I would like to see testing
for integer overflow be optional.  Add a behavioral parameter, such as
int_overflow, that can be true or false, similar to iec_559.
 
Page 2, 1.2 Specifications not within the scope of this standard
Consider adding two more data types after item e).
f) A so called "doubled precision" (sum of two regular floating-point
numbers, each with fixed precision p) data type, or the operations on
such data.  This standard neither requires nor excludes such data or
operations.
g) A logarithmic data type, or the operations on such data.  This
standard neither requires nor excludes such data or operations.
 
Page 3, Conformity
Page 46, Conformity to IEC 559
Page 66, E Bindings for specific languages
In several places, statements are made that "A complete binding for the
LIA-1 will include a binding for IEC 559."  It seems to me that more
words to be added to distinguish language binding from implementation.
It seems to me that all the languages will have bindings to IEC 559, but
that only those implementations where iec_559 is true will actually
provide the facilities.  The languages need to provide a standard way to
access the facilities, so that if the facilities are provided, they can
be used.  By similar reasoning, all the optional parts of IEC 559 should
be standardized by the LIA binding for each language, but be optional
for each implementation.  Then, there must be additional (beyond
iec_559) flags that the programmer can test to see which optional
facilities are present in a given implementation.
 
Page 10, 5.2 Floating point types.
Page 36, A.5.2 Floating point types.
Change "five parameters" to "five constant parameters".
I assume that the precision p, as well as the other four parameters,
are constants.
 
Page 11, 5.2 Floating point types.
"More stringent conditions are needed to produce a computationally
useful floating point type."  Those conditions should be listed, even if
they are only 'should' instead of 'shall'.  Implementations should be
required to document which types are and are not computationally useful.
 
Page 18, 5.2.9 Conformity to IEC 559.
Remove "extended comparisons," in the first NOTE as they are an optional
feature of IEEE-754 so should not be mentioned here.  Someone might
believe that they are required and that languages supporting LIA and
IEEE-754 will have to have all 26 comparison operators.
 
Page 19, 5.3 Conversion operations
For integer to integer conversion, cvtIa->Ib, change "integer_overflow
if x not element Ib" to two cases similar to addI(x,y).  That is,
have one case for the target type has modulo true and a second case for
the target type has modulo false.  Then the conversion of a signed int -1
to an unsigned int will be taken care of without integer overflow.
 
Page 19, 5.3 Conversion operations
Change "Let nearestx be a helper rounding function from R to X
satisfying the round to nearest property."  to "Let nearestx be a helper
rounding function from R to X."
 
Page 20, 6 Notification
Consider adding a NOTE that LIA does not address client-server paradigms
or programs that never terminate.
 
Page 30, A.2.1 Validation
Consider adding a process for validation conformity.  A standard that
cannot be validated seems to be weak.
 
Page 58, A.7 Relationship with language standards
What is LIA's stand on sin(fmax)?  Must it return the correct answer?
If it cannot compute the correct answer, must it notify, say via
undefined?
 
Page 63, Annex C
Change "This means that a complete programming language binding for
LIA-1 should provide a binding for all IEC 559 facilities as well."  to
"This means that a complete programming language binding for LIA-1
should provide a binding for all required and optional IEC 559
facilities as well.".
 
Pages 63-64, C.1 Summary
Options f), g), and h) (optional in IEC 559) should be under a new
phrase:  "The binding shall and the implementation should provide the
notation for invoking each of the following operations:"  and renumbered
to a), b), and c).
 
Page 64, C.1 Summary
Options c) and d) (optional in IEC 559) should be under a new phrase:
"The binding shall and the implementation should provide the ability to
read and write the following components of the floating point
environment (modes or flags):"  and renumbered to a) and b).
 
Page 75, E.4 C
Change the discussion on cast operators being used as conversion
operators.  Leave the existing C casts with their more general rounding
requirements alone.  Add new functions for conversions with round to
nearest semantics.
 
Page 83, E.6 Fortran
In the NOTE, remove the "77" from "Fortran 77".
 
Page 97, H Bibliography
The following could be added:
Seppo Linnainmaa, Software for Doubled-Precision Floating-Point
Computations, ACM Transactions on Mathematical Software, Vol. 7, No. 3,
September 1981, Pages 272-283.
 
These are not IBM's views, these are the personal ones of:
Fred Tydeman, IBM, Austin, Texas (512) 838-3322; fax (512) 838-3484
AIX S/6000 Math library architect & IBM's rep to NCEG (X3J11.1)
Internet: tydemanaibmpa.awdpa.ibm.com    uucp: uunet!ibmsupt!tydeman