Commentary for third public review of X3J11 C

[Doug Gwyn]

In article <59 at radix> jimv at 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.