Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > exponentiation operator (lack of)

Reply
Thread Tools

exponentiation operator (lack of)

 
 
Nils Weller
Guest
Posts: n/a
 
      12-24-2005
On 2005-12-23, Eric Sosman <(E-Mail Removed)> 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!
 
Reply With Quote
 
 
 
 
Nils Weller
Guest
Posts: n/a
 
      12-24-2005
On 2005-12-24, Nils Weller <(E-Mail Removed)> 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!
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-24-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> Keith Thompson <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      12-26-2005
In article <(E-Mail Removed)> Jordan Abel <(E-Mail Removed)> 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/
 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      12-26-2005
In article <(E-Mail Removed)> Chris Torek <(E-Mail Removed)> writes:
> In article <(E-Mail Removed)>
> Eric Sosman <(E-Mail Removed)> 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/
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-26-2005
"Dik T. Winter" <(E-Mail Removed)> writes:
> In article <(E-Mail Removed)> Jordan Abel
> <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Mark L Pappin
Guest
Posts: n/a
 
      12-26-2005
Keith Thompson <(E-Mail Removed)> writes:

> "Dik T. Winter" <(E-Mail Removed)> writes:
> > Jordan Abel <(E-Mail Removed)> 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)
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      12-27-2005
Mark McIntyre <(E-Mail Removed)> wrote:

> On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , (E-Mail Removed)
> 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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-27-2005
(E-Mail Removed) (Richard Bos) writes:
> Mark McIntyre <(E-Mail Removed)> wrote:
>> On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , (E-Mail Removed)
>> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      12-27-2005
Keith Thompson <(E-Mail Removed)> wrote:

> (E-Mail Removed) (Richard Bos) writes:
> > Mark McIntyre <(E-Mail Removed)> wrote:
> >> On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , (E-Mail Removed)
> >> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Operator precedence of exponentiation (**) and complement (~) Andrew Savige Ruby 2 03-26-2009 08:03 PM
Decimal and Exponentiation elventear Python 7 05-20-2006 07:04 PM
An exponentiation function for int? Steven T. Hatton C++ 14 10-16-2004 12:23 AM
RE: strange exponentiation performance Tim Peters Python 1 11-24-2003 06:35 AM
strange exponentiation performance Jeff Davis Python 0 11-23-2003 11:31 AM



Advertisments