Third public review of X3J11 C (a scientist speaks up)

[Herman Rubin]

In article <8365 at smoke.ARPA>, gwyn at smoke.ARPA (Doug Gwyn ) writes:
> In article <4566 at saturn.ucsc.edu> joseph at chromo.ucsc.edu (Joseph Reger) writes:
> >The draft may not be 'badly broken' but is missing out on the opportunity
> >to make C a convenient language for numerical computing as well.
> 
> I happen to use C for numerical programming, despite occasional flaws
> such as those you mention, primarily because it offers much better
> support for data structures than do other alternatives such as FORTRAN.
> I agree that there are some changes that could make C more convenient
> for such applications.  Hough's suggestions are for the most part good
> ones, but they haven't been receiving sufficient committee support.
> 
> The fundamental problem is that IT IS MUCH TOO LATE to be making
> significant changes to the proposed standard.  Look at all the trouble
> the last-minute addition of "noalias" caused.  The public review
> period is intended as a REVIEW of work done by the committee, not as
> an opportunity for language design.  Where were all these scientific
> users of C when the design work was being done?  By leaving that up
> to people who didn't think the flaws you perceive were significant,
> you did not get those flaws addressed in the proposed C standard.
> It's easy to complain about other people's work; much easier than
> helping with the work.  I suggest that you GET INVOLVED in drafting
> the NEXT (revised) standard.
> 
> Obviously I am not speaking for X3J11 officially here..

I use C for numerical programming, and then have to edit the resulting .s
file.  All of the languages, including C, are woefully deficient is letting
the user use the capacities of the machines.  If C is to be a good flexible
language, the committee should widely advertise for complaints about the
deficiencies of the language before starting out.

I would have no trouble coming up with pages of these items.  But the last
time I did something like this, in reply to the open invitation to attend
the meeting on the IEEE floating-point convention, was to receive an invi-
tation to attend!  I do not have the time to attend meetings on software.

Another problem is that the language gurus are unsympathetic to ideas which
run counter to their perception of computing needs.  They see integer 
arithmetic as primarily for addressing and looping; I see integer arithmetic
as important for number-crunching.  What about fixed-point (_not_ integer)
arithmetic?  What about the use of overflow?  What about division with
simultaneous quotient and remainder?  What about an operation or function
returning a string of values?  What about table-driven branches?  What 
about inserting new operators, using the processor syntax to specify the
argument structure of these operators?  In fact, what about using the 
easy-to-use hardware operators on most machines?  A good example is &~,
which is more useful than &, and is hardware on many machines, including
the ones for which C was initially written.  Many of those machines do not
even have a hardware &.

How many useful instructions have disappeared from hardware because they
do not occur in the HLLs?  Multiprecision arithmetic needs unsigned
multiplication and division to be efficient, and not floating point
arithmetic.  The presence of a single hardware instruction can be
essential to an algorithm being worthwhile; if the instruction is in
software, it is more likely to appear in hardware.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)