Users for Language Independent Arithmetic Standard?

[David Hough]

ISO/IEC CD 10967-1:1992 is the latest draft of the first part of a
international standard for language independent arithmetic.    It is
the descendant of what used to be called LCAS.

Much has changed since the earliest drafts, but one thing hasn't
changed and it still puzzles me.    The puzzling question can be put in
this form:

> Among providers of mathematical software reading this message, who
> anticipates a valuable economic benefit from a framework which allows
> certain kinds of software to be written that is usefully portable among
> IEEE 754, VAX, and 370 floating-point architectures, but not to any
> Cray supercomputer?

In other words, how much new mathematical software is likely to be
written that gains much value from portability to VAX and 370 but not
Cray?  (Note that other firms besides DEC implement VAX and others than
IBM implement 370, sometimes missing the fine points.)

Note that even the "certain kinds of software" that can be so portable
are limited to software that won't trip over the 370 hex arithmetic or
the relatively small exponent ranges of the usual 370 and VAX
double-precision formats.    So such software has to be coded
defensively against these possibilities among others.

My suspicion is that there isn't any vast amount of such software
waiting to be written.   The percentage of all FLOPS that are being
executed on VAX and 370 architectures has been dropping steadily, as
has been implicitly recognized by DEC and IBM in their relatively
abrupt refocusing on ALPHA and RS/6000 respectively for the scientific
computation market.

New software applications that will be written for VMS-VAX and VS-370
will probably depend on a lot more than LIA will standardize, relating
to the non-numeric parts of the problems they solve, and at least for
C, all that's needed is two predefined macros

	__VMSVAX__
	__VS370__

(VS is IBM's current mainframe operating system, isn't it?  I lost
track years ago.)

This is not to say that these architectures will not continue to be
important for other application areas than scientific computation, but
LIA won't do much for portability in those other arenas.

Aside from these two, any other important future general-purpose
non-IEEE scientific computation platforms are likely to be, at least
spiritually, "sons of Cray", that sacrifice roundoff and exception
predictability, (even if their storage format is IEEE)
for better performance on the huge classical simulation
problems that can get along without them.  Current Cray supercomputers
fall short of LIA's requirements in the areas of subtraction,
multiplication, and division, I believe, and changing their code
generation to conform to LIA would probably eliminate their
cost-effectiveness relative to less expensive and less powerful
systems.   If you are porting commercial software to a Cray or similar
system, you are going to want it to win big against mini-supers and
workstations, so I think you will invest in the engineering effort to
get along with the native arithmetic.

LIA only applies to conventional scaled-integer floating-point
arithmetic, so it won't help in porting to proposed new methods like
logarithmic representations, rational arithmetic, variable-exponent
representations, etc.  Nor does LIA mandate anything to improve the
general availability of interval arithmetic, which is the most likely
candidate to actually overcome the major reliability problem in
scientific computing, which is roundoff error.

The foregoing comments apply to one aspect of LIA, which is a
specification for computer arithmetic, which is too loose to do much
good on PC's and workstations, which are almost all IEEE, and too tight
to do much good on mainframes.  Another aspect is that it intends to
define a mapping between language features and arithmetic standard
features and a paradigm for documenting the mapping.    This aspect is
potentially more useful because IEEE 754 didn't do it - that was a
wise decision at the time, for it would have delayed publication of 754
for years, and we might have bound to Pascal and Fortran-66 by
mistake.   It might be better for languages to define the mapping to
IEEE 754, as NCEG is doing for C, but that generally isn't happening,
so maybe a standard of language bindings for IEEE 754 is the way to
go.  Some of the LIA work might even be usable for that purpose.
But I'd be more inclined to "port" NCEG's IEEE bindings to other languages.

So returning to my original question, I'd appreciate hearing from 
commercial software developers who anticipate a significant benefit if 
LIA were adopted in its present form.