exponentiation operator (lack of)

[Jack Klein]

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).

People are entitled to their own opinions, no matter how wrong they
are, so they can differ all they want. And beg all they want, for
that matter.

As someone who has been fluent in many, many assembly languages over
the years, I am qualified to say that those who refer to C as "a high
level assembler" are generally trying to deprecate the language. And
they are wrong.

C is vastly superior to most assembly languages in many ways, and
certainly inferior to most of them in other ways.

 

[Malcolm]

Either the right operand has to be an integer, making it equivalent to
repeated multiplication, or the right operand can be floating-point,
making it equivalent to pow() (or powf() or powl()). Pick one.

I'd go for the first.
That way you can write x^^-1 and get a division for the cost of a single
multiplication.

 

[Mark McIntyre]

Mark McIntyre a écrit :

Well, frankly this is nonsense. Why do you not post sensible things?
Is it some sort of fetish?

Echoing other peoples posts is pretty childish don't you think?

And do you deny that C was designed to be 'close to the metal' ?

 

[Giannis Papadopoulos]

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.

I tend to use log() a lot and exp(). And they are extremely useful to
engineers. Should that be implemented too using some kind of a primitive
operator? Different people use different operators, actions, functions
or whatever. Even complex.h is too much...

One could easily write a new function that replaces pow() in his own
projects (either simple or aimed to super-computers and extreme
computations) that has the proper assembly calls for his system. And
that would be a more elegant solution.

If you want simplicity and ease of coding, use pow(). Else write our own
exponentiation function.

PS ...and although XOR is not usual in numerical computation, it's not
unusual in low-level programming and systems programming, for which C
was initially implemented.

 

[jacob navia]

Mark McIntyre a écrit :

And do you deny that C was designed to be 'close to the metal' ?

No, but it is surely NOT assembly language, and it is not determined
by hardware considerations.

The OP sentence:

> C is not assembly language

is perfectly true.

You answer:

"Read a history book"

what implies that you would contest that affirmation, what is
surely nonsense. C is NOT assembly language, either from
the syntax (completely different) or the semantics (C handles
concepts like structures, local variables, etc etc).

Of course C is close to the basic hardware, closer than many
other languages maybe, but that surely doesn't make it
"assembly language" !

Of course *all* languages are assembly language in the
sense that eventually they must be translated into some
machine instructions to run, but then, you can say that
Smalltalk is assembly language too.

I stay with my critic: C is not assembly language.

jacob

 

[jacob navia]

Jack Klein a écrit :

[snip]

As someone who has been fluent in many, many assembly languages over
the years, I am qualified to say that those who refer to C as "a high
level assembler" are generally trying to deprecate the language. And
they are wrong.

C is vastly superior to most assembly languages in many ways, and
certainly inferior to most of them in other ways.

I would like to underline this. I think the idea of C as a
"High level assembler" was introduced by Betrand Meyer, with
his language Eiffel.

B.M. was too lazy to make a direct Eiffel-->assembler compiler,
and used C to implement Eiffel. (As many other languages do).

This allowed Eiffel to be written without much effort, but
produced other problems, since, for instance, they could not
detect integer overflow... Yes, C is certainly inferior to
many assemblers in some ways!!!

 

[slebetman]

Eric Sosman a écrit :

jacob navia wrote:

The "enomous [sic] problems" you mention had already been
solved when I began programming thirty-nine years ago.

2**3**4
is an error in fortran. Should that be also the case in C?

Which is why, IMHO, I think the current pow() function is better:

pow(2,pow(3,4));

In fact, it even avoids confusion with:

pow(pow(2,3),4);

 

[slebetman]

Eric Sosman a écrit :

jacob navia wrote:

[...]
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.

2**3**4
is an error in fortran. Should that be also the case in C?

2|3|4 is legal C... Should the operator ** be the same?
Besides, ** is not really good since it is easily mistaken with
multiply by the dereferenced pointre:

a**b is
(a)*(*b)
or
(a)**(b) ???

Etc etc. Once you start you will see it is NOT that easy.

<snip>

Either the right operand has to be an integer, making it equivalent to
repeated multiplication, or the right operand can be floating-point,
making it equivalent to pow() (or powf() or powl()). Pick one.

Of course, in C++ you'd overload pow() with a pow(double, int) so that
if you supply an int as the right integer it will do the repeated
multiplication thing. I'd even overload it again with pow(int, int) for
cases where I want to avoid conversion problems. For C, powl() looks
like a good idea.

 

[Mark McIntyre]

Mark McIntyre a écrit :

No, but it is surely NOT assembly language, and it is not determined
by hardware considerations.

But it is.

I stay with my critic: C is not assembly language.

I never said it was. I said "read a history book".

 

[lawrence.jones]

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.

It's certainly feasible, but I don't know whether any compilers do
this. If exponentiation were a built-in operator, I think compiler
writers would have been more strongly motivated to optimize it along
with expression evaluation in general.

I doubt it. Implementers targeting numerical applications are going to
be motivated in either case, implementers who don't care about numerical
applications aren't going to be motivated in either case. Certainly
having the str* and mem* functions as functions rather than operators
hasn't prevented many compilers from implementing them as optimized
intrinsics.

-Larry Jones

When you're SERIOUS about having fun, it's not much fun at all! -- Calvin

 

[Nils Weller]

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 Weller]

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

Oops - #define expr _Expo

 

[Keith Thompson]

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.

 

[Dik T. Winter]

>
> it'd probably be **, but

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

 

[Dik T. Winter]

>
> (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).

 

[Keith Thompson]

it'd probably be **, but

I think not. ** has also a good meaning (double indirection).[/QUOTE]

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.

 

[Mark L Pappin]

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)

 

[Richard Bos]

Read a history book...

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

Richard

 

[Keith Thompson]

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.)

 

[Richard Bos]

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