Thanks for all your effort! Unfortunately, since there's no option for
negative numbers to intuitively square to positive outcomes, my vote is
still No. I understand and respect your reasoning even though I do not
agree with it.
To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2 = -9
is how the preponderance of credible resources evaluate the expression. As
far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.
http://math.stackexchange.com/questions/491933/exponent-rules-with-negative-numbers
The RFC's implementation is consistent with those found in other languages
and is (IMO) sensible as long as you play by the rules. Until someone
points out a valid problem other than "I don't like right associativity,"
I'm inclined to vote yes.
As far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.
This RFC indeed proposes a flat world. Maybe an RFC with Unicode
superscript numbers would solve this discussion and mark this one obsolet.
10⁰¹²³⁺⁴⁵⁶⁻⁷⁸⁹
(never seen this anywhere)
Thanks for all your effort! Unfortunately, since there's no option for
negative numbers to intuitively square to positive outcomes, my vote is
still No. I understand and respect your reasoning even though I do not
agree with it.To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2 = -9
is how the preponderance of credible resources evaluate the expression. As
far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.
That's a faulty analogy. In mathematics, the square of any number,
positive or negative, yields a positive result. Any scientific or graphing
calculator will match that behavior. I did sqr(-3) in the Windows
Calculator just now and it outputted 9, not -9.
From http://en.wikipedia.org/wiki/Square_(algebra):
"One of the important properties of squaring, for numbers as well as in
many other mathematical systems, is that (for all numbers x), the square of
x is the same as the square of its additive inverse -x. That is, the square
function satisfies the identity x2 = (-x)2. This can also be expressed by
saying that the squaring function is an even function."
Now, I understand why some programming languages behave differently from
the algebraic standard. I don't agree with it, but I understand their
reasoning. Claiming that "the squaring function should always be an even
function" is the equivalent of saying that the Earth is flat is faulty
because it completely ignores the facts that support that argument, just as
it would be faulty for me to ignore the facts that support yours.
I believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.
You're free to disagree and you certainly have valid reasons for doing so,
but please try to keep in mind that there is a valid argument on the other
side of this, as well.
--Kris
I believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.
No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
rare case that someone for some reason hardcodes a negative literal
there, they are going to have to learn about operator precedence because
we really can't have 0 - 32 be different from - 32.
-Rasmus
Maybe this is because my educational background is in Mathematics but
personally, I would tend to assume first (with just about any
language- unless I had reason to believe otherwise) that - blah is
equivalent to - (blah). FWIW, - 3 ** 2 === (-3) ** 2 would seem very
counter intuitive to me and I would probably gripe to myself about an
odd choice of operation syntax. This particularly makes sense given
Rasmus's example. The function
function blah($argument){
return 3 - $blah ** 2
}
Should not by default reverse the sign of $blah as the suggested
syntax might suggest. Again, just my thought.
I believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
rare case that someone for some reason hardcodes a negative literal
there, they are going to have to learn about operator precedence because
we really can't have 0 - 32 be different from - 32.-Rasmus
No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
rare case that someone for some reason hardcodes a negative literal
there, they are going to have to learn about operator precedence because
we really can't have 0 - 32 be different from - 32.
We also, surely, cannot have -3**2 act differently from - 3 ** 2, for
the same reason.
--
Andrea Faulds
http://ajf.me/
I believe that, especially for a KISS language like PHP, our top
priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3
** 2
and expect a result of 9, not -9, and rightly so I think.No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
I didn't quite understand if you're making the case for assuming a type
casting of $var and keep with the expected math or if operator precedence
would mean the result could be negative in some cases.
Example:
$str = '-3';
$res = 0 - $str ** 2;
PEMDAS would mean this results in $res having a value of 9 whatever the
case ($str positive or negative)!
Would this be different in regards to operator precedence?
rare case that someone for some reason hardcodes a negative literal
there, they are going to have to learn about operator precedence because
we really can't have 0 - 32 be different from - 32.-Rasmus
No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
I didn't quite understand if you're making the case for assuming a type
casting of $var and keep with the expected math or if operator precedence
would mean the result could be negative in some cases.
I understood Rasmus's point to be rather simpler than that: PHP code
will rarely contain the actual hard-coded sum "-3 ** 2", it will much
more likely look something like this:
$var = some_function();
$square_of_var = $var ** 2;
Now if some_function() returns -3 (the integer), $square_of_var will end
up with a value of 9. No need to worry about associativity, no type
casting, just application of maths, and the result is as expected.
Now, you could imagine a more complex example like this:
$cube_of_inverted_var = -$var ** 3;
But that's hard enough to read that I'd probably introduce brackets
anyway, if not avoid the unary operator altogether:
$cube_of_inverted_var = (-1 * $var) ** 3;
In my head, the reason "-3 ** 2" looks like (-3) ** 2 is that I tend to
think of "-3" as a single literal value, not the application of the
unary operator "-" to the literal value "3". Once it becomes "-$var **
2", that impression evaporates, and I would, personally, avoid assuming
precedence one way or another, and add some brackets.
Regards,
--
Rowan Collins
[IMSoP]
Well and lets reverse the argument a bit. Lets assume the syntax -3**3
== (-3)**2.
Which syntax would be easier to read:
1 - - 3**3 or 1 - (-3)**3
I would find myself always going with number 2 since it is more
intuitive from an operations standpoint and is less jarring on the
eyes.
Well and lets reverse the argument a bit.
Reverse which argument? I think your reply may have been threaded to the
wrong message, and it gives no quotes for context.
Which syntax would be easier to read:
1 - - 3**3 or 1 - (-3)**3
Frankly, both make my eyes bleed, and seem very unlikely in practice (at
least one of those would be a variable, or why would you not just
hard-code the result?)
--
Rowan Collins
[IMSoP]
Disregard, I was thinking too hard. Seems all of the important points
have already been made.
Well and lets reverse the argument a bit.
Reverse which argument? I think your reply may have been threaded to the
wrong message, and it gives no quotes for context.Which syntax would be easier to read:
1 - - 3**3 or 1 - (-3)**3
Frankly, both make my eyes bleed, and seem very unlikely in practice (at
least one of those would be a variable, or why would you not just hard-code
the result?)--
Rowan Collins
[IMSoP]
Rasmus Lerdorf wrote:
I believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.No, the average PHP developer is going to do $var ** 2 and it will
behave exactly as they expect with negative values. Yes, in the very
rare case that someone for some reason hardcodes a negative literal
there, they are going to have to learn about operator precedence because
we really can't have 0 - 32 be different from - 32.
The only way to ensure you get what YOU expect is to add the missing brackets to
any equation ...
- (3**2) is simply not the same as (- 3)**2 but '-3' should always be (-3) the
space has a significance in this case as far as I am concerned. All of this
needs the proper inclusion of the brackets since you can't always remember which
alternate is being used anyway ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
- (3**2) is simply not the same as (- 3)**2 but '-3' should always be (-3) the
space has a significance in this case as far as I am concerned.
But it doesn't... the - is just another operator (even in "real math")
and doesn't have the highest precedence, space or not.
What's fascinating is that some portion of devs have been making
assumptions for years and years and only now is there an case that
requires consensus -- since the (wrong) assumption still ends up with
the right results ~100% of the time given the current precedence table
and other math rules.
-- S.
I did sqr(-3) in the Windows Calculator just now and it outputted 9,
not -9.
In this situation, you are forcing the order of operations based on
rules of the UI and/or parentheses. That's not the same as deciding
the natural associativity of the exponent.
-- Sandy
Thanks for all your effort! Unfortunately, since there's no option for
negative numbers to intuitively square to positive outcomes, my vote is
still No. I understand and respect your reasoning even though I do not
agree with it.To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2 =
-9
is how the preponderance of credible resources evaluate the expression.
As
far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.That's a faulty analogy. In mathematics, the square of any number,
positive or negative, yields a positive result. Any scientific or graphing
calculator will match that behavior. I did sqr(-3) in the Windows
Calculator just now and it outputted 9, not -9.
The problem here is that pow(-3, 2) is equivalent to the expression (-3) ** 2, not -(3 **2). Said differently, -3 ** 2 is equivalent to
-pow(3,2) and not pow(-3,2).
Hopefully this helps.
Thanks for all your effort! Unfortunately, since there's no option for
negative numbers to intuitively square to positive outcomes, my vote is
still No. I understand and respect your reasoning even though I do not
agree with it.
Intuition can (by definition) not coexist with mathematical reasoning, so
it seems that you're talking about experience here.
Experience may come from:
a) prior mathematical education
Assuming a sane teacher, you would have been taught to write (-3) ^ 2 on
paper if you mean to square negative 3.
b) prior use of mathematical expressions in other programming languages
17 out of 22 programming languages that I have investigated are in favour
of a higher precedence for the power operation.
To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2 =
-9
is how the preponderance of credible resources evaluate the expression.
As
far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.That's a faulty analogy. In mathematics, the square of any number,
positive or negative, yields a positive result. Any scientific or graphing
calculator will match that behavior. I did sqr(-3) in the Windows
Calculator just now and it outputted 9, not -9.
Likewise, both pow(-3, 2) as well as (-3) ** 2 yield 9. I'm not
arguing that an even power of a negative base should yield a negative
outcome; I'm arguing that what you deem to be intuitive is based on a
misconception.
From http://en.wikipedia.org/wiki/Square_(algebra):
"One of the important properties of squaring, for numbers as well as in
many other mathematical systems, is that (for all numbers x), the square of
x is the same as the square of its additive inverse -x. That is, the square
function satisfies the identity x2 = (-x)2. This can also be expressed by
saying that the squaring function is an even function."
See what they're doing there? They disambiguate the expression to (-x)2,
which is the same as (-3) ** 2 or (-$x) ** 2.
Now, I understand why some programming languages behave differently from
the algebraic standard. I don't agree with it, but I understand their
reasoning. Claiming that "the squaring function should always be an even
function" is the equivalent of saying that the Earth is flat is faulty
because it completely ignores the facts that support that argument, just as
it would be faulty for me to ignore the facts that support yours.
Not just some, more than 75% of the languages I've investigated do that.
Curiously, Visual Basic does it this way, whereas Excel doesn't :) I've
listed them here: https://wiki.php.net/rfc/pow-operator#discussion
I believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.
And arithmetic law states that -3 ** 2 should be interpreted as -(3 ** 2). See also:
http://en.wikipedia.org/wiki/Order_of_operations#Exceptions_to_the_standard
It's only in programming languages that this behaviour may be different due
to historical reasons or what not.
You're free to disagree and you certainly have valid reasons for doing so,
but please try to keep in mind that there is a valid argument on the other
side of this, as well.
Your case seems to promote following a minority of programming languages
that do this, though.
--Kris
--
Tjerk
On Thu, Dec 19, 2013 at 4:27 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
On Thu, Dec 19, 2013 at 4:33 AM, Daniel Lowrey rdlowrey@gmail.com
wrote:Thanks for all your effort! Unfortunately, since there's no option
for
negative numbers to intuitively square to positive outcomes, my vote
is
still No. I understand and respect your reasoning even though I do
not
agree with it.Intuition can (by definition) not coexist with mathematical reasoning, so
it seems that you're talking about experience here.Experience may come from:
a) prior mathematical education
Assuming a sane teacher, you would have been taught to write (-3) ^ 2 on
paper if you mean to square negative 3.b) prior use of mathematical expressions in other programming languages
17 out of 22 programming languages that I have investigated are in favour
of a higher precedence for the power operation.To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2
= -9
is how the preponderance of credible resources evaluate the expression.
As
far as I can tell voting "no" on this basis is equivalent to me claiming
the earth is flat because it better fits my world-view.That's a faulty analogy. In mathematics, the square of any number,
positive or negative, yields a positive result. Any scientific or
graphing
calculator will match that behavior. I did sqr(-3) in the Windows
Calculator just now and it outputted 9, not -9.Likewise, both
pow(-3, 2)as well as(-3) ** 2yield9. I'm not
arguing that an even power of a negative base should yield a negative
outcome; I'm arguing that what you deem to be intuitive is based on a
misconception.From http://en.wikipedia.org/wiki/Square_(algebra):
"One of the important properties of squaring, for numbers as well as in
many other mathematical systems, is that (for all numbers x), the square
of
x is the same as the square of its additive inverse -x. That is, the
square
function satisfies the identity x2 = (-x)2. This can also be expressed by
saying that the squaring function is an even function."See what they're doing there? They disambiguate the expression to
(-x)2,
which is the same as(-3) ** 2or(-$x) ** 2.Now, I understand why some programming languages behave differently from
the algebraic standard. I don't agree with it, but I understand their
reasoning. Claiming that "the squaring function should always be an even
function" is the equivalent of saying that the Earth is flat is faulty
because it completely ignores the facts that support that argument, just
as
it would be faulty for me to ignore the facts that support yours.Not just some, more than 75% of the languages I've investigated do that.
Curiously, Visual Basic does it this way, whereas Excel doesn't :) I've
listed them here: https://wiki.php.net/rfc/pow-operator#discussionI believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 ** 2
and expect a result of 9, not -9, and rightly so I think.And arithmetic law states that
-3 ** 2should be interpreted as-(3 ** 2). See also:
http://en.wikipedia.org/wiki/Order_of_operations#Exceptions_to_the_standardIt's only in programming languages that this behaviour may be different
due to historical reasons or what not.You're free to disagree and you certainly have valid reasons for doing so,
but please try to keep in mind that there is a valid argument on the other
side of this, as well.Your case seems to promote following a minority of programming languages
that do this, though.--Kris
--
Tjerk
So just to tie it all together (and please correct me if I'm mistaken),
your argument is basically that:
-x is actually -1 * x. Therefore, -3 ** 2 would actually be -1 * 3 ** 2.
Due to order of operations, that comes out to -1 * 9 == -9.
But now, let's look at another scenario:
<?php
$x = -3; // Or $x = -1 * 3, if you wish.
$y = $x ** 2;
?>
What would be the value of $y under this RFC?
--Kris
On Thu, Dec 19, 2013 at 4:27 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
On Thu, Dec 19, 2013 at 4:33 AM, Daniel Lowrey rdlowrey@gmail.com
wrote:Thanks for all your effort! Unfortunately, since there's no option
for
negative numbers to intuitively square to positive outcomes, my vote
is
still No. I understand and respect your reasoning even though I do
not
agree with it.Intuition can (by definition) not coexist with mathematical reasoning, so
it seems that you're talking about experience here.Experience may come from:
a) prior mathematical education
Assuming a sane teacher, you would have been taught to write (-3) ^ 2 on
paper if you mean to square negative 3.b) prior use of mathematical expressions in other programming languages
17 out of 22 programming languages that I have investigated are in favour
of a higher precedence for the power operation.To me this is not a question of "intuitive" vs. "unintuitive" ... -3^2
= -9
is how the preponderance of credible resources evaluate the
expression. As
far as I can tell voting "no" on this basis is equivalent to me
claiming
the earth is flat because it better fits my world-view.That's a faulty analogy. In mathematics, the square of any number,
positive or negative, yields a positive result. Any scientific or
graphing
calculator will match that behavior. I did sqr(-3) in the Windows
Calculator just now and it outputted 9, not -9.Likewise, both
pow(-3, 2)as well as(-3) ** 2yield9. I'm not
arguing that an even power of a negative base should yield a negative
outcome; I'm arguing that what you deem to be intuitive is based on a
misconception.From http://en.wikipedia.org/wiki/Square_(algebra):
"One of the important properties of squaring, for numbers as well as in
many other mathematical systems, is that (for all numbers x), the square
of
x is the same as the square of its additive inverse -x. That is, the
square
function satisfies the identity x2 = (-x)2. This can also be expressed by
saying that the squaring function is an even function."See what they're doing there? They disambiguate the expression to
(-x)2, which is the same as(-3) ** 2or(-$x) ** 2.Now, I understand why some programming languages behave differently from
the algebraic standard. I don't agree with it, but I understand their
reasoning. Claiming that "the squaring function should always be an even
function" is the equivalent of saying that the Earth is flat is faulty
because it completely ignores the facts that support that argument, just
as
it would be faulty for me to ignore the facts that support yours.Not just some, more than 75% of the languages I've investigated do that.
Curiously, Visual Basic does it this way, whereas Excel doesn't :) I've
listed them here: https://wiki.php.net/rfc/pow-operator#discussionI believe that, especially for a KISS language like PHP, our top priority
with math operators should be to match arithmetic laws as closely and as
intuitively as possible. The average PHP developer is going to do -3 **
2
and expect a result of 9, not -9, and rightly so I think.And arithmetic law states that
-3 ** 2should be interpreted as-(3 ** 2). See also:
http://en.wikipedia.org/wiki/Order_of_operations#Exceptions_to_the_standardIt's only in programming languages that this behaviour may be different
due to historical reasons or what not.You're free to disagree and you certainly have valid reasons for doing
so,
but please try to keep in mind that there is a valid argument on the
other
side of this, as well.Your case seems to promote following a minority of programming languages
that do this, though.--Kris
--
Tjerk
So just to tie it all together (and please correct me if I'm mistaken),
your argument is basically that:-x is actually -1 * x. Therefore, -3 ** 2 would actually be -1 * 3 ** 2.
Due to order of operations, that comes out to -1 * 9 == -9.
I suppose you could look at it that way; the minus here is treated as an
operator rather than something that belongs to the number it's next to.
But now, let's look at another scenario:
<?php
$x = -3; // Or $x = -1 * 3, if you wish.
$y = $x ** 2;
?>
What would be the value of $y under this RFC?
That would obviously be 9, it can't be anything else.
--Kris
--
Tjerk
Tjerk, I hadn't noticed this part of your patch before.
https://github.com/datibbaw/php-src/commit/f60b98cf7a8371233d800a6faa286ddba4432d02
I don't think this is necessary and it looks odd having pow as a
language construct. There is nothing wrong with having pow() as a
regular legacy function here.
Without this piece I think adding ** is a good idea.
-Rasmus
Tjerk, I hadn't noticed this part of your patch before.
https://github.com/datibbaw/php-src/commit/f60b98cf7a8371233d800a6faa286ddba4432d02
I don't think this is necessary and it looks odd having pow as a
language construct. There is nothing wrong with havingpow()as a
regular legacy function here.Without this piece I think adding ** is a good idea.
I already voted, but I have to second that.
--
Regards,
Mike
Hi Rasmus,
Tjerk, I hadn't noticed this part of your patch before.
https://github.com/datibbaw/php-src/commit/f60b98cf7a8371233d800a6faa286ddba4432d02
I don't think this is necessary and it looks odd having pow as a
language construct. There is nothing wrong with havingpow()as a
regular legacy function here.
When Pierre suggested it I admittedly had not thought it through enough
what the possible issues could be and to paraphrase Phil Sturgeon, doing
this would break "public function pow() { }" and that's not acceptable.
This obviously means that the voting has to be broken off ... like, again.
I'm so sorry about this; it seems that the truly good observations only
come during voting phase ...
The following will be done:
- Voting gets closed
- Status goes back to Discussion
- Code changes will be made and will be documented in the RFC
- RFC stays that way until next year
- Voting opens again.
Without this piece I think adding ** is a good idea.
-Rasmus
--
Tjerk
On Sat, Dec 21, 2013 at 8:35 AM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
Hi Rasmus,
On Sat, Dec 21, 2013 at 6:24 AM, Rasmus Lerdorf rasmus@lerdorf.comwrote:
Tjerk, I hadn't noticed this part of your patch before.
https://github.com/datibbaw/php-src/commit/f60b98cf7a8371233d800a6faa286ddba4432d02
I don't think this is necessary and it looks odd having pow as a
language construct. There is nothing wrong with havingpow()as a
regular legacy function here.When Pierre suggested it I admittedly had not thought it through enough
what the possible issues could be and to paraphrase Phil Sturgeon, doing
this would break "public functionpow(){ }" and that's not acceptable.This obviously means that the voting has to be broken off ... like, again.
I'm so sorry about this; it seems that the truly good observations only
come during voting phase ...The following will be done:
- Voting gets closed
- Status goes back to Discussion
- Code changes will be made and will be documented in the RFC
The changes have been made, the offending commit has been reverted and the
PR updated. Travis reported a build failure but afaict not due to these
changes.
- RFC stays that way until next year
- Voting opens again.
Waiting for that long seemed a bit overkill, so I've reopened the vote now.
Whoever changed or removed their vote because of the construct issue,
please review the changes and update their vote where necessary.
Without this piece I think adding ** is a good idea.
-Rasmus
--
Tjerk
--
Tjerk
Kris Craig wrote (on 20/12/2013):
But now, let's look at another scenario:
<?php
$x = -3; // Or $x = -1 * 3, if you wish.
$y = $x ** 2;
?>
What would be the value of $y under this RFC?
That has nothing to do with operator associativity: $x has already been
calculated as -3, just as if it were $y = (-3) ** 2
Consider the same thing with mixed addition and multiplication:
$y = 1 + 2 * 3;
// $y is 7, due to operator precedence
$y = (1 + 2) * 3;
// $y is 9, due to the brackets
$x = 1 + 2;
$y = $x * 3;
// $x is 3, so $y is 9; operator precedence is irrelevant
As I said before, I think people don't always think of "-3" as an
operator applied to a literal, but by the same token, they are rather
unlikely to write something like "-$x". That limits this whole debate on
associativity to those cases where somebody hard-codes a negative value
like -3, and doesn't think to add parentheses.
Regards,
Rowan Collins
[IMSoP]
-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Friday, December 20, 2013 10:28 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: power operator (again)Kris Craig wrote (on 20/12/2013):
But now, let's look at another scenario:
<?php
$x = -3; // Or $x = -1 * 3, if you wish.
$y = $x ** 2;
?>
What would be the value of $y under this RFC?
That has nothing to do with operator associativity: $x has already been
calculated as -3, just as if it were $y = (-3) ** 2
That's actually wrong. Consider the following code snippet:
echo ( -3 * 2); // -6
$x = -3;
echo $x * 2; // -6 -> does not behave like (-3) * 2
$x = "-3";
echo $x * 2; // -6 -> does not behave like (-3) * 2
But I think it would be more intuitive if it would behave as (-3)
Consider the same thing with mixed addition and multiplication:
$y = 1 + 2 * 3;
// $y is 7, due to operator precedence$y = (1 + 2) * 3;
// $y is 9, due to the brackets$x = 1 + 2;
$y = $x * 3;
// $x is 3, so $y is 9; operator precedence is irrelevant
Nope, that's not true. 1+2 is just already evaluated and the result was stored in $x rather than the expression.
As I said before, I think people don't always think of "-3" as an
operator applied to a literal, but by the same token, they are rather
unlikely to write something like "-$x". That limits this whole debate on
associativity to those cases where somebody hard-codes a negative value
like -3, and doesn't think to add parentheses.Regards,
Rowan Collins
[IMSoP]
echo ( -3 * 2); // -6
$x = -3;
echo $x * 2; // -6 -> does not behave like (-3) * 2
This is an extremely poor choice of example: (-3) * 2 and -(3*2) both
evaluate to -6 anyway, since unary minus is effectively multiplication
by -1, and therefore commutative with multiplication.
However, the last line does behave like "(-3) * 2", because left
operand of the * has already been calculated and stored in $x; it could
have been calculated using "$x = 10 - 13", in which case you could see
it as equivalent to "(10 - 13) * 2" - the brackets basically meaning
"calculate this bit first before you even look at the rest of the
expression".
Nope, that's not true. 1+2 is just already evaluated and the result was stored in $x rather than the expression.
That is exactly what I was trying to say: the expression $x * 3 does not
need any rules of operator precedence, because it has only one operator
(unless you count the $ sigil as an operator); if $x was previously
assigned based on some other expression, the details of that expression
are entirely irrelevant, only their answer matters.
The point being that all this discussion of precedence only applies if
the unary minus operator appears in the same expression as the power
operator. But it's very unlikely that anyone would write "$sq = -3 ** 2"
rather than just "$sq = 9"; more likely, they will write "$sq =
$calculated_value ** 2", which has no ambiguity, and will work as
expected for any value of "$calculated_value".
Regards,
--
Rowan Collins
[IMSoP]
-----Original Message-----
From: Rowan Collins [mailto:rowan.collins@gmail.com]
Sent: Saturday, December 21, 2013 1:00 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: power operator (again)echo ( -3 * 2); // -6
$x = -3;
echo $x * 2; // -6 -> does not behave like (-3) * 2This is an extremely poor choice of example: (-3) * 2 and -(3*2) both
evaluate to -6 anyway, since unary minus is effectively multiplication
by -1, and therefore commutative with multiplication.
Indeed, was probably too tired when I wrote the example :) sorry for cluttering up the discussion