www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pow operator precedence

reply bearophile <bearophileHUGS lycos.com> writes:
This is the third time I see people trip on power operator precedence:
http://d.puremagic.com/issues/show_bug.cgi?id=7268

Some people expect this:
(-10 ^^ 2)
To be 100 instead of -100
(Note: Python here uses the same operator precedences.)

Do you think it's worth (and possible) to help D programmers avoid this mistake
in their code?

Bye,
bearophile
Jan 13 2012
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
the problem is, that there are two popular use cases of this
expression. One is plain old power expression and the other is writing
scientific notations of numbers. I thing we should stick with the
first use case, because at least for literals we already have
scientific notation.

On Fri, Jan 13, 2012 at 4:48 PM, bearophile <bearophileHUGS lycos.com> wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
mistake in their code?

 Bye,
 bearophile




-- 
Bye,
Gor Gyolchanyan.
Jan 13 2012
prev sibling next sibling parent Mail Mantis <mail.mantis.88 gmail.com> writes:
2012/1/13 bearophile <bearophileHUGS lycos.com>:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
mistake in their code?

 Bye,
 bearophile


My fail =)
I guess that's the right behaviour, but for C++ programmer it's rather
confusing that binary operator precedes unary minus.
Don't see a way how such mistake may be helped to avoid though.
Jan 13 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com> wrote:


 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
 mistake in their code?


I would certainly have made this mistake if I tried it. And knowing this
information will not cause me to do it properly, it will simply make me
question my code, and become very suspicious every time I ever use the
operator (ie. I will never understand the proper precedence, I don't think
it makes sense).
I'm fairly amazed it's not the other way around... what's the logic behind
this?
Jan 13 2012
next sibling parent reply Don Clugston <dac nospam.com> writes:
On 13/01/12 14:47, Manu wrote:

 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com
 <mailto:bearophileHUGS lycos.com>> wrote:

     This is the third time I see people trip on power operator precedence:
     http://d.puremagic.com/issues/show_bug.cgi?id=7268

     Some people expect this:
     (-10 ^^ 2)
     To be 100 instead of -100
     (Note: Python here uses the same operator precedences.)

     Do you think it's worth (and possible) to help D programmers avoid
     this mistake in their code?


 I would certainly have made this mistake if I tried it. And knowing this
 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't
 think it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic
 behind this?


Originally it worked the other way, but bearophile complained about it, 
so it got changed to this way <g>.
Jan 13 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
13.01.2012 19:56, Don Clugston пишет:

 On 13/01/12 14:47, Manu wrote:

 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com
 <mailto:bearophileHUGS lycos.com>> wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid
 this mistake in their code?


 I would certainly have made this mistake if I tried it. And knowing this
 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't
 think it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic
 behind this?


 Originally it worked the other way, but bearophile complained about it,
 so it got changed to this way <g>.


Current behaviour is uncomfortable for me too. What was the reason of 
this change?
Jan 13 2012
prev sibling next sibling parent Mail Mantis <mail.mantis.88 gmail.com> writes:
2012/1/13 Don Clugston <dac nospam.com>:

 On 13/01/12 14:47, Manu wrote:

 I would certainly have made this mistake if I tried it. And knowing this
 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't
 think it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic
 behind this?



 Originally it worked the other way, but bearophile complained about it, so
 it got changed to this way <g>.


I agree to this - meanwhile I've chosen to use std.math.pow to avoid confusion.

Anyway, current convention violates the consistence of the language's
rules, while other one would be confusing to people who have
python/put_language_name experience. In either case, this operator
will be ambiguous for someone. Since C doesn't have such operator, I
don't see a proper way to solve it. Maybe it would be good to always
require explicit parenthesis in such expressions?
Jan 13 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 13 January 2012 17:56, Don Clugston <dac nospam.com> wrote:


 On 13/01/12 14:47, Manu wrote:


 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com
 <mailto:bearophileHUGS lycos.**com <bearophileHUGS lycos.com>>> wrote:

    This is the third time I see people trip on power operator precedence:
    http://d.puremagic.com/issues/**show_bug.cgi?id=7268<http://d.puremagic.com/issues/show_bug.cgi?id=7268>

    Some people expect this:
    (-10 ^^ 2)
    To be 100 instead of -100
    (Note: Python here uses the same operator precedences.)

    Do you think it's worth (and possible) to help D programmers avoid
    this mistake in their code?


 I would certainly have made this mistake if I tried it. And knowing this
 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't
 think it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic
 behind this?


 Originally it worked the other way, but bearophile complained about it, so
 it got changed to this way <g>.


Well... he should obviously be shot!
Jan 13 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/01/2012 13:47, Manu wrote:
<snip>

     Some people expect this:
     (-10 ^^ 2)
     To be 100 instead of -100


<snip>

 I'm fairly amazed it's not the other way around... what's the logic behind
this?


It matches standard mathematical notation.  -x² means -(x²) not (-x)².

This actually makes most sense when you consider that:

(a) -2x² means -2(x²), because exponentiation beats multiplication.  With the
precedence 
you're suggesting, removal of the 2 would completely change the expression.

(b) 42 - x² means 42 - (x²).  With the precedence you're suggesting, removal
of the 42 
would completely change the expression.

Both these rules play a significant part in how we write polynomial
expressions.  Look at 
these:

x³ - x² + 3
    - x² + 3
    -4x² + 3

In all these, the coefficient of x² is negative.  It would be confusing if it
were 
positive only in the second one.

It might help to think of -Exp as syntactic sugar for 0-Exp.

Stewart.
Jan 13 2012
parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 20:54, Stewart Gordon <smjg_1998 yahoo.com> wrote:


 On 13/01/2012 13:47, Manu wrote:
 <snip>

     Some people expect this:

    (-10 ^^ 2)
    To be 100 instead of -100


 <snip>

  I'm fairly amazed it's not the other way around... what's the logic

 behind this?


 It matches standard mathematical notation.  -x=C2=B2 means -(x=C2=B2) not=


 (-x)=C2=B2.

 This actually makes most sense when you consider that:

 (a) -2x=C2=B2 means -2(x=C2=B2), because exponentiation beats multiplicat=


ion.  With

 the precedence you're suggesting, removal of the 2 would completely chang=


e

 the expression.

 (b) 42 - x=C2=B2 means 42 - (x=C2=B2).  With the precedence you're sugges=


ting,

 removal of the 42 would completely change the expression.

 Both these rules play a significant part in how we write polynomial
 expressions.  Look at these:

 x=C2=B3 - x=C2=B2 + 3
   - x=C2=B2 + 3
   -4x=C2=B2 + 3

 In all these, the coefficient of x=C2=B2 is negative.  It would be confus=


ing if

 it were positive only in the second one.

 It might help to think of -Exp as syntactic sugar for 0-Exp.



I think there's one very important point to realise in all your examples
though...
We're NOT writing -4x=C2=B2 + 3. We write -4 * x ^^ 2 + 4. That's not a
polynomial expressions, it's source code.
I don't know about you, but the visual similarity is just not there for me.
I can't see C/D/Java/whatever code as a direct transcription of
mathematical notation no matter how hard I squint at it.
I personally have the presumption that unary operators have a higher
precedence than binary operators... period. I wouldn't give that a second
thought, and that trumps all other logic for me.
Secondary to that, when looking at that statement and deciding which of the
* or ^^ might have higher precedence, I would probably only then consider
that '^^' *may* have higher precedence than '*', but still not certain, and
I wouldn't be surprised (possibly assume) it had the same, ie. left to
right, as with * and /.
Jan 13 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


 Originally it worked the other way, but bearophile complained about it,
 so it got changed to this way <g>.


If I port Python code to D I prefer the current design. I have opened this
thread to see if there are ways to mitigate some of the future problems caused
by that :-)

Of my past design decisions about D I regret of suggesting Walter the name
"immutable". Its meaning is very clear and it's the correct word, but it's a
bit too much long to type, and I am using it often :-| (but less often than
const, fortunately). Maybe "imm" or "immu" was better :-)

---------------------

Manu:


 What I wonder is why this operator is necessary at all?


It's not necessary, like most other features in a language, like for loops. But
it's handy and very useful, I am now using one power operator about every 40 or
50 lines of D2 code.

Instead of writing:
result = (complex expression) * (complex expression);

Or:

const aux = complex expression;
result = aux * aux;

You write:

result = (complex expression) ^^ 2;

And it gets better with cubes.

I think ^^ operator is currently lacking one overload still, it's discussed a
bit in one of the Bugzilla answers written by Don, I think regarding BigInts.

--------------

Mail Mantis:


 Maybe it would be good to always require explicit parenthesis in such
expressions?


Is this wise and good?

Bye,
bearophile
Jan 13 2012
parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 21:31, bearophile <bearophileHUGS lycos.com> wrote:


 What I wonder is why this operator is necessary at all?


 It's not necessary, like most other features in a language, like for
 loops. But it's handy and very useful, I am now using one power operator
 about every 40 or 50 lines of D2 code.

 Instead of writing:
 result = (complex expression) * (complex expression);


What are you working on if I may ask? I do tend to write a lot of very
maths-intensive code (physics, rendering, lighting), and I almost never
find myself using any sort of pow, other than ^2, which I'm perfectly happy
to type x*x.

Or:

 const aux = complex expression;
 result = aux * aux;

 You write:

 result = (complex expression) ^^ 2;


I'm more than happy with aux*aux, in fact, I think I prefer it (probably
just through habit). Though I do sort of see your point.



 And it gets better with cubes.


Realistically, how often do you cube? It's extremely rare in my experience.
Jan 13 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Manu:


 What are you working on if I may ask?


Bioinformatics, exploratory programing, simulations, data munging, hardening of
slow scripts, data visualization, data mining, optimization of some tasks,
faster routines for dynamic code written by other people, and more.



 I do tend to write a lot of very
 maths-intensive code (physics, rendering, lighting), and I almost never
 find myself using any sort of pow, other than ^2, which I'm perfectly happy
 to type x*x.


The problem is that often you don't have a "x", but a "long_named_variable", so
you have to write long_named_variable * long_named_variable. And often you have
to compute an expression to square, so if you don't want to use a temporary
variable you have to duplicate the expression. This is bug-prone and noisy.

Other cases:

1 << 5  ==>  2 ^^ 5  (more readable)

sqrt(3.5)  ==>  3.5 ^^ 0.5
Sometimes better:
return ((p1.x - p2.x) ^^ 2 + (p1.y - p2.y) ^^ 2) ^^ 0.5;

10, 100, 1000, ... ==>  map!(p => 10 ^^ p)(iota(2, ...))

You are allowed to write matrix code that overloads ^^ too.

DMD replaces x^^2 and x^^3 with inlined x**x and x*x*x, so it's better than
using pow efficiency-wise. DMD knows few other exponent rules that applies as
tricks, that I think pow() doesn't use. And programmers usually don't use pow
to square a variable, while D programmers feel natural to use ^^ to square. So
comparing the use cases of pow with ^^ is wrong.

I suggest you to start using ^^ in your D2 code and you will find it more and
more useful.

I have now counted about 730 distinct usages of ^^ operator in the D2 code I
have written and I am keeping my hands on at the moment. The real number is
probably over 800. You are not going to deprecate it.



 Realistically, how often do you cube? It's extremely rare in my experience.


^^3 is not common.

Bye,
bearophile
Jan 13 2012
parent Alvaro <alvaroDotSegura gmail.com> writes:
El 13/01/2012 21:29, bearophile escribió:

 Bioinformatics, exploratory programing, simulations, data munging, hardening
of slow scripts, data visualization, data mining, optimization of some tasks,
faster routines for dynamic code written by other people, and more.

 The problem is that often you don't have a "x", but a "long_named_variable",
...
 ...

 Realistically, how often do you cube? It's extremely rare in my experience.


 ^^3 is not common.



I completely agree. The ^^ operator is a great addition in D even if it 
is not used very often. I always found awkward the lack of such operator 
in C-derived languages (some others use either ^ or **). And I was happy 
to see in the DMD source how ^^2 and ^^3 are rewritten to avoid pow().

There are indeed applications that use exponentiation and whose 
expressions using ^^ are much more readable and closer to the 
mathematical notation.

e.g. sphere_volume = 4./3 * PI * radius^^3; // so much better


As for the original discussion on precedence I think the first example 
is different to the others posted in that it uses a *number literal*.

in -x^^2, following standard math, it should be -(x^^2) (<0)

but the first example, -10^^2 is confusing because one might quickly see 
the - sign as part of the number literal. As long as in D the - sign is 
not part of the literal, the current behavior is fine. If you want it 
the other way around write:

(-10)^^2
Jan 14 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/01/2012 19:14, Manu wrote:
<snip>

 I think there's one very important point to realise in all your examples
though...
 We're NOT writing -4x² + 3. We write -4 * x ^^ 2 + 4. That's not a polynomial
expressions,
 it's source code.


What are you on about?  -4x² + 3 and -4 * x ^^ 2 + 3 are the exact same
polynomial 
expression.  They're just written in different notations.


 I don't know about you, but the visual similarity is just not there for me. I
can't see
 C/D/Java/whatever code as a direct transcription of mathematical notation no
matter how
 hard I squint at it.


<snip>

But we mathematicians get used to the similarities in stuff like precedence
rules.  We 
shouldn't have to remember that D works differently in ways that the compiler
won't warn 
us if we forget.  Add to that that some of us may be migrating from something
like Maple 
or Mathematica that bridges the gap between mathematical notation and program
code.

And my points still apply.

x ^^ 3 - x ^^ 2 + 3
vs.
        - x ^^ 2 + 3

One shouldn't have to remember to add brackets to x ^^ 2 because removal of the
x ^^ 3 
term has changed the nature of the -.

Stewart.
Jan 13 2012
prev sibling next sibling parent Somedude <lovelydear mailmetrash.com> writes:
Le 13/01/2012 13:48, bearophile a écrit :

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268
 
 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)
 
 Do you think it's worth (and possible) to help D programmers avoid this
mistake in their code?
 
 Bye,
 bearophile


Maybe a compiler warning ?
Jan 13 2012
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Fri, Jan 13, 2012 at 7:47 AM, Manu <turkeyman gmail.com> wrote:

 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com> wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
 mistake in their code?



 I would certainly have made this mistake if I tried it. And knowing this
 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't think
 it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic behind
 this?


The logic is that the precedence in the language matches the
precedence of a written equation.
Jan 13 2012
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
On Fri, 2012-01-13 at 08:09 -0600, Andrew Wiley wrote:

 On Fri, Jan 13, 2012 at 7:47 AM, Manu <turkeyman gmail.com> wrote:

 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com> wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=3D7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid thi=






s

 mistake in their code?



 I would certainly have made this mistake if I tried it. And knowing thi=




s

 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't th=




ink

 it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic beh=




ind

 this?


=20
 The logic is that the precedence in the language matches the
 precedence of a written equation.


The problem here is the conflict introduced by allowing -10 to be the
application of the unary minus operator to the positive value 10 instead
of being a representation of the negative integer value -10.  BODMAS
covers everything.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 13 2012
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
bearophile wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)


Why x ^^ y is considered _unary_ expression?
Jan 13 2012
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 1/13/2012 4:48 AM, bearophile wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
mistake in their code?

 Bye,
 bearophile


I don't like it, but I think we should keep it.

The reason?

-10 ^^ 2 == -(10) ^^ 2 == -(x) ^^ 2 == -x ^^ 2 != (-x) ^^ 2
Jan 13 2012
parent reply Mehrdad <wfunction hotmail.com> writes:
On 1/13/2012 8:59 AM, Mehrdad wrote:

 On 1/13/2012 4:48 AM, bearophile wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid 
 this mistake in their code?

 Bye,
 bearophile


 I don't like it, but I think we should keep it.

 The reason?

 -10 ^^ 2 == -(10) ^^ 2 == -(x) ^^ 2 == -x ^^ 2 != (-x) ^^ 2


Heck, or how about emitting a warning if it's a literal without 
parentheses either way?
Jan 13 2012
next sibling parent Matej Nanut <matejnanut gmail.com> writes:
I feel it should be left as is: it'll be ambiguous either way and why mess
with how it's in mathematics? If anyone feels uncomfortable using it,
just use std.math.pow. Many other languages don't have this operator so
people coming from them won't know it exists anyway (like me until this
post).

=E2=80=94 Matej

On 13 January 2012 18:01, Mehrdad <wfunction hotmail.com> wrote:

 On 1/13/2012 8:59 AM, Mehrdad wrote:

 On 1/13/2012 4:48 AM, bearophile wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=3D7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
 mistake in their code?

 Bye,
 bearophile



 I don't like it, but I think we should keep it.

 The reason?

 -10 ^^ 2 =3D=3D -(10) ^^ 2 =3D=3D -(x) ^^ 2 =3D=3D -x ^^ 2 !=3D (-x) ^^ =




2

 Heck, or how about emitting a warning if it's a literal without parenthes=


es

 either way?
Jan 13 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 19:41, Matej Nanut <matejnanut gmail.com> wrote:


 I feel it should be left as is: it'll be ambiguous either way and why mess
 with how it's in mathematics? If anyone feels uncomfortable using it,
 just use std.math.pow. Many other languages don't have this operator so
 people coming from them won't know it exists anyway (like me until this
 post).



Expecting all people who may be uncomfortable with it to use pow() doesn't
help those who have to read others code containing the operator.
It's NOT like it is in mathematics, there is no 'operator' in mathematics
(maths uses a superscript, which APPEARS to be a unary operation). When
using the operator, with spaces on either side, it looks like (and is) a
binary operator.
I think it's reasonable for any experienced programmer to expect that any
binary operator will have a lower precedence than a unary operator.
What I wonder is why this operator is necessary at all? With this
ambiguity, it harms the readability, not improves it :/
Jan 13 2012
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 13/01/2012 18:18, Manu wrote:
<snip>

 It's NOT like it is in mathematics, there is no 'operator' in mathematics
(maths uses a
 superscript, which APPEARS to be a unary operation). When using the operator,
with spaces
 on either side, it looks like (and is) a binary operator.


<snip>

Actually, exponentiation _is_ an operator, just like + or - or × or ÷.  Or
even ∩ or ∪, 
though these have completely different domains.  Indeed, strictly speaking,
there's no 
distinction between operators and functions.

What does vary between operators, however, is the structure of the _notation_. 
This has 
no bearing on its intrinsic nature as an operator.  The distinction is part of 
mathematical notation, not mathematics itself.

To put it differently, you could invent a mathematical notation of your own. 
Doing so 
does not intrinsically change the mathematics.

Stewart.
Jan 13 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/13/2012 07:18 PM, Manu wrote:

 On 13 January 2012 19:41, Matej Nanut <matejnanut gmail.com
 <mailto:matejnanut gmail.com>> wrote:

     I feel it should be left as is: it'll be ambiguous either way and
     why mess
     with how it's in mathematics? If anyone feels uncomfortable using it,
     just use std.math.pow. Many other languages don't have this operator so
     people coming from them won't know it exists anyway (like me until this
     post).


 Expecting all people who may be uncomfortable with it to use pow()
 doesn't help those who have to read others code containing the operator.


They surely can spend the 2 seconds worth of effort to become 
comfortable with it. This is an exceedingly trivial issue, and D has 
adapted a common convention.


 It's NOT like it is in mathematics, there is no 'operator' in
 mathematics (maths uses a superscript, which APPEARS to be a unary
 operation).


If an operation has two parameters, then it is a binary operation.


 When using the operator, with spaces on either side, it
 looks like (and is) a binary operator.


^ commonly means superscript. It simply cannot be argued that ^^ does 
not resemble ^ a lot. (no matter how many spaces anyone puts anywhere.)


 I think it's reasonable for any experienced programmer to expect that
 any binary operator will have a lower precedence than a unary operator.


It is reasonable for any 'experienced programmer' to be familiar with 
some language/calculator that has an exponentiation operator. 
Furthermore, I bet there are many 'experienced programmers' who would 
actually be surprised that -a*b is parsed as (-a)*b instead of -(a*b).


 What I wonder is why this operator is necessary at all?


Few handy language features are strictly 'necessary'. Having ^^ as a 
built-in means that the compiler can optimize it for common small 
constant exponents, like 2 or 3.


 With this ambiguity, it harms the readability, not improves it :/


There is no ambiguity. And yes, it improves readability:

sqrt((x1-x2)^^2+(y1-y2)^^2);

is better than

sqrt(pow(x1-x2,2)+pow(y1-y2,2));

or

sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2));


There is no contest.
Jan 13 2012
prev sibling next sibling parent Matej Nanut <matejnanut gmail.com> writes:
Oh, yeah, my bad. I've been at uni for too long: seeing subscripts as "^a"...
I agree that an operator for this is unnecessary though. At least I have never
felt the need to write "pow(,)" quicker than 6 symbols.

On another note, Octave (and I guess Matlab as well?) use D's precedence
for the pow operator. Bearophile stated earlier that Python does too. Those
seem like quite large audiences. I'm not saying agreeing with the masses
is the choice here, but if a mathematical environment sees it as fit, and
since as far as I'm concerned there's still no reason to prefer one over the
other, it should be either deprecated or left alone.

It will remain ambiguous to someone at some point, no matter how it's
defined. Part of learning the language though.

On 13 January 2012 19:18, Manu <turkeyman gmail.com> wrote:

 On 13 January 2012 19:41, Matej Nanut <matejnanut gmail.com> wrote:

 I feel it should be left as is: it'll be ambiguous either way and why mess
 with how it's in mathematics? If anyone feels uncomfortable using it,
 just use std.math.pow. Many other languages don't have this operator so
 people coming from them won't know it exists anyway (like me until this
 post).



 Expecting all people who may be uncomfortable with it to use pow() doesn't
 help those who have to read others code containing the operator.
 It's NOT like it is in mathematics, there is no 'operator' in mathematics
 (maths uses a superscript, which APPEARS to be a unary operation). When
 using the operator, with spaces on either side, it looks like (and is) a
 binary operator.
 I think it's reasonable for any experienced programmer to expect that any
 binary operator will have a lower precedence than a unary operator.
 What I wonder is why this operator is necessary at all? With this ambiguity,
 it harms the readability, not improves it :/
Jan 13 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 20:46, Matej Nanut <matejnanut gmail.com> wrote:


 On another note, Octave (and I guess Matlab as well?) use D's precedence
 for the pow operator. Bearophile stated earlier that Python does too. Those
 seem like quite large audiences. I'm not saying agreeing with the masses
 is the choice here, but if a mathematical environment sees it as fit, and
 since as far as I'm concerned there's still no reason to prefer one over
 the
 other, it should be either deprecated or left alone.


Fair call. I buy this argument. If there is a precedent set by (multiple)
other languages towards this precedence (and none against), then so be it.
If there were a vote though, I'd vote for it being deprecated on grounds of
offering nothing to the language more than confusion.
Jan 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 11:25 AM, Manu wrote:

 Fair call. I buy this argument. If there is a precedent set by (multiple) other
 languages towards this precedence (and none against), then so be it.
 If there were a vote though, I'd vote for it being deprecated on grounds of
 offering nothing to the language more than confusion.


I suspect that pow may be better off as a compiler intrinsic.
Jan 13 2012
parent reply Mehrdad <wfunction hotmail.com> writes:
On 1/13/2012 5:39 PM, Walter Bright wrote:

 On 1/13/2012 11:25 AM, Manu wrote:

 Fair call. I buy this argument. If there is a precedent set by 
 (multiple) other
 languages towards this precedence (and none against), then so be it.
 If there were a vote though, I'd vote for it being deprecated on 
 grounds of
 offering nothing to the language more than confusion.


 I suspect that pow may be better off as a compiler intrinsic.


I posted this once but it seemed to go ignored, so I'll post again ;)

I think a WARNING is the best route.
Kind of like when VC++ cries in pain when you say something like "a << b 
+ c": http://msdn.microsoft.com/en-us/library/5d2e57c5.aspx
Jan 14 2012
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 01/14/2012 02:56 PM, Mehrdad wrote:

 On 1/13/2012 5:39 PM, Walter Bright wrote:

 On 1/13/2012 11:25 AM, Manu wrote:

 Fair call. I buy this argument. If there is a precedent set by
 (multiple) other
 languages towards this precedence (and none against), then so be it.
 If there were a vote though, I'd vote for it being deprecated on
 grounds of
 offering nothing to the language more than confusion.


 I suspect that pow may be better off as a compiler intrinsic.


 I posted this once but it seemed to go ignored, so I'll post again ;)

 I think a WARNING is the best route.
 Kind of like when VC++ cries in pain when you say something like "a << b
 + c": http://msdn.microsoft.com/en-us/library/5d2e57c5.aspx


Eh, unless things have changed in the past few years, D isn't really 
into warnings.  I'm fine with it being an error though.
Jan 14 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 16:09, Andrew Wiley <wiley.andrew.j gmail.com> wrote:


 On Fri, Jan 13, 2012 at 7:47 AM, Manu <turkeyman gmail.com> wrote:

 On 13 January 2012 14:48, bearophile <bearophileHUGS lycos.com> wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=3D7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid thi=






s

 mistake in their code?



 I would certainly have made this mistake if I tried it. And knowing thi=




s

 information will not cause me to do it properly, it will simply make me
 question my code, and become very suspicious every time I ever use the
 operator (ie. I will never understand the proper precedence, I don't


 think

 it makes sense).
 I'm fairly amazed it's not the other way around... what's the logic


 behind

 this?


 The logic is that the precedence in the language matches the
 precedence of a written equation.


But the operator looks nothing like the written equation... nothing at all
like the written equation.
Perhaps D could support the unicode characters '=C2=B2' '=C2=B3' or '=C2=AA=
' as kinda
handy operators. But to me, the operator looks NOTHING like maths notation,
and it would never have occurred to me that the operator was trying to
emulate maths notation (and by extension, its precedence rules).
I'd be interested to see a poll, and how many people see it one way or the
other...
Jan 13 2012
parent reply "Grue" <Grue nop.com> writes:
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    The logic is that the precedence in the language matches the
    precedence of a written equation.



  But the operator looks nothing like the written equation... nothing at =
all like the written equation.
  Perhaps D could support the unicode characters '=C2=B2' '=C2=B3' or =
'=C2=AA' as kinda handy operators. But to me, the operator looks NOTHING =
like maths notation, and it would never have occurred to me that the =
operator was trying to emulate maths notation (and by extension, its =
precedence rules).
  I'd be interested to see a poll, and how many people see it one way or =
the other...

Beware... your statement has awoken an "Ancient Forum Lurker"! ;)

1. Google -5^2, result: -(5^2) =3D -25
2. Start ancient TI graphing calculator(which by the way has a special =
unary (-) minus operator).
-5^2 =3D -25
-5=C2=B2 =3D -25

The list can be extended by a great number of examples of prior =
convention for the pow operator(especially in mathemathical software)... =
not just Python... I have actually never even seen a valid counter =
example... changing this would greatly confuse people with mathematical =
background.
Jan 13 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 January 2012 21:24, Grue <Grue nop.com> wrote:


 **


  The logic is that the precedence in the language matches the

 precedence of a written equation.


 But the operator looks nothing like the written equation... nothing at al=


l

 like the written equation.
 Perhaps D could support the unicode characters '=C2=B2' '=C2=B3' or '=C2=


=AA' as kinda

 handy operators. But to me, the operator looks NOTHING like maths notatio=


n,

 and it would never have occurred to me that the operator was trying to
 emulate maths notation (and by extension, its precedence rules).
 I'd be interested to see a poll, and how many people see it one way or th=


e

 other...


 Beware... your statement has awoken an "Ancient Forum Lurker"! ;)


Sweet! I have that effect :P



 1. Google -5^2, result: -(5^2) =3D -25
 2. Start ancient TI graphing calculator(which by the way has a special
 unary (-) minus operator).
 -5^2 =3D -25
 -5*=C2=B2* =3D -25

 The list can be extended by a great number of examples of prior conventio=


n

 for the pow operator(especially in mathemathical software)... not just
 Python... I have actually never even seen a valid counter example...
 changing this would greatly confuse people with mathematical background.


In my prior post I agreed, though that said, I still maintain that none of
those exampled look sufficiently like -5 ^^ 2 by my mind to be considered
'the same thing'. The single ^ and your not using spaces on either side
distinguish it quite clearly...
If it weren't for participation in this debate, I would have never
clarified this in my mind personally, I can say that with confidence.
The ^ xor operator was already taken. Promotion of a 'common' (arguable...)
function to an operator can only be justified by improving code clarity...
I don't think there's any evidence that it does that.

It's funny, I've written a lot of maths code (mostly physics and/or
rendering/lighting), but I can probably count the number of times I've used
pow() on one hand. I use sqrt(), but I think that's a fairly well
established subset of pow(), and people would never use ^^ to perform a
sqrt. A function of that rarity possibly doesn't warrant a custom operator
:)






 Jan 13 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.328.1326483521.16222.digitalmars-d puremagic.com...
On 13 January 2012 21:24, Grue <Grue nop.com> wrote:

 Beware... your statement has awoken an "Ancient Forum Lurker"! ;)


Sweet! I have that effect :P


Arise!


In my prior post I agreed, though that said, I still maintain that none of
those exampled look sufficiently like -5 ^^ 2 by my mind to be considered
'the same thing'. The single ^ and your not using spaces on either side
distinguish it quite clearly...


If that's the case, then what you're objecting to is almost exactly like:

2+3 * 4+1

But that's well-accepted. If the spaces throw you off, then just use them 
differently:

2 + 3*4 + 1
-5^^2


It's funny, I've written a lot of maths code (mostly physics and/or
rendering/lighting), but I can probably count the number of times I've used
pow() on one hand. I use sqrt(), but I think that's a fairly well
established subset of pow(), and people would never use ^^ to perform a
sqrt. A function of that rarity possibly doesn't warrant a custom operator
:)


Sounds like you're talking about game code, in which case it doesn't 
surprise me you haven't used it much. Game code needs to be real-time, so 
doing advanced math in code tends to be avoided whenever possible, even if 
it's at the expense of slight inaccuracy (since framerate and user 
experience are more important than perfect mathematical "correctness"). 
Other applications would be fairly different, like scientific computing.



 Jan 13 2012



  parent  "Grue" <Grue nop.com>  writes:


"Nick Sabalausky" <a a.a> skrev i meddelandet 
news:jeq6h1$18mu$1 digitalmars.com...

 "Manu" <turkeyman gmail.com> wrote in message 
 news:mailman.328.1326483521.16222.digitalmars-d puremagic.com...
 On 13 January 2012 21:24, Grue <Grue nop.com> wrote:

 Beware... your statement has awoken an "Ancient Forum Lurker"! ;)


Sweet! I have that effect :P


 Arise!


Haha, just as I was beginning to suspect the predictions of 2012 were 
true... but whew, language crisis narrowly averted! ;) Now I can go back to 
planning my wedding instead... :P

Manu" <turkeyman gmail.com> wrote in message

 Perhaps D could support the unicode characters '²' '³' or 'ª' as kinda 
 handy operators.


You know... that's an interesting idea... but there's a far cooler 
possibility lurking around the corner... Remember the first time you 
experienced 'syntax highlighting' and how limiting it felt to go back to a 
black&white afterwards?

Imagine... an IDE/editor with pretty formatting of math source 
expressions... even if it was just limited to... fractions and maybe sqrt... 
byebye ubiquitous parentheses hell... say hi to readable expressions!

Proper fractions would be a killer feature for readability... and there 
would be no language change needed at all... Am I the only one upset with 
the obvious omissions of must have math symbols from normal keyboards... 
sqrt, pretty please?!



 Jan 13 2012



prev sibling  parent reply Stewart Gordon <smjg_1998 yahoo.com>  writes:


On 13/01/2012 19:24, Grue wrote:
<snip>

 Beware... your statement has awoken an "Ancient Forum Lurker"! ;)
 1. Google -5^2, result: -(5^2) = -25
 2. Start ancient TI graphing calculator(which by the way has a special unary
(-) minus
 operator).
 -5^2 = -25
 -5*²* = -25


<snip>

And probably most BASICs.  Just checked VBA and Spectrum BASIC.  Once upon a
time I would 
have had QBasic to test on as well.

Stewart.



 Jan 13 2012



  parent  Matej Nanut <matejnanut gmail.com>  writes:


My HP 49g+ does -2^2 =3D -4 as well (with special unary minus), in algebrai=
c
mode. Would love to test it on the 41C, but it only has RPN. ^_^

I've been swayed into the =C2=BBlet's keep it=C2=AB direction.

I'll start using it, too. It even works as an array operator. =3DD

On 14 January 2012 00:30, Stewart Gordon <smjg_1998 yahoo.com> wrote:

 On 13/01/2012 19:24, Grue wrote:
 <snip>

 Beware... your statement has awoken an "Ancient Forum Lurker"! ;)
 1. Google -5^2, result: -(5^2) =3D -25
 2. Start ancient TI graphing calculator(which by the way has a special
 unary (-) minus
 operator).
 -5^2 =3D -25
 -5*=C2=B2* =3D -25


 <snip>

 And probably most BASICs. =C2=A0Just checked VBA and Spectrum BASIC. =C2=


=A0Once upon a

 time I would have had QBasic to test on as well.

 Stewart.





 Jan 13 2012



prev sibling  parent reply Chad J <chadjoan __spam.is.bad__gmail.com>  writes:


On 01/13/2012 07:48 AM, bearophile wrote:

 This is the third time I see people trip on power operator precedence:
 http://d.puremagic.com/issues/show_bug.cgi?id=7268

 Some people expect this:
 (-10 ^^ 2)
 To be 100 instead of -100
 (Note: Python here uses the same operator precedences.)

 Do you think it's worth (and possible) to help D programmers avoid this
mistake in their code?

 Bye,
 bearophile


I read some of the other responses and... ewwwww.

My only conclusion is that there is no right answer in the precedence 
dichotomy, so my suggestion is to ditch the dichotomy.

Off hand, I'd be comfortable with forbidding such ambiguous expressions 
(in human readability terms; I know the grammar is fine).  It'd be in 
the spirit of things like "if (a = b)".  Parentheses would be required, 
so one must write
(-10)^^2
or
-(10^^2)

I imagine this would make sense for all unary operators colliding with ^^:

++10^^2    // wtf does this do?
...
(++10)^^2  // aha!
or
++(10^^2)  // aha!



 Jan 14 2012



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Chad J:


 Parentheses would be required, so one must write
 (-10)^^2
 or
 -(10^^2)
 
 I imagine this would make sense for all unary operators colliding with ^^:


Is this wise and good? What are Walter & Andrei & Don thinking about this?

Bye,
bearophile



 Jan 14 2012