By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,963 Members | 920 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,963 IT Pros & Developers. It's quick & easy.

exponentiation operator (lack of)

P: n/a
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.

Dec 22 '05
Share this Question
Share on Google+
67 Replies


P: n/a
On 2005-12-23, Eric Sosman <er*********@sun.com> wrote:
This is just a question of spelling. Obviously you
can't grab ** or ^ or % to be C's exponentiation operator;
they're already taken for other purposes. # would almost
work, but there'd be niggling problems with line boundaries.
$ would work, but there's a distaste for national characters.
Someone has already suggested ^^, and I think @ would also
be all right. The only question here is the choice of a
character combination that isn't already in use and has
some amount of mnemonic value. We could even do without
the mnemonic: nobody seems to complain about % even though
it's not very suggestive of "remainder."


What about making new operators keywords, like ``sizeof''?

a _Expo b;

Plus maybe something like

#include <funnyops.h> /* typedef _Expo expo; */

a expo b;

--
Nils R. Weller, Bremen (Germany)
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
Dec 24 '05 #51

P: n/a
On 2005-12-24, Nils Weller <me@privacy.net> wrote:
#include <funnyops.h> /* typedef _Expo expo; */


Oops - #define expr _Expo
--
Nils R. Weller, Bremen (Germany)
My real email address is ``nils<at>gnulinux<dot>nl''
.... but I'm not speaking for the Software Libre Foundation!
Dec 24 '05 #52

P: n/a
la************@ugs.com writes:
Keith Thompson <ks***@mib.org> wrote [quoting me]:
There's nothing preventing a compiler from optimizing calls to the pow()
function the same way.


It's slightly more difficult, since both arguments of pow() are
floating-point.


If the compiler implements pow() as an intrinsic, it's free to provide
different implementations based on the actual (unconverted) argument
types rather than promoting everything to double.


Thus the phrase "slightly more difficult". If you think I should have
written "very slightly more difficult", I won't argue with you.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 24 '05 #53

P: n/a
In article <sl********************@random.yi.org> Jordan Abel <jm****@purdue.edu> writes:
....
10 ^^ 3 --> 1000


it'd probably be **, but


I think not. ** has also a good meaning (double indirection).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dec 26 '05 #54

P: n/a
In article <do*********@news1.newsguy.com> Chris Torek <no****@torek.net> writes:
In article <RY********************@comcast.com>
Eric Sosman <es*****@acm-dot-org.invalid> wrote:
... 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.)


It is not an error, but it is indeed non-associative. It binds from
right to left, so A**B**C is equivalent to A**(B**C).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dec 26 '05 #55

P: n/a
"Dik T. Winter" <Di********@cwi.nl> writes:
In article <sl********************@random.yi.org> Jordan Abel
<jm****@purdue.edu> writes:
...
> > 10 ^^ 3 --> 1000

>
> it'd probably be **, but


I think not. ** has also a good meaning (double indirection).


Sure, but ** is effectively a unary prefix operator, so that's no more
of a problem than the fact that multiplication and single indirection
use the same symbol. The real problem is that x**y mean x * *y.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 26 '05 #56

P: n/a
Keith Thompson <ks***@mib.org> writes:
"Dik T. Winter" <Di********@cwi.nl> writes:
Jordan Abel <jm****@purdue.edu> writes:
...
> > 10 ^^ 3 --> 1000
>
> it'd probably be **, but


I think not. ** has also a good meaning (double indirection).


Sure, but ** is effectively a unary prefix operator, so that's no more
of a problem than the fact that multiplication and single indirection
use the same symbol. The real problem is that x**y mean x * *y.


I don't see that this is a "real problem" at all.

It's been said a number of times: if 'y' is a pointer type, then the
latter parse is valid, but attempting to raise to the 'y'th power is
not (unless it is known that 'y' is null); conversely, if 'y' is a
numeric type, then dereferencing it is not valid. Agreed, this
disambiguation can't be done at the token level without whitespace,
but neither can 'x++++y' (C's greedy lexer MUST give the syntactically
invalid 'x++ ++y', even though 'x++ + +y' is kosher).

mlp
(playing Devil's Advocate here - I think the exponentiation operator
that C already has (a.k.a. 'pow()') is fine)
Dec 26 '05 #57

P: n/a
Mark McIntyre <ma**********@spamcop.net> wrote:
On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , ca****@colorado.edu
wrote:
C is not assembly language.


Read a history book... :-)


Get a clue. You are not an Ada advocate; you are therefore not supposed
to be this stupid.

Richard
Dec 27 '05 #58

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Mark McIntyre <ma**********@spamcop.net> wrote:
On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , ca****@colorado.edu
wrote:
>C is not assembly language.


Read a history book... :-)


Get a clue. You are not an Ada advocate; you are therefore not supposed
to be this stupid.


I suggest that dragging an Ada vs. C debate into this would be a
really bad idea. (I worked with Ada myself for many years; I don't
advocate it here, but attacking it is no more topical here than
advocating it would be.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 27 '05 #59

P: n/a
Keith Thompson <ks***@mib.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Mark McIntyre <ma**********@spamcop.net> wrote:
On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , ca****@colorado.edu
wrote:
>C is not assembly language.

Read a history book... :-)


Get a clue. You are not an Ada advocate; you are therefore not supposed
to be this stupid.


I suggest that dragging an Ada vs. C debate into this would be a
really bad idea.


I'm not advocating C over Ada; I'm advocating real users of either
language over advocates.

Richard
Dec 27 '05 #60

P: n/a
Richard Bos a écrit :
Mark McIntyre <ma**********@spamcop.net> wrote:

On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , ca****@colorado.edu
wrote:

C is not assembly language.


Read a history book... :-)

Get a clue. You are not an Ada advocate; you are therefore not supposed
to be this stupid.

Richard


This is OFF TOPIC.

If anything is OFF TOPIC here, insults are.
Please let's keep manners.

You disagree with Mark?

Tell him so, but do it without insults, or attacks.

Thanks in advance for your understanding.

jacob
Dec 27 '05 #61

P: n/a
On Tue, 27 Dec 2005 08:02:12 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Mark McIntyre <ma**********@spamcop.net> wrote:
On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , ca****@colorado.edu
wrote:
>C is not assembly language.


Read a history book... :-)


Get a clue. You are not an Ada advocate; you are therefore not supposed
to be this stupid.


No idea if thats addressed at me or Carlos, but either way, C was
written to be a higher level language than the assembler that Thompson
et al were otherwise forced to use on the PDP-7, yet compact and
simple enough to fit into the very limited memory available. The
original language was deliberately close to the machine, using
concrete data types and operators which existed on the target h/w.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Dec 27 '05 #62

P: n/a
ca****@colorado.edu writes:
Giving this ongoing enlargement in the scope of C applications,
I see no reason why a new operator (** or ^^) could not be
introduced to meet those needs either in a future standard, or
in a "successor to C" , as discussed in another thread.


Alright, it's quiz time. Consider the following program:

#include <stdio.h>

int main(void)
{
int a = 2, b = 3;
int *bp = &b;

printf("%d\n", a**bp);
return 0;
}

1) what is the effect of the above code?

2) explain the relationship between the & and && operators

3) explain the relationship between the ^ and ^^ operators

4) explain the relationship between the | and || operators

5) which of the above is a trick question?

DES
--
Dag-Erling Smørgrav - de*@des.no
Dec 30 '05 #63

P: n/a
de*@des.no (Dag-Erling Smørgrav) writes:
ca****@colorado.edu writes:
Giving this ongoing enlargement in the scope of C applications,
I see no reason why a new operator (** or ^^) could not be
introduced to meet those needs either in a future standard, or
in a "successor to C" , as discussed in another thread.


Alright, it's quiz time. Consider the following program:

#include <stdio.h>

int main(void)
{
int a = 2, b = 3;
int *bp = &b;

printf("%d\n", a**bp);
return 0;
}

1) what is the effect of the above code?
2) explain the relationship between the & and && operators
3) explain the relationship between the ^ and ^^ operators
4) explain the relationship between the | and || operators
5) which of the above is a trick question?


I think that the first person to implement the short-circuit xor
operator will become nearly as rich as the first person to invent a
way to factor large primes.

(My own "exclusive-and" operator (A and B but not both) is a small
step in this direction.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Dec 30 '05 #64

P: n/a
Dag-Erling Smørgrav wrote:
ca****@colorado.edu writes:
Giving this ongoing enlargement in the scope of C applications,
I see no reason why a new operator (** or ^^) could not be
introduced to meet those needs either in a future standard, or
in a "successor to C" , as discussed in another thread.

Alright, it's quiz time. Consider the following program:

#include <stdio.h>

int main(void)
{
int a = 2, b = 3;
int *bp = &b;

printf("%d\n", a**bp);
return 0;
}

1) what is the effect of the above code?


If compiled and executed by a C implementation
conforming to any version of the Standard, as amended,
it attempts to write the digit '6' and a newline '\n'
to the standard output stream. Whether this attempt
succeeds or not, it then attempts to close all open
streams (including the standard output) and returns an
implementation-defined "success" indication to the
environment.
2) explain the relationship between the & and && operators
They are both C operators.
3) explain the relationship between the ^ and ^^ operators
One is a C operator, one is not. They are related
by their antipathy, like Don Carlo and Don Alvaro.
4) explain the relationship between the | and || operators
They are both C operators.
5) which of the above is a trick question?


Number 5.

--
Eric Sosman
es*****@acm-dot-org.invalid
Dec 30 '05 #65

P: n/a

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:
de*@des.no (Dag-Erling Smørgrav) writes:
ca****@colorado.edu writes:
I see no reason why a new operator (** or ^^) could not be
introduced to meet those needs either in a future standard, or
in a "successor to C" , as discussed in another thread.


2) explain the relationship between the & and && operators
3) explain the relationship between the ^ and ^^ operators
4) explain the relationship between the | and || operators
5) which of the above is a trick question?


I think that the first person to implement the short-circuit xor
operator will become nearly as rich as the first person to invent a
way to factor large primes.


Obviously, the logical-xor operator short-circuits when the result
is neither true nor false.

On a more serious note, short-circuiting is obviously not the
only characteristic which distinguishes the bitwise and logical
operators (| versus || and & versus &&), so while a "logical xor"
wouldn't short-circuit, it would still be distinct from bitwise
xor, and could have its own operator. There just isn't any call
for it.

--
Michael Wojcik mi************@microfocus.com

Web 2.0 is ... like talking to people - without the pesky annoyance of
other people. -- Martin Wood
Jan 3 '06 #66

P: n/a
Chris Torek <no****@torek.net> schrieb:
size_t size;
size = sizeof(i);

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


Some people seem to have too much parentheses. I'm sure you
know that, but just for the record: 'sizeof' is an operator,
not a function and therefore it's not especially astonishing
that it does not generate a function call.

int i;
i = -(1);

won't generate one either.

Markus
Jan 3 '06 #67

P: n/a
On 23 Dec 2005 18:14:06 GMT, Chris Torek <no****@torek.net> wrote:

<snip>
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

Almost. APL is written infix (for this example 3 x 4 + iota 7)
but with no precedence (or equivalently all the same precedence) for
dyadic and right associative so they execute right-to-left except if
overridden by parentheses; and prefix are inherently right to left
(and unambiguously parsed), and there are no postfix.

For additional confusion APL follows mathematical terminology in
calling things like + and x that operate on data 'functions' and using
'operators' for things that operate _on functions_ e.g. slash for
reduce in 'plus slash times' for dot-product. C has no direct analog
builtin of such, and C++ only a pale imitation in bind1st etc.,
although in both you can write functions that take a pointer to
function and do something with it e.g. find_zero_of (func_ptr_t).

- David.Thompson1 at worldnet.att.net
Jan 4 '06 #68

67 Replies

This discussion thread is closed

Replies have been disabled for this discussion.