rfc: pow-operator View as Markdown

I don't see any benefit in using Python's unique behavior as a model. The
model should conform to established mathematical laws, not some other
arbitrarily chosen scripting language. According to Order of Operations,
all operations of the same type within the same context (parentheses) must
be processed in order from left to right. For example, -2 ** 3 ** 2 would
be processed from left to right, like this: pow( pow( -2, 3 ), 2 );

We've introduced multiple options into RFCs before without encountering the
problems you mention. The alternative would be to create a separate RFC
that calls for behavior that conforms to established arithmetic standards.
But it makes more sense to me to put that into one RFC rather than having
two separate threads to discuss what should be one single issue.

--Kris

We should be following standard Order of Operations here. As such, the
option of no associativity should be included. Furthermore, there needs
to
be a voting option regarding how to deal with even exponents of negative
bases; i.e. treat "-3 ^ 2" as "-3 ^ 2 == 9" or as "-(3 ^ 2) == -9".

Without those options, my vote would be a firm No.

I am worried that adding so many options might cause problems. Is it fair
if it passes 3/4, but there is only a plurality for, say,
left-associativity or right-associativity? What if someone votes for it,
but would not have voted for it were it to be left-associative?

I suggest that either Tjerk makes a decision for us and offers a straight
Yes/No choice, or he limits the choices to very few and combines them, so:

• Yes, right-associative

• Yes, left-associative

• No

Oh, and for my personal thoughts on the matter: I know ** from Python, and
I think (2 ** (3 ** 2)) is more useful than ((2 ** 3) ** 2), so I'd like
(-2 ** 3 ** 2) to be -(2 ** (3 ** 2)), just as Python does it.

--
Andrea Faulds
http://ajf.me/

A more appropriate example would be to say should we treat -3 ^ 2 as (-3)
^ 2 == 9 or as -(3 ^ 2) == -9

Ok, though if we want to be completely accurate, I'd go with this: (-3) ^
(2) == 9. Likewise: (1) + (-3) ^ (2) == (1) + ((-3) ^ (2)) == 10.

http://en.wikipedia.org/wiki/Order_of_operations

--Kris

On Sat, Nov 23, 2013 at 10:58 PM, Tjerk Meesters
tjerk.meesters@gmail.comwrote:

To support the latter "-3 ** 2 == 9" we would require a unary minus that
has a higher precedence than the exponent operator and as such falls
outside of the scope of this RFC.

That said, I'm not even sure whether we can support a unary minus with the
current parser.

Ok, I can accept that argument. I'm tempted to chase that unary rabbit
down the hole further, but as you said that would take us off-topic.

I'll just ask this, then: Hypothetically, if a unary minus for negative
numbers was added in the future, how would that affect the behavior being
discussed here with the proposed ** operator? I.e. if we had "-3 ** 2"
with a unary minus, would the outcome be 9 or -9?

--Kris

On Sun, Nov 24, 2013 at 7:58 AM, Tjerk Meesters tjerk.meesters@gmail.comwrote:

We should be following standard Order of Operations here. As such, the
option of no associativity should be included. Furthermore, there needs
to
be a voting option regarding how to deal with even exponents of negative
bases; i.e. treat "-3 ^ 2" as "-3 ^ 2 == 9" or as "-(3 ^ 2) == -9".

To support the latter "-3 ** 2 == 9" we would require a unary minus that
has a higher precedence than the exponent operator and as such falls
outside of the scope of this RFC.

That said, I'm not even sure whether we can support a unary minus with the
current parser.

Huh? We already support a unary minus with the current parser. It has the
same precedence and associativity as ++ (%prec). You can adjust the
relative precedence of ** and - by adjusting the relative precedence of **
and T_INC (or making it completely independent if you like.)

Nikita

Should it not be possible to do something similar than isset? Changing
pow from a function to operator? The big advantage is that any
existing code will benefit from it without code changes.

This approach also makes the syntax much less ambiguous:
pow(-3, 2) // we know what this does, already…

Perhaps the only drawback to this is in the strict comparison operator (if it returns a GMP object instead of strictly a number)…?

As a further aside: in 15 years of PHP dev, I've rarely used pow() and I've never ever seen it show up as a bottleneck of any sort in profiling. Searching GitHub correlates that I'm not alone here: for PHP, a search for "pow(" yields 280,769 code results vs. 4,886,604 for "trim(". At a glance, many of these are inefficient bitwise operations.

S

it not be possible to do something similar than isset? Changing
pow from a function to operator? The big advantage is that any
existing code will benefit from it without code changes.

Personally, I'd much rather see another operator introduced since it more closely mirrors what we do in written math, which makes conversion and validation easier. Some simple examples:

$area = M_PI * $radius**2

Instead of this:

$area = pow(M_PI * $radius, 2)

$pv = $fv / (1 + $i)**$n

Instead of this:

$pv = $fv / pow(1 + $i, $n)

$c = sqrt($c12 + $c22)

Instead of this:

$c = sqrt(pow($c1, 2) + pow($c2, 2))

When you start throwing in nested exponents, the nested pow() calls just get that much messier.

As for existing code (and new code where people will inevitably use pow()), can the function call be optimized away? I know PHP doesn't do heavy optimizations because it happens at runtime, but is this conversion within the realm of what it can do?

--
Bob Williams

Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).

Hi Pierre,

On Sun, Nov 24, 2013 at 7:15 AM, Tjerk Meesters <
tjerk.meesters@gmail.com>wrote:

2. The available votes for the associativity is reduced to either right
   or
   non associative; I'd rather see it done right (pun intended) or done in
   a
   way whereby the developer must put parentheses to disambiguate.

I completely agree. Here's another resource that explains a little more
why
the exponent comes before the negation:
http://mathforum.org/library/drmath/view/55709.html

Replying here about the general idea of having power as an operator, I
really like the optimization brought by this change.

However I don't really like ** and all the confusions it brings
(whether other languages support it or not, from a precedence point of
view).

Should it not be possible to do something similar than isset? Changing
pow from a function to operator? The big advantage is that any
existing code will benefit from it without code changes.

Speeding up existing code sounds like a very good idea actually :) I'll
look into this.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

--

Tjerk