exponentiation operator (lack of)

[carlos]

Curious:
Why wasnt a primitive exponentiation operator not added to C99?
And, are there requests to do so in the next std revision?

Justification for doing so:
C and C++ are increasingly used in low-level
numerical computations, replacing Fortran in newer projects.
Check, for example, sourceforge.net or freshmeat.net

But neither language offers a primitive exp operator.
^ is exclusive OR, which is much less common in numerical
programs than exponentiation. However, ^^ is open.

 

[Robert Gamble]

Curious:
Why wasnt a primitive exponentiation operator not added to C99?

You should read the FAQ before posting, this is answered in question
14.7, see http://www.eskimo.com/~scs/C-faq/q14.7.html for the answer.

Robert Gamble

 

[carlos]

That is not an answer, just an excuse. It links language operators to
presence or absence of hardware. C is not assembly language.
Translation is the job of something called a compiler.

 

[Artie Gold]

That is not an answer, just an excuse. It links language operators to
presence or absence of hardware. C is not assembly language.
Translation is the job of something called a compiler.

1) You have failed to quote sufficient context -- for which Google's
broken Usenet interface is no excuse.
2) You were directed to an answer -- in the FAQ, which you should have
read *before* asking your original question.
3) This newsgroup is primarily concerned with the ISO C language as it
*is*. If you want it to be different, the proper place for such
discussions is
Further, I recommend you do some reading on the history of the C
language, why it was created, what was its intended purpose, etc. That
may provide insight into the design decisions made.

HTH,
--ag

 

[slebetman]

C is not assembly language.

Some people would beg to differ. C evolved from B which was merely a
very high level macro assembler. C itself was developed primarily as
replacement of assembly - a better way to write low level system
software. You want something higher level, try C++ (there you can
overload whatever operater you want).

 

[jacob navia]

(e-mail address removed) a écrit :

Some people would beg to differ. C evolved from B which was merely a
very high level macro assembler. C itself was developed primarily as
replacement of assembly - a better way to write low level system
software. You want something higher level, try C++ (there you can
overload whatever operater you want).

This is the old story supported by many people around here.

C is dead and everybody should move to the "higher" level, C++.

This justifies trying to deny C any evolution possibilities, and
keeping the discussion in this group as "low level" as
possible.

The OP question is a good one. Personally I do not think we need a new
exponentiation operator, and in lcc-win32 there is operator overloading,
but those are not answers to the OP question.

May I remind you that the supposedly "higher" level C++ doesn't
have an exponentiation operator EITHER ???

I think the answer is that the enormous problem of introducing a
new operator, with all the complications of the 15 levels of
precedence of C makes the introduction of an ^^ operator an
herculean task, one that nobody has attempted, and probably never
will.

Let's stop the nonsense and tell the truth for one.

jacob

 

[carlos]

Some people would beg to differ. C evolved from B which was merely a

very high level macro assembler. C itself was developed primarily as
replacement of assembly - a better way to write low level system
software. You want something higher level, try C++ (there you can
overload whatever operater you want)

Absolutely correct, but C++ does not have an exponentiation operator
to overload. I might be off base here since I use C++ very little,
but I dont think pow(..) is in the "overloadable" list.

As regards gradual departure of C from assembly, let me note that
C99 offers a built-in complex type and associated operators.
Those are not part of any widely used assembly language
instruction set, although they can be microcoded in some
embedded systems.

 

[osmium]

Some people would beg to differ. C evolved from B which was merely a
very high level macro assembler. C itself was developed primarily as
replacement of assembly - a better way to write low level system
software. You want something higher level, try C++ (there you can
overload whatever operater you want).

This exposes one of the frailties of C++. The natural exponentiation
operator, ^, has the precedence of exclusive or, which is far too low for
the operation desired. Overloading it would be a disaster waiting to
happen. You would have parens all over the place and if you forgot one
there would probably be hell to pay in faulty results.

 

[slebetman]

(e-mail address removed) a écrit :
<snip>

May I remind you that the supposedly "higher" level C++ doesn't
have an exponentiation operator EITHER ???

The OP I was replying to did not mention anything about exponentiation
operator. He just said operators are linked to what is available in
assembly.

 

[Jordan Abel]

Absolutely correct, but C++ does not have an exponentiation operator
to overload. I might be off base here since I use C++ very little,
but I dont think pow(..) is in the "overloadable" list.

I believe functions can also be overloaded.

 

[jacob navia]

Jordan Abel a écrit :

I believe functions can also be overloaded.

What's the use of overloading a function here?

I mean would you overload pow() ???

What's the point?

A function (overloaded or not) is not an operator!

 

[jacob navia]

(e-mail address removed) a écrit :

The OP I was replying to did not mention anything about exponentiation
operator. He just said operators are linked to what is available in
assembly.

God you are totally confused!!!

1) The OP (see the TITLE of this thread) asked why there isn't
an exponentiation operator in C.
2) He was redirected to the FAQ that says that there isn't since there
is no hardware support for that operator. It is the FAQ that says
it, not the OP.
3) The OP critized the FAQ, saying (rightly so in my opinion) that
C is not tied to hardware.

You mess completely!

jacob

 

[jacob navia]

osmium a écrit :

:




This exposes one of the frailties of C++. The natural exponentiation
operator, ^, has the precedence of exclusive or, which is far too low for
the operation desired. Overloading it would be a disaster waiting to
happen. You would have parens all over the place and if you forgot one
there would probably be hell to pay in faulty results.

And we come to the point that I mentioned elsethread:

The 15 levels of precedence of C are so messy that nobody
has had the time to devote a man year to find out how
an exponentiation operator could be implemented.

 

[Richard Heathfield]

jacob navia said:

A function (overloaded or not) is not an operator!

Actually, they're not all /that/ different, conceptually speaking. One can
think of qsort as the "sort" operator, strcmp as the "string comparison"
operator, foo as the "do the foo thing" operator, and so on. A function is
just God's way of letting us specify our own operators that can do whatever
we have the skill and imagination to write.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




Actually, they're not all /that/ different, conceptually speaking. One can
think of qsort as the "sort" operator, strcmp as the "string comparison"
operator, foo as the "do the foo thing" operator, and so on. A function is
just God's way of letting us specify our own operators that can do whatever
we have the skill and imagination to write.

Granted, both operator overloading and function calls are the
same. The difference is syntax. In a function call even
if the function is overloaded you have a monadic (single
argument operator)

FUNCTION '(' arguments ... ')'

An operator can be monadic like above:
! arguments of the NOT operator
or DYADIC

arguments operator arguments

like

2 + 3

The purported exponentiation operator would have to be dyadic:

10 ^^ 3 --> 1000

This would be feasible but the problem is inserting it in
the precedence rules of C

10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???

There are enomous problems with this approach, and for exponentiation
I think it is just not worth the effort, unless we devise a general
rule about adding new operators.

 

[Jordan Abel]

Richard Heathfield a écrit :

Granted, both operator overloading and function calls are the
same. The difference is syntax. In a function call even
if the function is overloaded you have a monadic (single
argument operator)

You don't seem to see the distinction between overloading a function and
overloading the function-call operator.

FUNCTION '(' arguments ... ')'

An operator can be monadic like above:
! arguments of the NOT operator
or DYADIC

arguments operator arguments

like

2 + 3

The purported exponentiation operator would have to be dyadic:

10 ^^ 3 --> 1000

it'd probably be **, but

10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???

There are enomous problems with this approach, and for exponentiation
I think it is just not worth the effort, unless we devise a general
rule about adding new operators.

Nobody suggested adding a new operator - only overloading pow().

 

[Chuck F.]

(e-mail address removed) a écrit :

God you are totally confused!!!

1) The OP (see the TITLE of this thread) asked why there isn't
an exponentiation operator in C. 2) He was redirected to the FAQ
that says that there isn't since there is no hardware support
for that operator. It is the FAQ that says it, not the OP. 3)
The OP critized the FAQ, saying (rightly so in my opinion) that
C is not tied to hardware.

No, you are. Based on the context included in the various
messages, only your point 1) is valid. The rest was not quoted,
and thus not necessarily available to Mr. Slebetman.

The FAQ points out a perfectly valid reason for omitting any sort
of exponentiation operator. C is not alone among languages in
doing this. Exponentiation is not the most prevalent of operators,
and is normally a subroutine in almost any language.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Eric Sosman]

[...]
The purported exponentiation operator would have to be dyadic:

10 ^^ 3 --> 1000

This would be feasible but the problem is inserting it in
the precedence rules of C

10+4 ^^ 4+5 --> pow(14,9) ? or 10+pow(4,4)+5 ???

There are enomous problems with this approach, and for exponentiation
I think it is just not worth the effort, unless we devise a general
rule about adding new operators.

The "enomous [sic] problems" you mention had already been
solved when I began programming thirty-nine years ago. In
FORTRAN the `**' operator means exponentiation, and binds more
tightly than multiplication and division but less tightly than
parentheses and function calls. Expressions in FORTRAN are
structurally similar to those in C, and I'm confident a similar
precedence rule could be worked out easily.

But perhaps I'm abusing you needlessly and owe an apology;
you may be referring to the problems of adding user-defined
operators on the fly and at the programmer's whim. Those would
indeed be "enomous" problems! But perhaps we need not generalize
from a question about one obviously missing operator to the issue
of accommodating every conceivable (and ill-conceived) operator
a programmer's diseased mind can imagine. If you want APL, you
know where to find it. ;-)

 

[Chris Torek]

... In FORTRAN the `**' operator means exponentiation, and binds more
tightly than multiplication and division but less tightly than
parentheses and function calls.

(And, if I recall correctly, is non-associative as well: A**B**C
is an error.)

But perhaps I'm abusing you needlessly and owe an apology;
you may be referring to the problems of adding user-defined
operators on the fly and at the programmer's whim. Those would
indeed be "enomous" problems!

Although these, too, have been solved (for some definition of
"solved" anyway) in other languages.

But perhaps we need not generalize
from a question about one obviously missing operator to the issue
of accommodating every conceivable (and ill-conceived) operator
a programmer's diseased mind can imagine. If you want APL, you
know where to find it. ;-)

It, I think, is worth noting that APL -- a language designed by a
mathematician -- avoids the whole operator binding ("precedence
and associativity") problem by defining it away. Operators are
handled strictly in textual order, right to left. For instance,

* 3 + 4 (iota) 7

is handled as:

iota 7: produces the vector 1 2 3 4 5 6 7
+ 4 [vector]: produces the vector 5 6 7 8 9 10 11
* 3 [vector]: produces the vector 15 18 21 24 27 30 33

Also, as I think someone else mentioned in this thread, APL provides
sort operators (grade-up, which sorts into ascending order, and
grade-down, which sorts into descending order).

If you write pure functions (or ignore possible control flow and
"global variable" problems due to errors), the difference between
"function" and "operator" is mere syntax. A good programmer should
be comfortable with all three of these:

(* 2 (+ 3 4)) # functions, e.g., Lisp
2 3 4 + * # RPN, e.g., PostScript, FORTH
2 * 3 + 4 # "conventional" infix

This does not mean you cannot *prefer* one form over another (even
Lisp programmers write fancy macros), but there is no significant
difference. The spelling does not matter as much as the semantics.
Note that, on some machines (V7-and-earlier SPARC for instance):

int i, j, result;
...
result = i * j;

compiles to a subroutine call ("call .mul"), rather than a multiply
instruction, and:

size_t size;
size = sizeof(i);

compiles to a simple assignment, despite "sizeof(i)"'s resemblance
to a call to a function.

 

[slebetman]

(e-mail address removed) a écrit :

God you are totally confused!!!

1) The OP (see the TITLE of this thread) asked why there isn't
an exponentiation operator in C.
2) He was redirected to the FAQ that says that there isn't since there
is no hardware support for that operator. It is the FAQ that says
it, not the OP.
3) The OP critized the FAQ, saying (rightly so in my opinion) that
C is not tied to hardware.

You mess completely!

OK, here's the OP's complete post:

That is not an answer, just an excuse. It links language operators to
presence or absence of hardware. C is not assembly language.
Translation is the job of something called a compiler.

Apart from the title, where is the mention of the FAQ? Where is the
quote of the reply the OP was critisizing?