Power function as operator

On Fri, Nov 22, 2013 at 9:58 AM, Tjerk Meesters tjerk.meesters@gmail.comwrote:

It introduces the pow() function as an operator ** (double asterisk), as

can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

I would prefer the more math standard ^ (carat) but as that's a bitwise
operator (XOR) I know my dream will never be realized ;)

On Fri, Nov 22, 2013 at 11:58 AM, Tjerk Meesters
tjerk.meesters@gmail.comwrote:

Hi,

To challenge myself I had tasked myself to introduce a new operator and
opcode to the language; now that I'm done with it, I wanted to measure the
response on the list to actually get it merged before writing an RFC.

My work can be found here:
https://github.com/datibbaw/php-src/compare/pow-operator

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

The logic gets exposed via the ZEND_POW opcode and all the logic that went
into pow() itself is copied into it. The exceptions are that an expression
such as [] ** 2 (squared empty array) will cause a fatal error because the
operands are incompatible, whereas pow([], 2) would give 0.

Why this operator? Basically because:

1. it's shorter (the keyboard rejoices).
2. it's faster (no ZEND_CALL).
3. it's found in other languages too.

I've only implemented one of the test suites; there are quite a few for
just one function, but when needed I can add those others as well.

Btw, changes to vld aren't pushed yet.

Let me know!

--

Tjerk

I definitely like the idea of having pow as an operator. I've actually been
wanting to copy that from Python for a while. I'm all for it.

Definitely something that is missing and would be a welcome addition.

Where have you placed it in terms of operator precedence?

Hi,

To challenge myself I had tasked myself to introduce a new operator and
opcode to the language; now that I'm done with it, I wanted to measure the
response on the list to actually get it merged before writing an RFC.

My work can be found here:
https://github.com/datibbaw/php-src/compare/pow-operator

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

The logic gets exposed via the ZEND_POW opcode and all the logic that went
into pow() itself is copied into it. The exceptions are that an expression
such as [] ** 2 (squared empty array) will cause a fatal error because the
operands are incompatible, whereas pow([], 2) would give 0.

Why this operator? Basically because:

1. it's shorter (the keyboard rejoices).
2. it's faster (no ZEND_CALL).
3. it's found in other languages too.

I've only implemented one of the test suites; there are quite a few for
just one function, but when needed I can add those others as well.

Btw, changes to vld aren't pushed yet.

Let me know!

--

Tjerk

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

This is great! I like Python's ** operator and having it in PHP would be
great too. It's a very versatile mathematical operator. With ** you get
three for the price of one: You can do powers ($x ** 2), you can do
square roots ($x ** (1/2)) and you can do reciprocals ($x ** -1), though
for that last one there was already 1 / $x.

I will definitely vote for this proposal if it works and you make an RFC.

I do have one concern, however. It looks like your current pull request
doesn't make gmp support it. Nikita's (nikic) proposal to add internal
operator overloading so that the gmp library could support it has been
merged in. So could you make it overloadable (if it isn't already), and
make sure gmp supports it?

Thanks!

Andrea Faulds
http://ajf.me/

+1

Does it work with https://wiki.php.net/rfc/operator_overloading_gmp ?

Am 22.11.2013 17:58, schrieb Tjerk Meesters:

Hi,

To challenge myself I had tasked myself to introduce a new operator and
opcode to the language; now that I'm done with it, I wanted to measure the
response on the list to actually get it merged before writing an RFC.

My work can be found here:
https://github.com/datibbaw/php-src/compare/pow-operator

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

The logic gets exposed via the ZEND_POW opcode and all the logic that went
into pow() itself is copied into it. The exceptions are that an expression
such as [] ** 2 (squared empty array) will cause a fatal error because the
operands are incompatible, whereas pow([], 2) would give 0.

Why this operator? Basically because:

1. it's shorter (the keyboard rejoices).
2. it's faster (no ZEND_CALL).
3. it's found in other languages too.

I've only implemented one of the test suites; there are quite a few for
just one function, but when needed I can add those others as well.

Btw, changes to vld aren't pushed yet.

Let me know!

On Fri, Nov 22, 2013 at 5:58 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:

Hi,

To challenge myself I had tasked myself to introduce a new operator and
opcode to the language; now that I'm done with it, I wanted to measure the
response on the list to actually get it merged before writing an RFC.

My work can be found here:
https://github.com/datibbaw/php-src/compare/pow-operator

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

The logic gets exposed via the ZEND_POW opcode and all the logic that went
into pow() itself is copied into it. The exceptions are that an expression
such as [] ** 2 (squared empty array) will cause a fatal error because the
operands are incompatible, whereas pow([], 2) would give 0.

Why this operator? Basically because:

1. it's shorter (the keyboard rejoices).
2. it's faster (no ZEND_CALL).
3. it's found in other languages too.

I've only implemented one of the test suites; there are quite a few for
just one function, but when needed I can add those others as well.

Btw, changes to vld aren't pushed yet.

Let me know!

I don't really see a need for this operator in PHP. From my experience
pow() isn't some particularly commonly used function, so I don't think it
needs its own operator. (But I don't think that adding it would
particularly hurt either...)

Anyway, if this is added I would strongly recommend to make the operator
non-associative. I have no idea how Python came up with the idea to make **
right-associative, which violates basic programming language design rules
(all binary non-assignment operators are left-associative) and goes against
(at least my) common sense, but now that they made the choice it's likely
unwise to deviate from it by making it left-associative in PHP (see ternary
operator mess...) So I think making it non-associative makes for a safe
middle ground. This will cause 2 ** 3 ** 2 to throw an error and require
you to group it as either (2 ** 3) ** 2 or 2 ** (3 ** 3). Less ambiguity.

Nikita

Hi again,

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

Hi,

To challenge myself I had tasked myself to introduce a new operator and
opcode to the language; now that I'm done with it, I wanted to measure the
response on the list to actually get it merged before writing an RFC.

My work can be found here:
https://github.com/datibbaw/php-src/compare/pow-operator

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

The logic gets exposed via the ZEND_POW opcode and all the logic that went
into pow() itself is copied into it. The exceptions are that an expression
such as [] ** 2 (squared empty array) will cause a fatal error because the
operands are incompatible, whereas pow([], 2) would give 0.

Why this operator? Basically because:

1. it's shorter (the keyboard rejoices).
2. it's faster (no ZEND_CALL).
3. it's found in other languages too.

I've only implemented one of the test suites; there are quite a few for
just one function, but when needed I can add those others as well.

Btw, changes to vld aren't pushed yet.

Let me know!

--

Tjerk

So far, there have been no violent objections against the proposal, so I
shall go ahead and effect the following:

1. Investigate the GMP overloading option.
2. Write an RFC

As for the associativity argument (assuming the precedence is now correct),
if not resolved before the voting begins, I would suggest to move that into
the vote itself, i.e.:
a) don't implement;
b) yes, with left associativity;
c) yes, with right associativity.

--

Tjerk

Hi,

It introduces the pow() function as an operator ** (double asterisk), as
can be found in languages such as Python (with perhaps the notable
difference that it's right associative there).

As a comment: In my view we try to keep the language understandable even
for people who aren't as deep into it as we are. There having power as
function serves two purposes. For one it is a normal function and can
easily identified as such with clear precedence etc. Secondly people can
stick it in their favorite search engine and can understand what it
means. Searching for ** however isn't as trivial.

Is the power operation really that common so we have to have it as an
operator and opcode? I don't know what the threshold is, but -/ might be
a nice unary (square) root operator ;-)

Looking at github search results
https://github.com/search?l=PHP&p=1&q=pow&source=cc&type=Code
I see quite a few search results but most of them duplication (pow.phpt
from our test suite comes very often) and in others I inspected it
didn't see to be critical code paths gaining much from performance in
(in my personal opinion) loosing readability.

Randomly picked example:
} elseif ($dec - pow(2,$i) >= 0) {
vs.
} elseif ($dec - (2 ** $i) >= 0) {
https://github.com/pkeane/exercises/blob/68b58fb11abfbe8301c202b94906a4ec7e041c10/binpal.php#L59
I consider the former to be better to parse with my brain.

And yes, I understand that there are cases where this will boost
performance by quite a bit, but then we'd rather make strlen() an
opcode. ;-)

johannes