# rfc: pow-operator - Thread: https://externals.io/message/70325 - Original archive: https://news-web.php.net/php.internals/70325 - Started by Tjerk Meesters on 2013-11-23T13:51:48+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/70325.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #70325 — Tjerk Meesters — 2013-11-23T13:51:48+00:00 URL: https://externals.io/message/70325#70325 Hi guys, I'm done drafting the RFC for the exponential operator: https://wiki.php.net/rfc/pow-operator Since this is a language feature, voting will only start in two weeks from now. Best, Tjerk --- ## #70329 — Derick Rethans — 2013-11-23T17:43:35+00:00 URL: https://externals.io/message/70325#70329 · In reply to: #70325 > Hi guys, > > I'm done drafting the RFC for the exponential operator: > https://wiki.php.net/rfc/pow-operator > > Since this is a language feature, voting will only start in two weeks from > now. Something that I missed in there, are you thinking of adding: **= in there too, just like we have: $a += 5; cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #70335 — Kris Craig — 2013-11-24T00:31:09+00:00 URL: https://externals.io/message/70325#70335 · In reply to: #70329 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. --Kris > > > > […] > from > > […] > > Something that I missed in there, are you thinking of adding: > > **= > > in there too, just like we have: > > $a += 5; > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > Posted with an email client that doesn't mangle email: alpine --- ## #70336 — Andrea Faulds — 2013-11-24T00:51:52+00:00 URL: https://externals.io/message/70325#70336 · In reply to: #70335 > 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/ --- ## #70337 — Kris Craig — 2013-11-24T00:58:36+00:00 URL: https://externals.io/message/70325#70337 · In reply to: #70336 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 > > > > > > […] > 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/ --- ## #70338 — Chris London — 2013-11-24T01:13:18+00:00 URL: https://externals.io/message/70325#70338 · In reply to: #70335 > > 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". A more appropriate example would be to say should we treat -3 ^ 2 as (-3) ^ 2 == 9 or as -(3 ^ 2) == -9 > Without those options, my vote would be a firm No. > > --Kris > > > > > > […] --- ## #70339 — Ferenc Kovacs — 2013-11-24T01:15:26+00:00 URL: https://externals.io/message/70325#70339 · In reply to: #70337 > I don't see any benefit in using Python's unique behavior as a model. they aren't the only ones doing it that way, there were a bunch of languages mentioned for left, right and no associativity, maybe it would be useful to list them on the rfc page. > The > model should conform to established mathematical laws, not some other > arbitrarily chosen scripting language. the power tower comes from mathematical laws, and that would support the right association, as mentioned by Jakub in the other thread. > 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 ); > see above, and this was also discussed in the other thread. > > 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 > > I think it would make sense to extend the rfc with the issues brought up, and answer them there, because it seems that we started repeating the same arguments pro and con. ps: please don't top post. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #70340 — Kris Craig — 2013-11-24T01:18:38+00:00 URL: https://externals.io/message/70325#70340 · In reply to: #70338 > 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 --- ## #70341 — Sherif Ramadan — 2013-11-24T01:49:14+00:00 URL: https://externals.io/message/70325#70341 · In reply to: #70340 For a comparative list of languages that implement the exponent operator as either right-associative or left-associative I've gathered the following, non-exhaustive list (see quasi-bibliography below)... | Right-associative | Left-associative | +--------------------+--------------------+ | Perl | VB | | Python | BASIC | | Tcl | Octave | | Freemat | Matlab | | Scilab | D | | Sage | | | Mathematica | | | Haskell | | | R | | | Ruby | | | Bash | | +--------------------+--------------------+ Lanaguages that don't have an exponent operator ------------------------------------------------ C C++ C# Java Javascript ActionScript ---- Languages that don't have exponent operators seem to have routes from C-style languages where at the time no machine instruction existed for the operation and so instead a library routine was used. Certainly PHP would benefit from an exponent operator here and I don't think going against the trend of languages making it right-associative in order to make power-towering easier for the user is necessarily a bad idea. Just my 0.00000002 cents! --- Qausi-bibliography --- https://plus.google.com/u/0/104277466162910953762/posts/e3jCt51VfmD http://perldoc.perl.org/perlop.html http://www.tcl.tk/cgi-bin/tct/tip/274.html http://book.realworldhaskell.org/read/getting-started.html --- ## #70342 — Tjerk Meesters — 2013-11-24T02:02:23+00:00 URL: https://externals.io/message/70325#70342 · In reply to: #70341 Hi, On Sun, Nov 24, 2013 at 9:49 AM, Sherif Ramadan wrote: > > For a comparative list of languages that implement the exponent operator > as either right-associative or left-associative I've gathered the > following, non-exhaustive list (see quasi-bibliography below)... > > | Right-associative | Left-associative | > +--------------------+--------------------+ > | Perl | VB | > | Python | BASIC | > | Tcl | Octave | > | Freemat | Matlab | > | Scilab | D | > | Sage | | > | Mathematica | | > | Haskell | | > | R | | > | Ruby | | > | Bash | | > +--------------------+--------------------+ > Awesome! Thanks for finding those; I have added them under the Discussion section. > > > Lanaguages that don't have an exponent operator > ------------------------------------------------ > > C > C++ > C# > Java > Javascript > ActionScript > > ---- > > Languages that don't have exponent operators seem to have routes from > C-style languages where > at the time no machine instruction existed for the operation and so > instead a library routine > was used. > > Certainly PHP would benefit from an exponent operator here and I don't > think going against the trend > of languages making it right-associative in order to make power-towering > easier for the user is > necessarily a bad idea. > > > Just my 0.00000002 cents! > > --- Qausi-bibliography --- > > https://plus.google.com/u/0/104277466162910953762/posts/e3jCt51VfmD > http://perldoc.perl.org/perlop.html > http://www.tcl.tk/cgi-bin/tct/tip/274.html > http://book.realworldhaskell.org/read/getting-started.html > -- -- Tjerk --- ## #70343 — Sanford Whiteman — 2013-11-24T03:22:02+00:00 URL: https://externals.io/message/70325#70343 · In reply to: #70341 > | Right-associative | Left-associative | > +--------------------+--------------------+ > | Perl | VB | > | Python | BASIC | > | Tcl | Octave | > | Freemat | Matlab | > | Scilab | D | > | Sage | | > | Mathematica | | > | Haskell | | > | R | | > | Ruby | | > | Bash | | > +--------------------+--------------------+ VBScript, VB6, and VB.NET are different languages. At the very least, you must separate VBScript and VB.NET because they are competitive technologies in the same space. ColdFusion is curiously left out of the left-associative department, since I already brought it up twice. F# has right-associative **. > Lanaguages that don't have an exponent operator > ------------------------------------------------ > C > C++ > C# > Java > Javascript > ActionScript + SQL -- S. --- ## #70344 — Galen Wright-Watson — 2013-11-24T05:46:23+00:00 URL: https://externals.io/message/70325#70344 · In reply to: #70341 On the left-vs-right-vs-non-associative debate: it seems to me that the reason for supporting associativity for any binary operator is to cut down on the number of parentheses that must be typed, which can help cut down on visual clutter. Otherwise, you might as well use a Lisp. (What are other reasons?) If that's true, then whether to pick left or right association should depend on the most common use-case. Personally, I'd be much more likely to mean 2**(3**2), as (2**3)**2 is equivalent to 2 ** (3*2) but is less performant. Also, by making ** right-associative, 2**3**2 is visually more distinct from 2 ** (3*2); if left-associative, 2 ** (3 ** 2) and 2 ** (3*2) would be more easily confused when reading or writing. Closely related to the power-tower argument is the relation between associativity and hyper operations, which offers another reason why right association is more natural in mathematics. Defining hyper operations in terms of hypo operations (successor -> addition -> multiplication -> exponentiation -> tetration ...) requires right associativity. However, as addition and multiplication are associative (and the computational versions of these operations aren't usually implemented in terms of each other), it doesn't much matter whether they're made left- or right-associative. For reasons others have stated in this conversation, computational + and * are generally implemented as left-associative. Mathematical exponentiation isn't associative (hence this whole debate), so the reasons for allowing a switch from right- to left- association simply isn't present. Of course, the computational operators aren't the same as the mathematical, so this isn't actually a rigorous argument in favor of right association. Finally, here's a graphic depicting the "exponentiation is right-associative in math" argument (sorry text-readers, you'll have to go to http://i.imgur.com/G9aIn6X.png if you want to see the image): [image: Inline image 2] Of course, this doesn't help at all to determine whether ** should be associative or not. --- ## #70345 — Sanford Whiteman — 2013-11-24T06:27:33+00:00 URL: https://externals.io/message/70325#70345 · In reply to: #70344 > Also, by making ** right-associative, 2**3**2 is visually more > distinct from 2 ** (3*2); if left-associative, 2 ** (3 ** 2) and 2 > ** (3*2) would be more easily confused when reading or writing. Hmm... to me, this argument is pretty circuitous, as it assumes people actively remember ( x ** y ) ** z == x ** ( y * z ) and yet are not using the optimization nor parentheses. It's hard for me to follow your logic here. Plus, you shouldn't say something will be less performant unless you know the compiler won't optimize it on its own! If you're concerned (not unreasonably) about confusing ** and *, why not suggest another character instead? -- S. --- ## #70347 — Tjerk Meesters — 2013-11-24T06:58:36+00:00 URL: https://externals.io/message/70325#70347 · In reply to: #70335 > 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. > > Without those options, my vote would be a firm No. > > --Kris > > > > > > […] > -- -- Tjerk --- ## #70348 — Tjerk Meesters — 2013-11-24T09:57:56+00:00 URL: https://externals.io/message/70325#70348 · In reply to: #70329 > > > > […] > from > > […] > > Something that I missed in there, are you thinking of adding: > > **= > > in there too, just like we have: > > $a += 5; > Sure, I've created a new branch for that and added it under the Discussion section. If there are no objections it will get added to the proposal. Thanks! > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > Posted with an email client that doesn't mangle email: alpine > -- -- Tjerk --- ## #70349 — Kris Craig — 2013-11-24T10:37:57+00:00 URL: https://externals.io/message/70325#70349 · In reply to: #70347 On Sat, Nov 23, 2013 at 10:58 PM, Tjerk Meesters wrote: > > 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 --- ## #70350 — Nikita Popov — 2013-11-24T11:05:40+00:00 URL: https://externals.io/message/70325#70350 · In reply to: #70347 On Sun, Nov 24, 2013 at 7:58 AM, Tjerk Meesters wrote: > > > > […] > to > > […] > > 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 --- ## #70351 — Tjerk Meesters — 2013-11-24T11:31:54+00:00 URL: https://externals.io/message/70325#70351 · In reply to: #70350 > On Sun, Nov 24, 2013 at 7:58 AM, Tjerk Meesters wrote: > > > […] > > 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.) > Aha! I haven't yet learned all the Bison tricks :) With the unary minus in place (should we adjust the unary plus as well?), this would be the behaviour: -3 ** 2 == 9 1 -3 ** 2 == -8 I'll add this in the RFC. > > Nikita > -- -- Tjerk --- ## #70352 — Robert Williams — 2013-11-24T11:33:05+00:00 URL: https://externals.io/message/70325#70352 · In reply to: #70345 Hmm... to me, this argument is pretty circuitous, as it assumes people actively remember ( x ** y ) ** z == x ** ( y * z ) and yet are not using the optimization nor parentheses. Yes, people will use that simplification if they know it; that's sort of the point of using right-associativity: it makes things easier and clearer in those cases where you actually *need* to use exponentiation. Folks who don't use the operator that often will probably use parentheses no matter what, or they'll just use `pow()` like they've always done. Those who will use the operator regularly will know how it works, and they'll appreciate that they can use it without having to include a bunch of extraneous parenthesis. I'd also like to point out that PHP programmers are, well, programmers. I don't know about you, but almost every programmer I know has a much stronger mathematical background than the average person. Given this, I'm surprised at how much concern has been expressed in this discussion that people won't understand how the operator works, nor be able to make the connection to traditional math rules. It strikes me as another case of dumbing down the language so as to not alienate the lowest-level amateur users. Besides, I can just see all the "PHP sucks" articles out there being expanded with examples showing how PHP gets basic math wrong when compared against trendy Ruby and Python, or against the stalwart Perl. They'll further drive home the point by linking to Google (see https://www.google.com/search?q=2%5E3%5E2), Wolfram Alpha (see http://m.wolframalpha.com/input/?i=2%5E3%5E2), or even Bing (see http://www.bing.com/search?q=2%5E3%5E2). And you know what? They'll be right. -- 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). --- ## #70353 — Tjerk Meesters — 2013-11-24T14:15:11+00:00 URL: https://externals.io/message/70325#70353 · In reply to: #70325 Hi, The following notable updates have been made: 1. The exponent assignment operator is added, i.e. "$foo **= 2; // raise $foo to power of 2" 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. 3. Added a list of languages with their respective handling. Have a good week ahead! On Sat, Nov 23, 2013 at 9:51 PM, Tjerk Meesters wrote: > Hi guys, > > I'm done drafting the RFC for the exponential operator: > https://wiki.php.net/rfc/pow-operator > > Since this is a language feature, voting will only start in two weeks from > now. > > > Best, > Tjerk > > -- -- Tjerk --- ## #70354 — Chris London — 2013-11-24T15:26:59+00:00 URL: https://externals.io/message/70325#70354 · In reply to: #70353 On Sun, Nov 24, 2013 at 7:15 AM, Tjerk Meesters 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 --- ## #70355 — Pierre Joye — 2013-11-24T15:56:30+00:00 URL: https://externals.io/message/70325#70355 · In reply to: #70354 > On Sun, Nov 24, 2013 at 7:15 AM, Tjerk Meesters wrote: > > […] > > 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. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #70356 — Sean Coates — 2013-11-24T17:21:26+00:00 URL: https://externals.io/message/70325#70356 · In reply to: #70355 > 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 --- ## #70359 — Robert Williams — 2013-11-24T20:58:24+00:00 URL: https://externals.io/message/70325#70359 · In reply to: #70355 > > > 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($c1**2 + $c2**2) 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). --- ## #70361 — johannes@schlueters.de — 2013-11-24T21:33:56+00:00 URL: https://externals.io/message/70325#70361 · In reply to: #70359 > > $c = sqrt($c1**2 + $c2**2) > > Instead of this: > > $c = sqrt(pow($c1, 2) + pow($c2, 2)) This can even be improved already: $c = hypot($c1, $c2); No need for engine changes, new opcodes and grammar rules :-) johannes --- Next page: https://externals.io/message/70325.md?page=2