«

Jordan Abel a écrit :
> On 2005-12-23, <> wrote:
>
>>>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)
>>
>>Absolutely correct, but C++ does not have an exponentiation operator
>>to overload. I might be off base here since I use C++ very little,
>>but I dont think pow(..) is in the "overloadable" list.
>
>
> I believe functions can also be overloaded.

What's the use of overloading a function here?

I mean would you overload pow() ???

What's the point?

A function (overloaded or not) is not an operator!

a écrit :
>
> The OP I was replying to did not mention anything about exponentiation
> operator. He just said operators are linked to what is available in
> assembly.
>

God you are totally confused!!!

1) The OP (see the TITLE of this thread) asked why there isn't
an exponentiation operator in C.
2) He was redirected to the FAQ that says that there isn't since there
is no hardware support for that operator. It is the FAQ that says
it, not the OP.
3) The OP critized the FAQ, saying (rightly so in my opinion) that
C is not tied to hardware.

You mess completely!

jacob

osmium a écrit :
> "" writes:
>
>
>>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).
>
>
> This exposes one of the frailties of C++. The natural exponentiation
> operator, ^, has the precedence of exclusive or, which is far too low for
> the operation desired. Overloading it would be a disaster waiting to
> happen. You would have parens all over the place and if you forgot one
> there would probably be hell to pay in faulty results.
>
>

And we come to the point that I mentioned elsethread:

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.

jacob navia said:

<snip>

> A function (overloaded or not) is not an operator!

Actually, they're not all /that/ different, conceptually speaking. One can
think of qsort as the "sort" operator, strcmp as the "string comparison"
operator, foo as the "do the foo thing" operator, and so on. A function is
just God's way of letting us specify our own operators that can do whatever
we have the skill and imagination to write.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard Heathfield a écrit :
> jacob navia said:
>
> <snip>
>
>>A function (overloaded or not) is not an operator!
>
>
> Actually, they're not all /that/ different, conceptually speaking. One can
> think of qsort as the "sort" operator, strcmp as the "string comparison"
> operator, foo as the "do the foo thing" operator, and so on. A function is
> just God's way of letting us specify our own operators that can do whatever
> we have the skill and imagination to write.
>

Granted, both operator overloading and function calls are the
same. The difference is syntax. In a function call even
if the function is overloaded you have a monadic (single
argument operator)

FUNCTION '(' arguments ... ')'

An operator can be monadic like above:
! arguments of the NOT operator
or DYADIC

arguments operator arguments

like

2 + 3

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.

On 2005-12-23, jacob navia <> wrote:
> Richard Heathfield a écrit :
>> jacob navia said:
>>
>> <snip>
>>
>>>A function (overloaded or not) is not an operator!
>>
>>
>> Actually, they're not all /that/ different, conceptually speaking. One can
>> think of qsort as the "sort" operator, strcmp as the "string comparison"
>> operator, foo as the "do the foo thing" operator, and so on. A function is
>> just God's way of letting us specify our own operators that can do whatever
>> we have the skill and imagination to write.
>>
>
> Granted, both operator overloading and function calls are the
> same. The difference is syntax. In a function call even
> if the function is overloaded you have a monadic (single
> argument operator)

You don't seem to see the distinction between overloading a function and
overloading the function-call operator.

> FUNCTION '(' arguments ... ')'
>
> An operator can be monadic like above:
> ! arguments of the NOT operator
> or DYADIC
>
> arguments operator arguments
>
> like
>
> 2 + 3
>
> The purported exponentiation operator would have to be dyadic:
>
> 10 ^^ 3 --> 1000

it'd probably be **, but

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

Nobody suggested adding a new operator - only overloading pow().

jacob navia wrote:
> a écrit :
>>
>> The OP I was replying to did not mention anything about
>> exponentiation operator. He just said operators are linked to
>> what is available in assembly.
>
> God you are totally confused!!!
>
> 1) The OP (see the TITLE of this thread) asked why there isn't
> an exponentiation operator in C. 2) He was redirected to the FAQ
> that says that there isn't since there is no hardware support
> for that operator. It is the FAQ that says it, not the OP. 3)
> The OP critized the FAQ, saying (rightly so in my opinion) that
> C is not tied to hardware.

No, you are. Based on the context included in the various
messages, only your point 1) is valid. The rest was not quoted,
and thus not necessarily available to Mr. Slebetman.

The FAQ points out a perfectly valid reason for omitting any sort
of exponentiation operator. C is not alone among languages in
doing this. Exponentiation is not the most prevalent of operators,
and is normally a subroutine in almost any language.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

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. In
FORTRAN the `**' operator means exponentiation, and binds more
tightly than multiplication and division but less tightly than
parentheses and function calls. Expressions in FORTRAN are
structurally similar to those in C, and I'm confident a similar
precedence rule could be worked out easily.

But perhaps I'm abusing you needlessly and owe an apology;
you may be referring to the problems of adding user-defined
operators on the fly and at the programmer's whim. Those would
indeed be "enomous" problems! But perhaps we need not generalize
from a question about one obviously missing operator to the issue
of accommodating every conceivable (and ill-conceived) operator
a programmer's diseased mind can imagine. If you want APL, you
know where to find it.

--
Eric Sosman
lid

In article <RYOdnfwSj-tUmDHeRVn->
Eric Sosman <> 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.)

> But perhaps I'm abusing you needlessly and owe an apology;
>you may be referring to the problems of adding user-defined
>operators on the fly and at the programmer's whim. Those would
>indeed be "enomous" problems!

Although these, too, have been solved (for some definition of
"solved" anyway) in other languages.

>But perhaps we need not generalize
>from a question about one obviously missing operator to the issue
>of accommodating every conceivable (and ill-conceived) operator
>a programmer's diseased mind can imagine. If you want APL, you
>know where to find it.

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

Also, as I think someone else mentioned in this thread, APL provides
sort operators (grade-up, which sorts into ascending order, and
grade-down, which sorts into descending order).

If you write pure functions (or ignore possible control flow and
"global variable" problems due to errors), the difference between
"function" and "operator" is mere syntax. A good programmer should
be comfortable with all three of these:

(* 2 (+ 3 4)) # functions, e.g., Lisp
2 3 4 + * # RPN, e.g., PostScript, FORTH
2 * 3 + 4 # "conventional" infix

This does not mean you cannot *prefer* one form over another (even
Lisp programmers write fancy macros), but there is no significant
difference. The spelling does not matter as much as the semantics.
Note that, on some machines (V7-and-earlier SPARC for instance):

int i, j, result;
...
result = i * j;

compiles to a subroutine call ("call .mul"), rather than a multiply
instruction, and:

size_t size;
size = sizeof(i);

compiles to a simple assignment, despite "sizeof(i)"'s resemblance
to a call to a function.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

jacob navia wrote:
> a écrit :
> >
> > The OP I was replying to did not mention anything about exponentiation
> > operator. He just said operators are linked to what is available in
> > assembly.
> >
>
> God you are totally confused!!!
>
> 1) The OP (see the TITLE of this thread) asked why there isn't
> an exponentiation operator in C.
> 2) He was redirected to the FAQ that says that there isn't since there
> is no hardware support for that operator. It is the FAQ that says
> it, not the OP.
> 3) The OP critized the FAQ, saying (rightly so in my opinion) that
> C is not tied to hardware.
>
> You mess completely!
>

OK, here's the OP's complete post:

> That is not an answer, just an excuse. It links language operators to
> presence or absence of hardware. C is not assembly language.
> Translation is the job of something called a compiler.

Apart from the title, where is the mention of the FAQ? Where is the
quote of the reply the OP was critisizing?