Public comments on LIA-1

Wed Jan 5 19:52:35 PST 1994

Original postscript happily provided upon request. Snail mail on its
way. 

To: Distribution
From: Keith H. Bierman

Comments on X3T2/93-135 LIA-1 Ballot

In general, all of my objections to the last draft hold, with modest
modifications. These follow as an addendum.

It is my opinion that LIA processing typifies process mistakes that
have become endemic in at least three standards communities: ANSI, ISO
and POSIX. I regret that the following document is so long; but
reviewing the email traffic on LIA has forced me to realize that there
is a deep communication gulf.

It is not my intent to insult any individual or group. Everyone
involved in the Standards process puts a lot of personal as well as
professional time and effort in; and I do not think that anyone means
to inflict harm upon the community in the process.

However even the best people with the best intentions will produce bad
standards if the goals aren't chosen correctly. Even the best people
with the best intentions will select ill-advised goals if the process
is flawed.

Standards ought not be viewed as an end in and of themselves.
Standards are good when they result in lower costs or higher quality.
Standards are expensive. They are costly to create, they impose costs
upon other standards bodies (to avoid conflicts, to get approval,
etc.), upon vendors and not infrequently upon users. In addition to
these "direct" costs, there is also the opportunity costs which are
harder to measure. These include the Standards work not done because
the people necessary are doing other work, Standards work not done
because there is already something (suboptimal) in the area, Standards
work not done because the coordination effort is too great, and the
like. In addition, there may very well be implementation work not done
because a Standard exists (even if it has limited utility or is
completely unresponsive to customer needs), there may be
implementation work done at the expense of useful work or improving
the quality of implementation, etc.

I, and several others, have complained that LIA is not helpful, that
it's basic approach is not appropriate for this era of computing and
the like. LIA's supporters (which are pretty much by definition its
authoring committee) dismiss such criticism as irrelevant because they
have a charter to do precisely this work. Similar arguments occurred
with the POSIX.9 effort, during some of the debate on "varying
character strings for Fortran" and during some of the X3H5 debate
(during my tenure there).

Since ANSI and ISO efforts are often closely aligned (and rightfully
so!) an ANSI committee often finds itself discussing how to vote on an
ISO ballot. During X3J3 deliberations, it has been argued that:

1.	 There is no doubt this is going to pass at ISO; therefore we
	 should vote yes so that we won't be perceived as being an
	 impediment to the process.    

2.	It is too early to vote no, this is merely a procedural vote
	to forward a Draft. 

3.	It is too late to vote no, the basic direction was cast in
	concrete long ago. 

4.	Voting no is hard; it requires substantial work. Voting yes is
	easy.

5.	The only possible votes are: Yes, Yes with comments and No
	with comments which when addressed change the vote to a yes. Therefore
	there is no way to object, so don't bother trying.   

I believe that these are all true to some extent, and all indicate
dangerous process flaws.  

During the time I was involved in attending or at least tracking X3H5
meetings I saw other unrelated danger signs: 

1.	Many attendees did not agree that the direction was a valid
	one. Private comments suggested that many were there "in self
	defense". Of course I can only speak for myself, but it
	certainly was the argument I had made to my Management to get
	us to participate for a time.     

2.	The number of attendees declined from about 15 to about 5. I
	do not know if attendance has improved. 

These were indications of a possibly flawed process in action. 

Some of the comments regarding POSIX.9 were directly aimed at the
fundamental direction taken. These ballot comments were resolved by
the simple expedient of noting that they were not responsive, the
direction had been settled long ago. It should be noted that the.9
drafting group consisted of approximately three individuals. Dedicated
and intelligent; but certainly not representing a large cross section
of interests.

Standards often take considerable calendar time to create. The
computer field is a rapidly evolving one. It is quite possible that
between the time an effort is begun and when it is completed that the
scope of work, or direction which is most suited to the environment of
the day has changed. It should be possible to change the direction of
an effort until it is a finished Standard. It should also be easy for
an effort to be disbanded.

This last point is a critical one, and a painful one. Any group of
people who invest years of effort into a project have a natural
interest in seeing it come to completion. Aside from the personal
investment, there may be negative professional consequences to an
effort abandoned.

Nonetheless, we should hold this out not merely as a theoretical
possibility but as a default course of action. For all Standards
committees, I think we should have the following procedures:

1.	At the time of inception, the parent body should specify a
	minimum committee size indicating viability. If a Standards
	effort can't get a certain level of participation from the
	community, we ought to abort the effort. Either the time for
	that particular Standard hasn't come, or it has passed. It is
	not a kindness to allow the participants to continue. Without
	community support it is unlikely that even a good Standard
	will have utility. It is, of course, much more likely that
	lack of community participation will result in a Standard
	which is less than Good, and may even be harmful.         

2.	Periodically (say yearly) a committee should formally review
	its charter and assigned work items. The committee should have
	to have a majority voting yes to continue work. It is usually
	hard to even get a committee to consider the question; it is a
	very rare act of courage for a committee to disband itself.
	POSIX.9's Fortran 90 effort was one such. This reconsideration
	of basic direction ought not involve elaborate debate, or a
	large time investment. If it does, it is a sure sign that
	there are underlying fundamental problems. Failure to resolve
	them is likely to reflected in a poor Standard or in
	difficulty in getting any Standard out the door.          

3.	An absence of Public comment is not indication of approval, it
	is indication of indifference, ignorance. of the process,
	ignorance of the consequences or ignorance of the subject
	area.During my review of the last round of US LIA public
	responses, I recall seeing *no* positive comments from the
	community and noting several critical comments. However it was
	most notable how few comments there were at all. Numerical
	computation remains a multi-billion dollar business; one might
	very well expect someone from outside the committee to applaud
	its efforts. I am loathe to prescribe precisely how many
	public comments any Standard must achieve; but common sense
	suggests that zero is a very poor choice.          

4.	Questions regarding the basic direction should always be in
	order. It is quite possible that the preponderance of opinion
	is on one side. I most certainly do not advocate holding up a
	Standard for any random complaint. But it should be possible
	to derail an effort which has progressed in the wrong
	direction before it becomes a Standard; and it should be
	possible after the first draft has been circulated.      

5.	The default for ISO voting should be NO not YES. Furthermore
	YES should require justification, NO should be allowed to be
	simple. YES, "this Standard will be useful in assisting
	portability" or some other stock phrase could be acceptable.
	The key thing is that we must have a reason for voting yes.
	Standards cost; we should not increase costs without having
	some benefit.       

6.	Lastly it should be possible to vote NO this is an area that
	is not yet ready for standardization or NO this is a
	completely unacceptable approach. 

I do not know precisely how LIA would have evolved under these revised
rules. But it does seem worth noting that: 

1.  Only a handful of people were involved in the detailed drafting of
    LIA, and only two vendors were represented (and no one from the IEEE
    754 effort was involved). It is possible that I am misinformed
    about the size and constitution of the committee; but I have seen
    no evidence to the contrary.

2. Many of the negative comments regarding LIA are directly squarely
   at its basic thrust; is it really helpful to have a new Standard in
   this area which doesn't solve problems the community feels it has?

3.	One of the criticisms of LIA is that (aside from providing no
	utility) it is too complex for most practitioners to confirmed
	in detail. ISO "yes" votes were portrayed (by the X3T2 chair
	during his remarks to X3J3) as a clear endorsement for LIA,
	but the only way for a country to vote NO is for its body of
	experts to understand the document and draft changes without
	changing the basic direction of the document! A tough chore to
	say the least! It is, of course, equally false to claim that
	it was opposed by everyone but that they failed to understand
	it. The sad fact of the matter is that given the current
	voting rules and procedures that neither YES nor NO votes can
	be taken to infer whether a Standard was liked or disliked!           

Kahan's objections to LIA have been dismissed as being merely
philosophical; based I *think* on the notion that the fundamental
direction chosen is somehow right (either by construction or by fiat).
My reading of the last round of public comments is that the
commentators, by and large, disagree with the committee and agree with
Kahan. It is indeed unfortunate that we lack a procedure for coping
with this situation other than ignoring the public input.

In one of Schaffert's published remarks, he characterized Kahan's
position of being an attempt to limit diversity and that LIA was
trying to promote it. I found this claim to be very entertaining. A
Standard is *supposed* to limit diversity! That's the point of the
exercise!

There is no particular reason why there must be only a single
arithmetic standard. As a user, I would certainly look forward to
greater availability of interval arithmetic as propounded by
representatives from DIN. But each arithmetic standard should be
focused, not designed to promote diversity. We have diversity before
we have Standards.

Part of my duties as a Sun employee, involve a great deal of customer
interaction. I've spent some effort since the last ballot period
talking to our users about LIA. The vast majority of them had no idea
of its existence. Those that I could cajole into talking about it a
bit, suggested that I find a better way to spend sleepless nights. I
was completely unable to get them interested enough to write down any
objections. The scariest remark was from a usually numerically
sensitive customer. I suggested that if LIA becomes a standard that
we'd have to invest time and energy in doing work related to it rather
than something else. He suggested that if we were stupid enough to
ignore real needs their organization would simply use someone else's
system. Nor was he prepared to invest even five minutes writing a
protest letter. His employer doesn't reward such activities, and he
noted that it was in his experience pretty pointless (the Standard
tends to go out anyway). It hardly advances the cause of
Standardization to give vendors such a strong incentive to ignore
them. Nor does it help users, as they can not assume that Standards
are either Good nor that they are going to be available.

I believe that the US should vote NO on LIA-1. I believe that SC22
should stop this before it is too late. There are no simple changes to
the document to make it useful; we can only strive to make it least
harmful. This is quite unfortunate, and it is not due to the authors
lack of effort or expertise. It is due to an ill-chosen charter which
was not so obviously ill-chosen when the effort began.

The following text is an updated version of my last ballot comments
(since I disagree with the committee's notion that it has resolved
them).

It should be noted that I take issue with processing of US LIA-1; that
is to say our X3T2 rep received his letter ballot prior to the
completion of the Public comment period (I understand the unfortunate
choice of dates between ISO and ANSI, but there is the strong
suggestion that the TAG is going to vote yes, come what may) and I do
not believe that the comments from the first public comment were dealt
with correctly either. In addition, as noted by Farkas, substantial
changes were made to the document without adequate review.

Changes to the original text are contained in <bracketed material>

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 numeric 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 implementations 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 standard. 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 language 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.  

<as mentioned above, the real objection still stands; it cannot be
word smithed away>

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
 accommodate 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) revised 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 features.

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 arithmetic schemes. New ones shall arise, old ones (e.g.
interval arithmetic) may finally 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 presence 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 computing, 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. <LIA now has a
way to accommodate CRI traditional arithmetic; however it makes it
even harder to use LIA. As Kahan noted years ago, creating a
descriptive system which covers all systems of interest results in an
exceedingly complex description>          

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 handles 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. Indeed, 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 consideration 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 arithmetic 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 initialize memory with "NaNs" and thus find bounds
problems. Similarly, one of the best features of IEEE are these
values. Certainly such "NaN" features are invaluable in writing
statistics codes, spreadsheets and dataprocessing codes in general.
Presumably the lack of these hugely useful features is to accommodate
older systems.

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 community. Either it would be ignored (which reduces the
stature of the standards organization(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.  <Craig Shaffert has asserted
that LIA, IEEE 754 and Fortran are currently compatible. I regret to
say that this is simply false. Fortran as it currently stands
conflicts with IEEE754 behavior in several ways. Work in X3J3 is
underway to fix this in some future release. It is perhaps worth
noting that I probably would have finished a draft of the changes
required during this winter break had I not been required to reread
LIA and the affiliated debate material, and worked on this response.
This is an example of the hidden costs I called out above.>

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 bindings 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" succeeded 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 consensus 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 several people over several
years. It is unfortunate that it serves no useful purpose.  <In
retrospect the generic problem is that what a bevy of experts may very
well have advised may change over time. While I do not think that
Kahan et al. would have ever accepted the charter that LIA undertook,
the "varying string" addendum to Fortran provides an example of a case
where propounds have become opponents, and quite reasonably so. The
"vary string" module effort served to highlight deficiencies in
Fortran and evidence that Strings should be a native type in the
language.

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 applicable language standards bodies. This should
	include detailed handling of matters 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 latitude they are currently allowed.

4.	Sample bindings for two popular languages.

I thank the reader for bearing with me .

Regards,

Keith H. Bierman

Distribution:
X3 Secretariat
Attn: Deborah J. Greco
Suite 200 
1250 Eye Street NW
Washington DC 20005

American National Standards Institute
Attn: BSR Center
11 West 42nd Street, 13th floor
New York NY 10036
WG5
X3J3
NCEG
numerical-interest
skj
fpgroup