dgh%dgh@Sun.COM (David Hough) (08/19/88)
The third public review of X3J11's Draft ANSI Standard C
is nearing its close on 1 September 1988. This third review
is based upon a draft dated 13 May 1988 which is not greatly
changed from earlier drafts except that the controversial
"noalias" keyword was removed.
Consequently the Draft still leaves a good deal to be
desired from the numerical point of view.
I have two documents available for electronic
distribution.
I will be glad to send you
tbl/troff -ms source for these;
I'll send both unless you specify that you only want the newer one
described below. Unfortunately the
Draft ANSI Standard itself is not publicly available in
electronic form.
The first available document is my 29 March 1988 commentary prepared
for the second public review period (30 pages), with X3J11's
formal responses of 22 April interspersed. The following were
co-conspirators:
Greg Astfalk Larry Breed D. Burton
W. J. Cody Iain Johnstone W. Kahan
Zhishun Alex Liu David Mendel Jim Meyering
K-C Ng Gene Spafford Philippe Toint
Stein Wallace
The second available document is a draft,
subject to revision until submitted about 25 August, of my commentary
for the third public review. It's only about 10 pages
since I generally avoided directly repeating what was in
the earlier document. I'm looking for additional reviewers
and conspirators on this one. The abstract follows:
The proposed C standard suffers numerical
shortcomings - many inherited from its precursors
- in areas of interest to providers of portable
mathematical software. I comment in detail upon
the following aspects of the proposed standard:
Comment #1, Section 3.9: encourage sound practices
Comment #2, Section 3.9: disparage hazardous practices
Comment #3, Section 1.1: emphasize surprises in rationale
Comment #4, Section 1.1: anticipate supplemental standards
Comment #5, Section 2.2.4.2: use "significand"
Comment #6, Section 2.2.4.2: <float.h> has too many names, not enough information
Comment #7, Section 3.2.1.4: round conversions between floating types
Comment #8, Section 3.5.4.2: fix arrays
Comment #9, Section 4.5: exceptions in mathematical functions
Comment #10, Section 4.5: tell more in the rationale
Comment #11, Section 4.5: standardize hypot
Comment #12, Section 4.5.4.6: delete modf
Comment #13, Section 4.7: specify which signals can arise
David Hough
dhough@sun.com
na.hough@na-net.stanford.edu
{ucbvax,decvax,decwrl,seismo}!sun!dhoughgwyn@smoke.ARPA (Doug Gwyn ) (08/19/88)
In article <64919@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes: >I comment in detail upon the following aspects of the proposed standard... One very important thing to be aware of is that X3J11 intends to get the proposed standard wrapped up (formally adopted) as soon as possible. When the third-round comments are reviewed at the September meeting, it is highly likely that all suggestions for substantive changes to the proposed standard will be rejected unless they remedy a proven serious deficiency. The reason is that any non-editorial change would necessitate yet another public review, therefore delay in publishing the official standard. This process could go on forever, but there is a strong desire to adopt a "good enough" standard in a timely fashion rather than working toward a "perfect" standard that is too late to matter. Many of us feel that the current draft is "good enough", perhaps modulo editorial nits. I don't mean to discourage comments on the draft; however, you should be advised that you'll need some extremely strong arguments for making any substantive changes. Examples showing that the current draft is badly broken would help.
jlg@beta.lanl.gov (Jim Giles) (08/20/88)
Why was this announcement posted to comp.lang.fortran?
jimv@radix (Jim Valerio) (08/22/88)
In article <8358@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
responds to David Hough's article (announcing his pending comments to X3J11).
Doug explains that X3J11's intention to get the proposed standard wrapped up
ASAP, and suggests that anything other than editorial changes are very likely
to be rejected.
Based on the replies I saw to the previous review cycle, I'm concerned that
even editorial comments are too likely to be rejected. Consider the
the Committee's choice not to replace "mantissa" and "value part" with
"significand". This editing change would bring the standard in conformance
with both IEEE 754/854 and ANSI/IEEE Std 1084-1986 (the IEEE Standard
Glossary of Mathematics of Computing Terminology).
I am also concerned that substantial mistakes are being made in the area of
floating-point support, despite the good critique provided by David Hough
in the previous review cycle.
I found the responses to David Hough's comments in the last review cycle were
often depressingly mechanical, unbalanced, and to my mind, unreasoned. I
don't understand how <float.h>, demonstably inadequate, arguably wrong, and
lacking prior art, can be accepted. Compare this to the decision not to
standardize hypot(), a function which exists on both BSD and SysV systems,
a function the Committee called an "invention of limited utility". Oddly
enough, the complementary atan2() function is standardized; the Committee
explains atan2() "can be used for purposes other than conversion to polar
coordinates", an argument that actually seems to apply more correctly to
hypot(). I could go on, but Hough's letter and the Committee's responses
say it all much better.
I hope that Doug, and the Committee as a whole, will very carefully read
and consider David Hough's comments in this coming review, and perhaps
supply better considered and self-consistent responses than those that
were provided in the previous review cycle.
--
Jim Valerio jimv%radix@omepd.intel.com, {verdix,omepd}!radix!jimvhenry@utzoo.uucp (Henry Spencer) (08/23/88)
In article <59@radix> jimv@radix.UUCP (Jim Valerio) writes: >I found the responses to David Hough's comments in the last review cycle were >often depressingly mechanical, unbalanced, and to my mind, unreasoned. ... Little birdies tell me that the review of the second-round public comments was, in general, awfully rushed. It shows. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (08/23/88)
In article <59@radix> jimv@radix.UUCP (Jim Valerio) writes: >I found the responses to David Hough's comments in the last review cycle were >often depressingly mechanical, unbalanced, and to my mind, unreasoned. The "mechanical" aspect may be partly due to the existence of a list of "stock response codes" that the Committee uses for its convenience in recording answers to issues raised. In cases where the proposal was rejected, there is also supposed to be additional explanation. As it happens, sometimes the additional explanation is not provided, or the one provided makes no sense to the response document editor and reviewers, so we have to try to provide additional explanation that reflects the Committee's position as best as we understand it. I will admit that less-than-perfect responses are sometimes the result. Also consider that a full rebuttal to a lengthy paper like Hough's would take far more work than anyone was prepared to do. >... Compare this to the decision not to >standardize hypot(), a function which exists on both BSD and SysV systems, >a function the Committee called an "invention of limited utility". Oddly >enough, the complementary atan2() function is standardized; the Committee >explains atan2() "can be used for purposes other than conversion to polar >coordinates", an argument that actually seems to apply more correctly to >hypot(). Although I favor standardizing hypot(), I have to say that I almost never have found occasion to use it, unlike atan2() which is the main inverse-trig function (if you find yourself using some other inverse- trig function, odds are you made the wrong choice). >I hope that Doug, and the Committee as a whole, will very carefully read >and consider David Hough's comments in this coming review, and perhaps >supply better considered and self-consistent responses than those that >were provided in the previous review cycle. I actually supported many of Hough's suggestions. Unfortunately, out of perhaps 30 to 40 voting members of the Committee, fewer than a dozen have significant experience using C for large-scale floating-point applications. This makes it hard to "sell" improvements in this area. Since the majority have little to gain (and their compiler/library work would be increased) by making such changes, naturally such proposals have a hard time obtaining the necessary 2/3 majority vote to be adopted. In fact, only remedies for really glaring deficiencies have much chance of gaining such a majority. And at this stage of the process, any substantive change has very little chance no matter how nice it might have been if it had been incorporated in the proposed Standard earlier.
scs@itivax.UUCP (Steve C. Simmons) (08/24/88)
Re the numeric problems: I agree with your assessments. But since this is largely a library issue, it is possible to cure the problem even with implementations that are seriously munged. This is not enough of an issue to make further delays in the standard. There's no reason why a revision of the standard cannot begin almost immediately. Clearly the folks who need the numeric changes should get together, formalize their needs, educate the rest of us on their necessity, and propose it for the revision. If we insist on making the changes in the *present* proposed standard, I think we're looking at major delays. Let's get the standard out NOW, and tighten down the libraries later. -- Steve Simmons ...!umix!itivax!vax3!scs Industrial Technology Institute, Ann Arbor, MI. "You can't get here from here."
henry@utzoo.uucp (Henry Spencer) (08/28/88)
In article <197@itivax.UUCP> scs@itivax.UUCP (Steve C. Simmons) writes: >... Clearly the folks who need the numeric changes should >get together, formalize their needs, educate the rest of us on their >necessity, and propose it for the revision. You forgot a couple of major intermediate steps: convince some compiler suppliers to implement the changes, and use them for a while to find out whether they really do the job. Many people, including me, will remain unconvinced that your proposals are reasonable unless you've actually tried them. Anyone who's actually tried language design (or library-function design, which is a specialized subcase of language design) can tell you that intuition is no substitute for experience. Yes, this is more work. There ain't no such thing as a free lunch. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu