V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) (01/08/88)
Gus Baird suggest's that C might not have been given a power operator so as to make the point (to programming students) that some operators such as the power operator require some overhead. Yes I know that many computer processor chips have multiplication built right in. In any case, I very much doubt that C's lack of a power operator stems from a desire to prove a point to computer science students. As I am reading output from this group, the purpose of C is not to teach programmers programming as was Pascal, but to get the job done. Many suggestions have been offered as to how to use math.h functions for power operations, but a strange thing has occurred. There seems to be a difference of opinion on the subject. How can this be? The fact of the matter is, if C's purpose is to get the job done, then inclusion of a power operator is a reasonable expectation. I am not a systems programmer nor do I ever plan to be one. Systems programming is not my cup of tea. I am interested in applying C to writing statistical applications software. As such a power operator would be very nice. Since I am not a compiler writer, I don't really care what the ramifications involving the inclusion of a power operator are as long as there is one available for my use. Just as with the + and * operators for addition and subtraction, I really don't care all that much how they are implemented as long as they work to my expectations. The same goes for the power operator. My suggestion is to make the symbol for the power operator *^ which in a way tells what it does. If some of you out there prefer a language which illustrates programming techniques and idealism for teaching purposes, I suggest you use Pascal which was designed for the purpose of teaching students of programming how to program. That is why := is used and probably why the language is so verbose. As I am sure many people will agree, C is not a language one uses to teach introductory programming. It is meant for production not education and I hope this will continue to be true of C. Thanks for listening ... Stan Horwitz V4039 AT TEMPLEVM over in snow covered Philadelphia.
karl@haddock.ISC.COM (Karl Heuer) (01/09/88)
In article <11182@brl-adm.ARPA> V4039%TEMPLEVM.BITNET@CUNYVM.CUNY.EDU (Stan Horwitz) writes: >Gus Baird suggest's that C might not have been given a power operator so as >to make the point (to programming students) that some operators such as >the power operator require some overhead. It wasn't done for the benefit of students, but yes, my understanding is that the authors did intentionally avoid having nontrivial semantics on the builtin operators. (They could have done it anyway, and justified it by saying that the most common cases have a small positive integer constant as the right operand; this case is sufficiently simple to be a builtin.) Actually, I'd give a higher wish-priority to min and max operators. They could have used "><" and "<>", respectively; the syntax would drive BASIC and PASCAL users crazy! :-) >If C can have an operator for such as % for modulo divide, why not one for >exponentiation? Surely the same arguments against such a request can also be >made against the inclusion of %. "%" is a single instruction on the pdp11 (it's a side effect of doing a divide in the proper registers). On most other architectures, it's still only a divide-multiply-subtract. Exponentiation isn't that simple; in general, it requires a loop. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
ok@quintus.UUCP (Richard A. O'Keefe) (01/10/88)
In article <2197@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > Actually, I'd give a higher wish-priority to min and max operators. They > could have used "><" and "<>", respectively; the syntax would drive BASIC and > PASCAL users crazy! :-) Some years ago the C compiler I used *did* have min (spelled "/\") and max (spelled "\/") operators. These symbols are ever so much better because they are standard mathematical notation. Admittedly, when I got my hands on the compiler, it didn't generate correct code for /\ and \/, but that was easy to fix. When we moved "up" to a PCC-based compiler, conversion was a pain. It is interesting that macros don't give you quite the same thing. Suppose I write x = low_bound \/ a /\ high_bound; This might compile into movl low_bound,r1 movl a,r0 cmpl r1,r0 bles 1f movl r1,r0 1: movl high_bound,r1 cmpl r1,r0 bges 2f movl r1,r0 2: movl r0,x Now suppose I have #define max(a,b) ((a)<(b)?(b):(a)) #define min(a,b) ((a)>(b)?(b):(a)) and write x = min(max(low_bound,a),high_bound); Modulo parentheses, this expands to x = ( (low_bound < a ? a : low_bound) > high_bound ? (low_bound < a ? a : low_bound) : high_bound ); That's three conditionals, not two. An optimising compiler could be expected to recognise the common sub-expression, but why put it to the trouble? This "clipping" form is what I mostly used, but maximum or minimum of more than two elements is reasonably common, and has the same problem. The macros make a most unsatisfactory ersatz. So there is prior art for /\ and \/ in C. Fortran, of course, has them too. Apparently Fortran programmers do not think it a great burden to write MIN(I,J) rather than I/\J. Do I think it would be a good idea to add the to the standard? No. Standards should be DISCOVERED, not INVENTED. (It was *years* before COBOL 74 was generally available. In fact the next version of the standard was already out...)
TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU (01/13/88)
COM%"ericb@athertn.Atherton.COM" writes: >In article <3812@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >>I guess most people who are talking about problems with pow() >>can't think like a (draft proposed) ANSI C compiler. >> >>Suppose you have a dumb math library. In <math.h> you put a declaration like: >> >> double pow(double, double); >>[...] >>Now suppose that you have a smart compiler and math library. In >><math.h> you do: >> >> #define pow _compiler_pow >> >>where _compiler_pow is recognized as a keyword by the compiler. >>[...] >>Does *anybody* have a problem with this??? > >Seems to work as far as it goes... >Your solution still requires the arguments to first be promoted to double, >and the return result converted from double to whatever. I have done >graphics and number crunching where that conversion both ways is >not desired (float precision is adequate) and it takes an unacceptable >performance hit. >[ some stuff deleted here ] >Now, in the first instance above, it is clear that the arguments MUST >be converted to double. In the second (the builtin), I suppose the >compiler could somehow be told (a #pragma?) not to do that, but >that's really wierd and unexpected behavior. John described something important here. He showed how USING THE CURRENT ANSI DRAFT SPECS an implementor could offer a more optimized power operator. It is important to remember that the implementor can do this for many things like this. No, it would not take a pragma. In the first instance above, yes, things will be promoted to doubles. In the second, the compiler could decide what to do (inline the best code or call the proper function). When ANSI is accepted, syntax ambiguities and library incompleteness will not be factors. This will allow vendors to specialize and make compilers that are particularly fast (for prototypeing code), that generate particularly fast code, that do extra good jobs with math, or who knows what. Obviously, if you are doing math programming, you'd pick a compiler that specializes in good math (they'd do what John suggests for pow(), etc). Personally, I will be going for the compiler with the best debugger :-) Tom Limoncelli Drew U/Box 1060/Madison NJ 07940 Bitnet: tlimonce@drew.BITNET Disclaimer: These are my views, not my employer or Drew Univesity. --------------------------------------------------------------------------
peter@sugar.UUCP (Peter da Silva) (01/17/88)
In article <2197@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: [ no power operator in 'C' because... ] > the authors did intentionally avoid having nontrivial semantics on the builtin > operators. That's the core of my objection to structure passing/assignment. The semantics of a structure copy are pretty complex for an atomic operation. In the general case they involve a loop. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
karl@haddock.ISC.COM (Karl Heuer) (01/19/88)
In article <1409@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <2197@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: >>[ no power operator in 'C' because] the authors did intentionally avoid >>having nontrivial semantics on the builtin operators. > >That's the core of my objection to structure passing/assignment. The semantics >of a structure copy are pretty complex for an atomic operation. In the general >case they involve a loop. There's a difference of degree. Aggregate copy, even on machines where it isn't a single instruction, is a very simple loop (which can be unrolled, since the size is known at compile-time). The general case of (integer) exponentiation is more complex, assuming you want the O(log n) algorithm rather than the naive O(n). Anyway, that was my perception of the original intent of the authors. I don't think that should be the primary guideline for modern C. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint