Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

exponentiation operator (lack of)

 
 
jacob navia
Guest
Posts: n/a
 
      12-27-2005
Richard Bos a écrit :
> Mark McIntyre <(E-Mail Removed)> wrote:
>
>
>>On 22 Dec 2005 11:02:43 -0800, in comp.lang.c , http://www.velocityreviews.com/forums/(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


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
 
Reply With Quote
 
 
 
 
Mark McIntyre
Guest
Posts: n/a
 
      12-27-2005
On Tue, 27 Dec 2005 08:02:12 GMT, in comp.lang.c ,
(E-Mail Removed) (Richard Bos) wrote:

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


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 =----
 
Reply With Quote
 
 
 
 
=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=
Guest
Posts: n/a
 
      12-30-2005
(E-Mail Removed) 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 - (E-Mail Removed)
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-30-2005
(E-Mail Removed) (Dag-Erling Smørgrav) writes:
> (E-Mail Removed) 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) (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
 
Eric Sosman
Guest
Posts: n/a
 
      12-30-2005
Dag-Erling Smørgrav wrote:
> (E-Mail Removed) 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
(E-Mail Removed)lid
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      01-03-2006

In article <(E-Mail Removed)>, Keith Thompson <(E-Mail Removed)> writes:
> (E-Mail Removed) (Dag-Erling Smørgrav) writes:
> > (E-Mail Removed) 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 (E-Mail Removed)

Web 2.0 is ... like talking to people - without the pesky annoyance of
other people. -- Martin Wood
 
Reply With Quote
 
Markus Becker
Guest
Posts: n/a
 
      01-03-2006
Chris Torek <(E-Mail Removed)> 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
 
Reply With Quote
 
Dave Thompson
Guest
Posts: n/a
 
      01-04-2006
On 23 Dec 2005 18:14:06 GMT, Chris Torek <(E-Mail Removed)> 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
 
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