Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70781 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51362 invoked from network); 20 Dec 2013 01:27:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Dec 2013 01:27:29 -0000 Authentication-Results: pb1.pair.com smtp.mail=tjerk.meesters@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tjerk.meesters@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.180 as permitted sender) X-PHP-List-Original-Sender: tjerk.meesters@gmail.com X-Host-Fingerprint: 209.85.220.180 mail-vc0-f180.google.com Received: from [209.85.220.180] ([209.85.220.180:40105] helo=mail-vc0-f180.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/D2-42949-00D93B25 for ; Thu, 19 Dec 2013 20:27:28 -0500 Received: by mail-vc0-f180.google.com with SMTP id ia6so873645vcb.25 for ; Thu, 19 Dec 2013 17:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MZ9oEVUeKWEep9fjTf+xjN/g/2wkGK5umjSx8tI1gNQ=; b=cpwUmGyWO2trqEcdSENXQeAu45tbJe/Y1m9VKTlrK2DekPOHRzbYDKxoJAO9A/x6Ud zT801/kI1ANfPFETDhOmCR2oMlvddFfYDMas5EY64TkTNir7SFJwvvVDm50wuMmKTJFN JaVJnuTkpQDUst8hL5CE4EqsVVh8dYjfgQfSVWEdvFyurEhtmTbc5DoI7dYY9zKh+8Ms iZ8CgyZFFK7IYMstrKWixL26c3/CR/+W4TQZDS3mrbAqRdThB4RkqPXugp5HgPqvUyAX qwAEqlUA7YYYLN0l+zClZ7Sgy6SNc7bSMryKZCpslBSMMui5fCD0QAw/doL+D4P2D66C 3eaQ== MIME-Version: 1.0 X-Received: by 10.58.100.244 with SMTP id fb20mr3276398veb.6.1387502845711; Thu, 19 Dec 2013 17:27:25 -0800 (PST) Received: by 10.58.128.33 with HTTP; Thu, 19 Dec 2013 17:27:25 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Dec 2013 09:27:25 +0800 Message-ID: To: Kris Craig Cc: Daniel Lowrey , "internals@lists.php.net" Content-Type: multipart/alternative; boundary=089e013a27083e5b3e04eded2e42 Subject: Re: [PHP-DEV] Re: power operator (again) From: tjerk.meesters@gmail.com (Tjerk Meesters) --089e013a27083e5b3e04eded2e42 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 20, 2013 at 9:22 AM, Kris Craig wrote: > > > > On Thu, Dec 19, 2013 at 4:27 PM, Tjerk Meesters wrote: > >> >> >> >> On Fri, Dec 20, 2013 at 5:50 AM, Kris Craig wrote: >> >>> On Thu, Dec 19, 2013 at 4:33 AM, Daniel Lowrey >>> 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) ** 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 >> > > 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: > > > $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 --089e013a27083e5b3e04eded2e42--