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
In article <64...@sun.uucp> 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.
In article <8...@smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>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.
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. It is a pity that many of the 'real programmers' feel that any change that would allow C to be the language of choice for 'non-real programmers' (scientists) somehow would hurt their feeling/interests. I did not participate in the debates about the power operator, noalias, conformant arrays etc., because I was scared by some the vehemence of the 'defender of the faith'. It is sad that never seemed to be enough time to discuss some recommendations in detail. There are many scientist that I know (mostly younger people) who really came to like C, and we are using it despite its problems and deficiencies as far as numerical computing is concerned.
I strongly feel that it is an unacceptable situation that many of us has to program around these problems, although some of them could be easily fixed. Much of today's (computational) science is done in a workstation environment, mostly under Unix. In the future this is going to be even more so, especially now that the supercomputer manufacturers are adopting Unix, too. The best compilers in these environments are the C compilers, period. Since the manufacturer often uses the same compilers for his own development, the user can be fairly confident that most of the bugs have already been eliminated. So there will be ever more scientist who program in C. Why is it such a good idea to have a growing amount of code around that contains ugly, difficult to understand "fixes"?
The power operator is a small issue, I agree. Noalias (no flames please, I am afraid of you) is definitely going to come, since the vector machines need it. Only that it will come in many (vendor specific) colors and flavors. Conformant arrays? We (scientists) need them very much and I do not see how they would mean any grand problem for C --and the end of the western civilization-- in the simple version proposed by David Hough (see his "Comments on Proposed ANSI C Standard").
All these problems could be solved, of course, by the inclusion of the following statement into the Draft:
"Scientist and other non-real programmers are not allowed to use the programming language C".
(The funny thing is that some scientist would actually like to see this statement, not only in the Draft, but everywhere).
In article <4...@saturn.ucsc.edu> jos...@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..
In article <8...@smoke.ARPA> g...@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%ra...@omepd.intel.com, {verdix,omepd}!radix!jimv
In article <8...@smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <4...@saturn.ucsc.edu> jos...@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.
>The fundamental problem is that IT IS MUCH TOO LATE to be making >significant changes to the proposed standard.
It seemed to me - and I admittedly did not follow it from the very beginning - that it was always MUCH TOO LATE.
>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.
> In article <4...@saturn.ucsc.edu> jos...@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 hru...@l.cc.purdue.edu (Internet, bitnet, UUCP)
>The fundamental problem is that IT IS MUCH TOO LATE to be making >significant changes to the proposed standard. Look at all the trouble >I suggest that you GET INVOLVED in drafting >the NEXT (revised) standard.
The problem is, how does one do this? IF you are a regular reader of this august information dispersal system, you might here about some such effort not too late after it gets started. But, in the absence of that, you are going to know about it only AFTER the standard gets approved, when the next version of your compiler comes out and your programs stop compiling. I never heard about Fortran 77 until my programs refused to run because a new compiler didn't support Hollerith fields.
In article <59@radix> j...@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 he...@zoo.toronto.edu
In article <4...@saturn.ucsc.edu> jos...@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...
Well, remember two things. First, that there was opportunity for input along these lines earlier, and little was received; it is now much too late for major changes. Second, that X3J11's mission was to standardize an existing language, not to invent a new one; they did make some small steps toward making C friendlier for numerical work, and that is probably about all one should expect from a standards committee.
If you really want to see C improved as a language for numerical computing, the first thing to do is to scream at your compiler supplier until he/she/it does some of the things you want. Then, when the time rolls around for the next revision of the C standard, you can propose changes based on *actual experience*. This will carry a lot more weight than untried inventions. Given the time lags involved in all this, if you are serious about it, the time to start haranguing your supplier is *now*. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
In article <59@radix> j...@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.
In article <8...@l.cc.purdue.edu>, c...@l.cc.purdue.edu (Herman Rubin) writes... >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.
On the contrary: C is NOT woefully deficient for the vast majority of applications to which the vast majority of "paying users" are interested in applying it. As later comments make clear, the kinds of users Mr. Rubin has in mind are rather different. The fact of the matter is, hardly anyone thinks that "fixed-point arithmetic" (as opposed to integer) is important. It just does not come up in the vast majority of uses to which computers are put.
Developing software is an expensive proposition. Everything added to a language has to be implemented somewhere, by someone. Then it has to be debugged, supported, and maintained. There are only two ways this will happen: If someone is willing to pay for it; or when someone is willing to do it out of their own love for the subject.
>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.
Ah, so Mr. Rubin is willing to COMPLAIN, but he is NOT willing to do the work out of his own love for the subject. He certainly gives no indication that he is willing (or able) to pay to have it done either.
>Another problem is that the language gurus are unsympathetic to ideas which >run counter to their perception of computing needs.
I am a "language guru", though my interests happen to be in parallel program- ming languages. Again, why should I care what Mr. Rubin thinks "computing needs" are when he can't provide money, isn't willing to invest his own time, and can only provide the most specialized examples of what such features might be used for?
> 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 &.
What about all these things? Being absolutely brutal about it: Why should I (or other readers) care? What will it gain us to worry about this?
>How many useful instructions have disappeared from hardware because they >do not occur in the HLLs?
Along the same brutal lines, my answer is: No USEFUL instructions have disappeared at all. What has disappeared are a lot of non-essential ideas that were tossed in back in the days when computer architecture was a new field, with a large research component. No one really knew what would turn out to be "useful".
Well, for better or for worse, computer architecture isn't like that any more. Computer design is a multi-billion dollar industry. It is driven, not by what people might WANT in some abstract sense, but by what they are willing and able to pay for. THAT is the only workable definition of "useful", and on that scale the things Mr. Rubin wants have long ago fallen to the bottom of the list.
> 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 >hru...@l.cc.purdue.edu (Internet, bitnet, UUCP)
It's painful to see economics dominating a field one loves and pushing it in directions one is not inclined to go. I'm not unsympathetic to Mr. Rubin's position; my own background, way back when, is in mathematics (complex analy- sis and a bit of analytic number theory). Even the work I do now is beyond the current "commercial" leading edge, and I am sometimes frustrated by the way hardware manufacturers put roadblocks in the way of doing "obviously useful" things, because they are too busy heading in other directions. But that's life.
The USEFUL thing for Mr. Rubin to do, if he really thinks these issues are important, is to work at convincing others of it. Not by complaining in this and other newsgroups about how he is being ignored. But exactly by spending some time with those committees, by offering some real alternatives, by showing how what he proposes is useful to people other than himself. Frankly, I doubt anything he can do will ever get major commercial ventures interested. But that doesn't mean he can't get other researchers interested. Many people are able to design and build special-purpose hardware and software today; if Mr. Rubin talked to some of them, he might discover that many good research hardware hackers have the tools, but are lacking interesting problems. I will say, however, that his chances of getting people interested would improve markedly if he stopped complaining about how he didn't "have the time to attend meetings on software". Very few computer scientists have the time to attend meetings on statistics either. -- Jerry
In article <8...@l.cc.purdue.edu> c...@l.cc.purdue.edu (Herman Rubin) writes:
[wish list for HLLs]
I agree that many of the features wished for ought to be in higher- level languages. But to put all of them in C would no longer leave the relatively small, simple, low-level language that C was designed to be.
Nearly all of the features that Herman Rubin wishes to see *are* already in HLLs, only not all are in each HLL. C++ has some. Ada has *many* of them, especially fixed point arithmetic and functions returning structured values.
The real problem is not with C designers. The real problem is with Fortran designers, who have always had an explicit mandate to design a language for scientific computing, and have continued to fail miserably to achieve this. In a way the C users who do numerical computing want to put on C the burden that Fortran was supposedly designed to carry.
The trouble with doing so is that other users will lose. Each new feature added to a language increases the complexity of the language translator, and *all* users, even those who don't need to use these features, will pay in money, disk space, and CPU time. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
Given: 1. ANSI C (as proposed) does not support numerical computing adequately. 2. There is not enough time to fix it for the current standard.
There are several ways of coping: 1. Use Fortran. 2. Hope your compiler vendor comes up with reasonable extensions. 3. Do something to encourage your compiler vendor to come up with something reasonable.
I would favor writing a standard for "correct" math extensions to the C language. If the standard is adopted by at least one compiler vendor (or producer so as to include the FSF) then you can show prior art for the next round of X3J11. If the "correct" math extensions are simple enough to implement then many manufacturers will put it into their compilers.
A proposal for a standard to be produced by an individual, an independent committee or a committee from one of the user groups (ACM, IEEE, /usr/group, Usenix, etc...). A committee could meet in person or electronically, etc...
Unfortunately, I lack the skills to produce such a document. ---- Paul Haas, uunet!actnyc!prh (if that doesn't work: h...@msudoc.egr.msu.edu)
In article <225800...@uxe.cso.uiuc.edu> mcdon...@uxe.cso.uiuc.edu writes: >you are going to know about it only AFTER the standard gets approved,
I'm pretty sure the formation of X3J11 was announced in CACM, and it has been well known in the C community for years (e.g. "The C Advisor" and other regular columns). I don't think it made the TV network news.
> On the contrary: C is NOT woefully deficient for the vast majority of > applications to which the vast majority of "paying users" are interested in > applying it.
I find this comment and the attitude of the author woefully parochial -- I do not program in COBOL and I might not even recognize a either a data entry language or a data base language if it hit me in the face, but I do know that more money (real dollars, payroll hours or however you want to look at it) is spent on programs that are much more difficult to write in C than in the language they are written in (and in some cases -- heresy -- that language is even 8086 assembly language!). I am quite certain that spreadsheets garner more user dollars than C compilers for any computers other than Crays and Suns (and Fortran compilers are probable ahead of C compilers on at least the Crays).
C is rapidly catching up with Pascal as the second most well known language but it has a long way to go before it becomes as well know (and perhaps as useful)as BASIC (more heresy?).
For my purposes, C is the language of choice most of the time (by a fair margin -- I have no second choice, except maybe Modula were C to vanish from the face of the earth). But C is not a universal language and she does not appear to be expanding into other areas of applicability any more rapidly than her elder brother and sister, FORTRAN and LISP. And I think this is both A GOOD THING, and the reason that it is unlikely to be a major language 20 years from now. I have plenty of spare time in 20 years to learn several new small languages and I have no real need to program in Ada or PL/I.
(How do you like my personification of programming language? Shall we create a few mythic tales to describe her birth?)
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."
In article <4...@saturn.ucsc.edu> jos...@chromo.ucsc.edu (Joseph Reger) writes: >It seemed to me - and I admittedly did not follow it from the very beginning - >that it was always MUCH TOO LATE.
X3J11 has been trying to get the %#@%$% thing out the door for quite some time now. The combination of lengthy public-review cycles and official meetings held only quarterly means that a standard which needs *three* public-review cycles will be in "almost finished, no substantive changes without a damn good reason" status for a long time. Sounds like you came on the scene after that phase started. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
In article <3...@bsu-cs.UUCP> dh...@bsu-cs.UUCP (Rahul Dhesi) writes:
>The real problem is not with C designers. The real problem is with >Fortran designers, who have always had an explicit mandate to design a >language for scientific computing, and have continued to fail miserably >to achieve this. In a way the C users who do numerical computing want >to put on C the burden that Fortran was supposedly designed to carry.
The Fortran 8x committee has its problems, but lack of features is not one of them. The April '87 Fortran draft standard includes a number of "modern programming language" features, including something like structures (referred to as derived types) and modules, with imports and exports. The real problem with the Fortran standardization process is the in ability of the Fortran community to arrive at a standard. The decade is almost over. Soon it will be Fortran 9x.
Ian Kaplan
"I don't know what the most popular numeric programming language will look like in the year 2000, but it will be named Fortran."
>>On the contrary: C is NOT woefully deficient for the vast majority of >>applications to which the vast majority of "paying users" are interested in >>applying it.
[back to chasm@killer:]
>I find this comment and the attitude of the author woefully parochial >-- I do not program in COBOL and I might not even recognize a either a >data entry language or a data base language if it hit me in the face, >but I do know that more money ... is spent on programs that are [done >in other languages] .... C is not a universal language and she does >not appear to be expanding into other areas of applicability any more >rapidly than her elder brother and sister, FORTRAN and LISP. And I >think this is both A GOOD THING, and the reason that it is unlikely to >be a major language 20 years from now.
This is curious, because I see Jerry Leichter and Charles Marslett as basically in agreement---so why should this attitude be `woefully parochial'? That C does not make a good functional programming language is no surprise; that people who pay for programs written in C are not paying for such code should also be no surprise; and hence that there is no great push for C to be augmented with everything out of Miranda and FP combined should likewise be no surprise.
To return somewhat to the original subject: If you believe that, with a few tweaks that would either improve, or at least not damage, the language, C could become an ideal language for numerical software, it is then your job to demonstrate it. Make the changes---write yourself a compiler, or have someone else write it---and show that the new language is better than the old. If it is sufficiently better, programmers will beat a path to your mailbox, and the new language will become popular in the same way that C became popular. And if *you* are not willing to put in the effort, why then should *we* be? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
I've been using C for most programs since 1978. I've taught and am currently teaching a C programming course at Purdue University. However, C isn't supposed to be all things to everyone: it is a systems programming language and has little real competition as such (Ada? Modula 2?).
Making C a numerical applications language has never been a priority, nor should it be. For example, fixed-point arithmetic would never be used by most of the originally-intended C user community; it would simply clutter the language definition and impede the development of good quality compilers. I personally feel that X3J11 has done an outstanding job of resisting the "kitchen sink" syndrome, keeping the language reasonably clean and implementable, while resolving more than a few ambiguous/omitted details. Propose a new language if you're not happy with any existing one.
As for the language standardization process, if you're not willing to attend the meetings nor to correspond in a reasonably formal way, I don't think you've got much of a reason to complain. Now, I'm a bit unhappy in that I wasn't invited to be on X3J11 and would like to have had more input, but even so I have had no trouble in getting X3J11 folk to listen to me. My number one remaining beef with X3J11 is that they changed the function declaration syntax in an incompatible way without simultaneously providing public-domain software to automatically convert old C programs to the new notation... but this is a problem I personally intend to remedy.
So, let's not flame on about X3J11. It isn't perfect, but it is C and it is a better definition than we had before. Enough said.
In article <8...@smoke.ARPA> g...@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <225800...@uxe.cso.uiuc.edu> mcdon...@uxe.cso.uiuc.edu writes: >>you are going to know about it only AFTER the standard gets approved,
>I'm pretty sure the formation of X3J11 was announced in CACM, and it >has been well known in the C community for years (e.g. "The C Advisor" >and other regular columns). I don't think it made the TV network news.
Doubtless. But we were talking about the numerical community, they generally don't read CACM. So, was it announced in, say publications of the AAAS or the IEEE? (NOTE: I'm not saying it wasn't, I don't know, and I'm curious)
We have been using C for scientific computing for some time now and so far we only feel the need for a very few changes to the language ( we use a non-ANSI C compiler). One of these changes is already made in the ANSI standard, the possibility to pass a float as an argument to a function. The second change we would like to be made is the possibility to compile C with "intrinsic" function to be able to use a floating point processor like the MC68881 more efficiently. This requires only an extra option for the compiler. For the rest we consider C a good language for scientific computing that generates code that is not much slower than FORTRAN and has the advantage of structures. In one case were we needed complex data structures our C version turned out to be even more than twice as fast as a similar code in FORTRAN.
Camiel Severijns UUCP: mcvax!eutrc3!eutnv1!camiel Surface Physics Group, Dept. of Physics Eindhoven Universtiy of Technology The Netherlands
