Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

exponentiation operator (lack of)

 
 
Christian Bau
Guest
Posts: n/a
 
      12-23-2005
In article <(E-Mail Removed) .com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> If we were going to add an exponentiation operator to C, we couldn't
> use "**" without breaking existing code. *x**y already means x * *y.


To be honest, anyone writing x**y would only get what they deserve if
their code is broken. Now if you can come up with an example where the
character sequence ** would change its meaning and still compile...

(I am assuming that number ** pointer would be an error that the
compiler has to catch).
 
Reply With Quote
 
 
 
 
lawrence.jones@ugs.com
Guest
Posts: n/a
 
      12-23-2005
Eric Sosman <(E-Mail Removed)> wrote:
>
> The operator I miss even more than exponentiation is
> "integer multiply producing double-width product."


The operator is "*". It's fairly simple for a compiler to recognize:

int i, j;
long l;
...
l = (long)i * j;

and avoid the needless widening of i and j.

-Larry Jones

Fortunately, that was our plan from the start. -- Calvin
 
Reply With Quote
 
 
 
 
lawrence.jones@ugs.com
Guest
Posts: n/a
 
      12-23-2005
Keith Thompson <(E-Mail Removed)> wrote:
>
> It wouldn't have been entirely unreasonable to have a built-in
> exponentiation operator in C. If it had been there from the
> beginning, x**y wouldn't have been a problem; if you wanted x * *y,
> you'd have to insert a space. It would provide some opportunities for
> optimization that a function doesn't; for example, x**2 can be
> translated to a simple multiplication, and x**16 can be implemented as
> a sequence of 4 multiplications rather than 15.


There's nothing preventing a compiler from optimizing calls to the pow()
function the same way.

-Larry Jones

I don't think math is a science, I think it's a religion. -- Calvin
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-23-2005
(E-Mail Removed) writes:
> 18.Keith ThompsonDec 23, 12:08pm show options
> Newsgroups: comp.lang.c
> From: Keith Thompson <(E-Mail Removed)> - Find messages by this author
> Date: Fri, 23 Dec 2005 19:08:11 GMT
> Local: Fri, Dec 23 2005 12:08pm
> Subject: Re: exponentiation operator (lack of)
> Reply |Reply to Author| Forward| Print| Individual Message| Show
> original| Report Abuse

[snip]

Thank you for trying to quote using the broken Google interface, but
there's a much better way to do it.

See <http://cfaj.freeshell.org/google/>.

--
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
 
Keith Thompson
Guest
Posts: n/a
 
      12-23-2005
(E-Mail Removed) writes:
> Keith Thompson <(E-Mail Removed)> wrote:
>> It wouldn't have been entirely unreasonable to have a built-in
>> exponentiation operator in C. If it had been there from the
>> beginning, x**y wouldn't have been a problem; if you wanted x * *y,
>> you'd have to insert a space. It would provide some opportunities for
>> optimization that a function doesn't; for example, x**2 can be
>> translated to a simple multiplication, and x**16 can be implemented as
>> a sequence of 4 multiplications rather than 15.

>
> 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. The compiler would have to recognize that the second
argument is an integer; in that case, rather than converting it to
double, it would replace the call with code to do repeated
multiplication or whatever is most efficient, or perhaps just a call
to another function that takes an integer as its second argument.

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.

--
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 McIntyre
Guest
Posts: n/a
 
      12-24-2005
On Fri, 23 Dec 2005 10:55:33 +0100, in comp.lang.c , jacob navia
<(E-Mail Removed)> wrote:

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


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

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

>That is not an answer, just an excuse.


So?There are lots of mathematical operators that C doesn't define, and
if you look closely, you'll notice that pretty much all of them are
ones you don't find hardware support for except in specialist math
chips. There are also missing operators for 'obvious' things like
addings two strings, adding two arrays, multiplying two matrices etc.
And why isn't there a dot-product operator and a cross-product
operator? I'm sure physicists would find them handy.

>C is not assembly language.


Read a history book...

----== 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 =----
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-24-2005
Mark McIntyre a écrit :
> 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...


Well, frankly this is nonsense. Why do you not post sensible things?
Is it some sort of fetish?
 
Reply With Quote
 
Bart C
Guest
Posts: n/a
 
      12-24-2005
"jacob navia" <(E-Mail Removed)> wrote in message
news:43abcc18$0$19674$(E-Mail Removed)...

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


Obviously exponentiation has to have a higher priority than +,-,* or /,
because that's the case with algebra.

And perhaps evaluated right-to-left too, so 10**10**2 is 10**(10**2).

Ideally a superscript would be used, but I can see that has certain
difficulties. With ** ambiguous and ^ taken, ^^ is a good alternative,
although I don't see why an operator has to be a symbol, why not:

10 + 4 pow 4 + 5 ?

What about using ^ as exponentiation operator when either operand is float?

Bart



 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      12-24-2005
On 22 Dec 2005 10:39:06 -0800, (E-Mail Removed) wrote in
comp.lang.c:

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


There is one. It's named pow(). How is pow(x, y) any more or less
primitive than x ** y?

> And, are there requests to do so in the next std revision?


No, we already have pow(), and it does what we need.

> 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


What C++ does or does not do is not relevant here.

What do you think happens when you use the exponentiation operator in
Fortran or Pascal? Perhaps on a very few hardware architectures a
short sequence of floating point unit instructions are added in line.
On most others, a run time support library routine is called.

Nothing at all prevents a C compiler for appropriate architectures to
make the function intrinsic and generate the same in line.

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


So what?

By the way, the place to propose new features to the language or the
standard library is news:comp.std.c, not here.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
 
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