exponentiation operator (lack of)

Discussion in 'C Programming' started by carlos@colorado.edu, Dec 22, 2005.

  1. Guest

    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.
    , Dec 22, 2005
    #1
    1. Advertising

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


    You should read the FAQ before posting, this is answered in question
    14.7, see http://www.eskimo.com/~scs/C-faq/q14.7.html for the answer.

    Robert Gamble
    Robert Gamble, Dec 22, 2005
    #2
    1. Advertising

  3. Guest

    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.
    , Dec 22, 2005
    #3
  4. Artie Gold Guest

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

    1) You have failed to quote sufficient context -- for which Google's
    broken Usenet interface is no excuse.
    2) You were directed to an answer -- in the FAQ, which you should have
    read *before* asking your original question.
    3) This newsgroup is primarily concerned with the ISO C language as it
    *is*. If you want it to be different, the proper place for such
    discussions is news:comp.std.c.

    Further, I recommend you do some reading on the history of the C
    language, why it was created, what was its intended purpose, etc. That
    may provide insight into the design decisions made.

    HTH,
    --ag

    --
    Artie Gold -- Austin, Texas
    http://goldsays.blogspot.com
    http://www.cafepress.com/goldsays
    "If you have nothing to hide, you're not trying!"
    Artie Gold, Dec 22, 2005
    #4
  5. Guest

    wrote:
    > C is not assembly language.


    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).
    , Dec 22, 2005
    #5
  6. jacob navia Guest

    a écrit :
    > wrote:
    >
    >>C is not assembly language.

    >
    >
    > 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 is the old story supported by many people around here.

    C is dead and everybody should move to the "higher" level, C++.

    This justifies trying to deny C any evolution possibilities, and
    keeping the discussion in this group as "low level" as
    possible.

    The OP question is a good one. Personally I do not think we need a new
    exponentiation operator, and in lcc-win32 there is operator overloading,
    but those are not answers to the OP question.

    May I remind you that the supposedly "higher" level C++ doesn't
    have an exponentiation operator EITHER ???

    I think the answer is that the enormous problem of introducing a
    new operator, with all the complications of the 15 levels of
    precedence of C makes the introduction of an ^^ operator an
    herculean task, one that nobody has attempted, and probably never
    will.

    Let's stop the nonsense and tell the truth for one.

    jacob
    jacob navia, Dec 22, 2005
    #6
  7. Guest

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

    As regards gradual departure of C from assembly, let me note that
    C99 offers a built-in complex type and associated operators.
    Those are not part of any widely used assembly language
    instruction set, although they can be microcoded in some
    embedded systems.
    , Dec 23, 2005
    #7
  8. osmium Guest

    "" 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.
    osmium, Dec 23, 2005
    #8
  9. Guest

    jacob navia wrote:
    > a écrit :
    > > wrote:
    > >
    > >>C is not assembly language.

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

    > <snip>
    >
    > May I remind you that the supposedly "higher" level C++ doesn't
    > have an exponentiation operator EITHER ???
    >


    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.
    , Dec 23, 2005
    #9
  10. Jordan Abel Guest

    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.
    Jordan Abel, Dec 23, 2005
    #10
  11. jacob navia Guest

    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!
    jacob navia, Dec 23, 2005
    #11
  12. jacob navia Guest

    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
    jacob navia, Dec 23, 2005
    #12
  13. jacob navia Guest

    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, Dec 23, 2005
    #13
  14. 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, Dec 23, 2005
    #14
  15. jacob navia Guest

    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.
    jacob navia, Dec 23, 2005
    #15
  16. Jordan Abel Guest

    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().
    Jordan Abel, Dec 23, 2005
    #16
  17. Chuck F. Guest

    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
    Chuck F., Dec 23, 2005
    #17
  18. Eric Sosman Guest

    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
    Eric Sosman, Dec 23, 2005
    #18
  19. Chris Torek Guest

    In article <>
    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.
    Chris Torek, Dec 23, 2005
    #19
  20. Guest

    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?
    , Dec 23, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven T. Hatton

    An exponentiation function for int?

    Steven T. Hatton, Oct 13, 2004, in forum: C++
    Replies:
    14
    Views:
    730
    JXStern
    Oct 16, 2004
  2. Jeff Davis

    strange exponentiation performance

    Jeff Davis, Nov 23, 2003, in forum: Python
    Replies:
    0
    Views:
    333
    Jeff Davis
    Nov 23, 2003
  3. Tim Peters
    Replies:
    1
    Views:
    425
    Jeff Davis
    Nov 24, 2003
  4. elventear

    Decimal and Exponentiation

    elventear, May 19, 2006, in forum: Python
    Replies:
    7
    Views:
    629
    Tim Peters
    May 20, 2006
  5. Andrew Savige
    Replies:
    2
    Views:
    233
    Andrew Savige
    Mar 26, 2009
Loading...

Share This Page