Copy of comments on LIA

[Keith Bierman fpgoup]

What follows is an ascii version of the comments I am mailing today to
ANSI. 

I will happily supply anyone interested with postscript of the precise
text sent in for formal processing.

cheers,

	khb

To: Distribution

Subject: Comments on LIA-1


To put my comments in perspective, a few words about my background.

I spent several years in the aerospace industry, working on a variety
of Estimation applications. One of my background duties was to port
our library from platform to platform. We had applications running on
everything from CDC 6600's to Zilog Z80's. Since that time, I have
worked for computer vendors, typically in groups closely associated
with compiler development. I have been involved with Fortran standards
development, and am currently a member of X3J3, WG5, and X3H5. I
attended the original HPF meeting; but a colleague took over tracking
their day- to-day work for me.



Thus I look at this proposal from three perspectives: as a user/author
of portable numeric codes, as a vendor of compiler products, and as a
member of standards bodies likely to be affected by this proposal.



LIA, as it is currently focused, is not useful to me (indeed appears
harmful) in any of my capacities.

In the discussion that follows, page citations are from the second
committee draft unless otherwise labeled.

Page v

"The first goal of this International Standard is to enhance the
portability of nu- meric programs...."

Perhaps a definition of portable would make it more clear what the
committee has in mind.

As a library writer and a language vendor I have often been faced with
someone who was confused about the results of a computation. Even when
computing on machines with "identical arithmetic" (e.g. two runs on
the same machine with and without optimization, with and without
floating point hardware or two im- plementations of IEEE 754). At the
end of the analysis, it proves to be something subtle. The user is not
satisfied, and one resorts to pointing at the language stan- dard. In
the case of most (certainly the case for Fortran, all three versions
of the standard) there is simply no assurance that

 2.0+3.0 = anything close to 5.0

I would have hoped that the fundamental task of a language independent
floating point standard would be to establish a foundation for all ISO
programming lan- guage standards to bind to. The effect of such a
binding would be to provide a useful and meaningful significance to
expressions such as

	 2.0+3.0

As it happens, there is such an international standard. Two of them to
be precise: IEEE 754 and IEEE 854. Henceforth in this missive, "IEEE"
should be read as IEEE 754 and 854 arithmetic standards.

A firm directive from ISO to all language standards bodies to provide
a binding to IEEE where available would suit my needs admirably. It
should be noted that Common LISP and X3J11.1 are, in fact, pursuing
this path already.

Objection	1

	LIA has a poorly defined goal as its primary mission; I prefer
a different primary goal. I believe my experience represents that of a
large user community, and of a large vendor community.


Objection	2

	With an appropriate goal, there exists a better solution which
is already a standard.

Given that portability is defined in the usual common sense fashion, that is:

 	A code is portable if it can be moved, recompiled easily onto
	another platform and when presented with the same input
	produces reasonably similar output.


LIA, as it stands is not helpful. 

In the POSIX, ANSI (X3H5 as an example), and I thought the ISO
universes, it has become the modus operandi to have a "model" and
"bindings".

In order for the common sense portability situation to be improved, we
need bindings not another model.


Objection	3

LIA is providing a substitute for the "model" (which IEEE provides)
and doing nothing to solve the remaining problem which is bindings to
the model. 

The claim that "bindings are beyond the scope of "is specious.
X3T2 (or its ISO counterpart) could propose to provide such bindings
(as X3H5 is doing for X3J3) or X3 could direct the various
X3J* bodies to do so, based on X3T2 recommendations (in the ANSI
world). Similarly SC22 could direct the various WG* groups working
on ISO programming languages. Presumably WG11 members would
spearhead the effort, and the various language working groups would
meet with them 	and etc.

page vii

 Description of why a descriptive standard is required; essentially to
accommo- date a variety of architectures.


If we were to assume that SC22 and X3 were to direct all their
subgroups to bind to some language independent standard today it would
require at least 5 years, and more likely 10 years for all of the
subgroups to be able to comply.


I derive this figure from the fact that language standards are seldom
(if ever) re- vised in less than five years. Since some of the
languages will be too far along in their current processing to
accommodate substantive changes without "slipping their schedules" I
conclude that the earliest any language could comply would be two
years, and the latest infinite time (e.g. the PL/1 committee no longer
meets, so I'm told).

Moreover, it usually takes some time for vendors to update their
compilers and some time for users to update their codes to take
advantage of new language fea- tures.

Thus to determine how useful a language independent model is likely to
be, we must look at the face of computing at least 8 years from now,
not 10 years ago.

Today there are more than 100 million IEEE machines. Virtually all new
machines from all vendors are IEEE or at worst, IEEE-like. This
includes hardware from IBM, DEC, HP, CRI, Sun, Intel, and Apple to
name but a few.

Improving code portability between IEEE machines would solve a great
deal of problems for the vast majority of computer users.

By trying to solve portability problems for machines which will
comprise but a few percent of the worlds computing resources is ill
advised unless it can be done at virtually no cost, and without
compromising on the quality of support for the many.

Objection	4

	LIA has focused on attempting to solve portability problems
	for the 10% not the 90%.


It has been counter-argued that IEEE is not the end all be-all of
computing arith- metic schemes. New ones shall arise, old ones (e.g.
interval arithmetic) may final- ly catch on.


This is why the direction chosen by Common LISP and X3J11.1 is the
correct one.  That is to define (in the context of each language) what
must happen in the pres- ence of IEEE arithmetic and fall back on the
usual verbiage for systems which are not IEEE. If some other scheme
eventually supplants IEEE in a few decades, it will not be hard to
alter the standards accordingly (changing everyone's codes will be
much harder).


It should be noted that if one does which to solve the problems of the
past, LIA has failed. By excluding Cray, the most popular
Supercomputers in the world.  While it is, of course, the case that
supercomputers are a small minority of com- puting, much if not most
mathematical software has them as a target. Since LIA is most useful
to those doing numerically intensive floating point applications, this
is a fatal shortcoming, if one is aiming at the past.

Newer machines from CRI (such as from their CRS division) are IEEE
based.  Their MPP machines (not shipping yet) are too. So if one looks
forward, IEEE han- dles this strata of computing.

LIA is focused about describing arithmetic; presumably so numerical
analysts can reason about implementations of known good algorithms.
Alas, the fraction of people who do numerical programming who are
numerical analysts is small. In- deed, even most application authors
who are numerical analysts do not always invest their time doing such
analyses.

Objection	5

So just as LIA addresses a minority of computing systems, it focuses
on a small minority of programmers!


page 1

 Scope: "...defines the properties of integer and floating point data
	types on... can be undertaken in a reliable and predictable
	manner"

If the basic goal is to improve portability of applications, it should
be stated here. When reading a standard, I expect the Goals and the
Scope to be conformant; there they appear to be unrelated!


page 2

 "exclusion of mixed mode"

Since most popular programming languages include this it is
unfortunate that the model neglects to cover it. Just as the model
ought to be designed with consider- ation given to the underlying
arithmetic/hardware it ought to consider the needs of the languages
which need to bind to it.


 "exclusion of interval arithmetic"

Presumably a reason for not basing this work on IEEE is to allow for
new useful, non-IEEE arithmetics to be more readily adopted. Interval
arithmetic is then a major omission.

 "exclusion of infinite and non-numeric values..."

One of the most useful things on the early CDC machines was the
ability to ini- tialize memory with "NaNs" and thus find bounds
problems. Similarly, one of the best features of IEEE are these
values. Certainly such "NaN" features are invalu- able in writing
statistics codes, spreadsheets and dataprocessing codes in general.
Presumably the lack of these hugely useful features is to accommodate
older sys- tems.


Continuation in a like vein would be largely futile. I do not object
to the "spelling" of various features, nor would correcting the
variety of "minor" errors that other commentators have and will no
doubt bring to the committee's attention make this proposed standard
any more useful to me, and others in the communities I serve.

It is my belief that passage of LIA would be very harmful to the
standards com- munity. Either it would be ignored (which reduces the
stature of the standards or- ganization(s) in question) or it will be
mandated for language standards.

In that case, I believe it would be very difficult to proceed with
Fortran, C or C++ standardization efforts, as LIA would provide a huge
black hole for efforts to fall into.

I believe there are real problems to solve. I believe that X3 and SC22
ought to take action to solve them. But this is not an appropriate
solution to the problems faced by most programmers, nor to most
applications.

I believe the correct approach would be to take IEEE as a starting
point for a language independent model, and a couple of languages
selected to provide bind- ings to. Bindings would be mandatory only to
those claiming system level conformance to IEEE. This effort might
reveal changes which ought to be proposed to IEEE for revisions of
their standard. Once such "proof of concept" suc- ceeded for a couple
of (preferably dissimilar) languages, SC22 and X3 would direct all
their language subgroups to arrange for such support to be bound into
the next revision of their standards.



I regret that neither SC22 nor X3 chose to invest the time "up front"
to get consen- sus among arithmetic experts (such as Kahan) and
language experts about what the problem to be solved was. LIA clearly
represents a great deal of effort, by sev- eral people over several
years. It is unfortunate that it serves no useful purpose.


Specific changes I'd like made to the document:

1.	Delete current text

2.	Pointer to IEEE arithmetic as language independent model

3.	Description of how binding to this standard ought to be
	performed by applica- ble language standards bodies. This should
	include detailed handling of mat- ters such as formatting of numerical
	results (e.g. Fortran claims that numbers are to be rounded. In light
	of IEEE, this should be clarified. Something along the lines of: "On
	an IEEE compliant system, rounding during formatting shall be
	performed using the rounding mode in effect"). Systems not claiming
	conformance with IEEE should be allowed the full lattitutde they are
	currently allowed.

4.	Sample bindings for two popular languages.



I thank the reader for bearing with me 


Regards,


Keith H. Bierman    keith.biermanaSun.COM| khbachiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043