sdw@hpsad.HP.COM (Steve Warwick) (06/22/91)
when ATT built the complex class, C++ became my favourite language for numerical processing and analysis. however, I'm still looking for one little friend, the power symbol "^" as in 10^5, x^y. Can/Has someone defined a set of friend functions for integer/double/complex numbers ? thanks sdw@hpsad.hp.com
horstman@mathcs.sjsu.edu (Cay Horstmann) (06/22/91)
In article <1920003@hpsad.HP.COM> sdw@hpsad.HP.COM (Steve Warwick) writes: >when ATT built the complex class, C++ became my favourite language for numerical processing and analysis. however, I'm still looking for one little friend, >the power symbol "^" as in 10^5, x^y. Can/Has someone defined a set of >friend functions for integer/double/complex numbers ? > There is a good reason that ^ is usually not used for exponentiation. Its precedence is wrong. For example, y = x ^ 2 + 1 is actually y = x ^ (2+1) which is not very intuitive and can lead to frustrating errors. Cay
pete@borland.com (Pete Becker) (06/23/91)
In article <1920003@hpsad.HP.COM> sdw@hpsad.HP.COM (Steve Warwick) writes: >when ATT built the complex class, C++ became my favourite language for numerical processing and analysis. however, I'm still looking for one little friend, >the power symbol "^" as in 10^5, x^y. Can/Has someone defined a set of >friend functions for integer/double/complex numbers ? I haven't looked, but there's a danger in using ^ for exponentiation. It doesn't group the way it should! In C++, ^ groups from left to right, just as in C. But when doing exponentiation, it should go the other way. A^B^C is evaluated as (A^B)^C, which is not at all the same as A^(B^C).
robert@am.dsir.govt.nz (Robert Davies) (06/24/91)
Wouldn't it be nice if C++ introduced a new operator - eg @ or @@ for taking powers. eg 2 @@ 3 would be 8. As already noted, I think it is very dangerous to use ^ as an overloaded operator for taking powers. Especially as 2 ^ 3 gets something completely different. (I know that C was considered to difficult/dangerous for numerical people who should stick to Fortran, so there was no need for a power operator. But with C++ perhaps this policy should be reconsidered.) Robert
sdw@hpsad.HP.COM (Steve Warwick) (06/25/91)
The fact that overloaded operators inheret the precedence of the underlying operator has always seemed strange to me - it seems to retrict the meaning of "overloading" and "operator definition", although from the standpoint of readability, it seems like the right thing to do. For my purposes, making a pre-defined power operator a part of the language would go a long way to obsoleting F**TRAN, since so many other problems have been so elegently solved However, people seem to like C++ as a "meta language", so a generic operator definition feature fits the style better.... This is a case where having the ability to define an operator, such as "^^" or "@@" makes sense. ( also with a reletive precedence and grouping preference ).
etj90@ecs.soton.ac.uk (Khaos) (06/26/91)
In <1920004@hpsad.HP.COM> sdw@hpsad.HP.COM (Steve Warwick) writes: >The fact that overloaded operators inheret the precedence of the >underlying operator has always seemed strange to me - it seems to >retrict the meaning of "overloading" and "operator definition", >although from the standpoint of readability, it seems like the right >thing to do. >For my purposes, making a pre-defined power operator a part of the >language would go a long way to obsoleting F**TRAN, since so many >other problems have been so elegently solved >However, people seem to like C++ as a "meta language", so a generic >operator definition feature fits the style better.... >This is a case where having the ability to define an operator, >such as "^^" or "@@" makes sense. ( also with a reletive precedence and >grouping preference ). This just gave me a Thought. Defining your own "meta-operators" would allow you to define things that aren't a normal language thing at all, such as foo@bar would allow you to e.g. booleanly test for the existence of foo in your Object bar (a database of some sort). If this is too woolly and 7th generation language-y then ignore it but defining your own operators (although I think retaining priorities of overloaded op's is a good idea) would be REELY K00L. Enough ranting. -- Quote: "I am Khaos !" \007, licensed to beep.
shankar@hpcupt3.cup.hp.com (Shankar Unni) (06/29/91)
In comp.lang.c++, etj90@ecs.soton.ac.uk (Khaos) writes: > This just gave me a Thought. Defining your own "meta-operators" would > allow you to define things that aren't a normal language thing at all, > such as foo@bar would allow you to e.g. booleanly test for the existence > of foo in your Object bar (a database of some sort). If this is too > woolly and 7th generation language-y then ignore it but defining your > own operators (although I think retaining priorities of overloaded op's > is a good idea) would be REELY K00L. ^^^^^^^^^^ It's a bird! It's a plane! It's ... BIFF?? :-) Anyway, having just used a language that allows you just this sort of facility (Prolog) - defining or modifying *any* arbitrary operator, along with precedence and arguments (unary and binary only, though :-/), I can say that it's an interesting feature, but used too rarely to justify the enormously more complex (or inefficient) parser required for such dynamic grammar changes. One of the most attractive features of C++ is that it's still a compact language, for which very efficient code can be generated. While the "general operator" facility won't necessarily detract from either of these, it will add an order of magnitude to the difficulty of writing a compiler for the language. That said, I'd also vote for an exponentiation operator as one of the "numeric extensions" to the language. I hope there will eventually be a formal tie-up between the ANSI C++ committee and the NCEG (Numerical C Extensions Group, a subgroup of the ANSI C committee), unless there is one already... ----- Shankar Unni E-Mail: HP India Software Operation, Bangalore Internet: shankar@india.hp.com Phone : +91-812-261254 x417 UUCP: ...!hplabs!hpda!shankar