Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52914DA8.7050303@ajf.me>
References: <CAHMUw2GyyABzaVjcMML8hhqm0gxCS5i-fzO5EE-e4b114OPRGA@mail.gmail.com>
	<alpine.DEB.2.10.1311231742510.5542@whisky.home.derickrethans.nl>
	<CAKOpQSw=_Gmv_hCimkoviL+6D4A1OwFBc4zuLkf3dFDWCqzcig@mail.gmail.com>
	<52914DA8.7050303@ajf.me>
Date: Sat, 23 Nov 2013 16:58:36 -0800
Message-ID: <CAKOpQSy34q0DuK70+dUazFyc=FAE+FpApasmG6ax=jOmnxG8Lg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Derick Rethans <derick@php.net>, Tjerk Meesters <tjerk.meesters@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011609bc4ec1d304ebe1bfbd
Subject: Re: [PHP-DEV] rfc: pow-operator
From: kris.craig@gmail.com (Kris Craig)

--089e011609bc4ec1d304ebe1bfbd
Content-Type: text/plain; charset=ISO-8859-1

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



On Sat, Nov 23, 2013 at 4:51 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
>
> On 24/11/13 00:31, Kris Craig wrote:
>
>> 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/
>

--089e011609bc4ec1d304ebe1bfbd--