Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87016 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 86960 invoked from network); 4 Jul 2015 20:56:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2015 20:56:14 -0000 Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.215.41 mail-la0-f41.google.com Received: from [209.85.215.41] ([209.85.215.41:35827] helo=mail-la0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 50/80-02984-C6848955 for ; Sat, 04 Jul 2015 16:56:13 -0400 Received: by lagh6 with SMTP id h6so116830154lag.2 for ; Sat, 04 Jul 2015 13:56:09 -0700 (PDT) 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=0lykcJANiKNF3hKR6ZYEgZID1bjT+KXZ5STxeyIoXwc=; b=Vih2EZZ0vYfiW0sDLVqACZIDTnnwlRarII0RPbFlsjGLaiHXjvdu61zw7echX8lpcI PeVKNskeWdGBgDyh4Ebl0teTitKxJ+gsdh3G1xXvp3DrEsjeiiV/5Pe93U3eBT6zg7BW uinFQw96jWGhnwC/X2Igpb3XLvqmFMTE1x31s3kQFKFYFLUslu0z+7j8WG0CwWRIC/wi m+fMJiTDAxjjWFMAHq6murzKnlGqibXdoC09MO36gF/eyzZNwhnJiam4dwJBo7BXWp3Z h6xIA/kZSNsFWo2CUTL4I7mH36hzmxLm+ec4QK10gACMjhhS8CVRPGr6MfRmyIHkfAec PA5Q== MIME-Version: 1.0 X-Received: by 10.112.157.36 with SMTP id wj4mr15686228lbb.115.1436043369158; Sat, 04 Jul 2015 13:56:09 -0700 (PDT) Received: by 10.25.35.216 with HTTP; Sat, 4 Jul 2015 13:56:09 -0700 (PDT) In-Reply-To: References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> Date: Sat, 4 Jul 2015 16:56:09 -0400 Message-ID: To: =?UTF-8?B?SmFrdWIgS3Viw63EjWVr?= Cc: Dmitry Stogov , Bob Weinand , Andrea Faulds , PHP Internals , Nikita Popov , Aaron Piotrowski , Levi Morrison Content-Type: multipart/alternative; boundary=001a11c2abc2e6a67e051a12e6d6 Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2) From: theanomaly.is@gmail.com (Sherif Ramadan) --001a11c2abc2e6a67e051a12e6d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey guys, I'm proposing that we reconsider removing the warning from floating point division and here's why. While IEEE 754 defines special values for floating point arithmetic when division by zero occurs, there's nothing stopping the language from providing useful error information to the user, which may help them debug potentially buggy code. It's true that it's not exceptional since there is now well defined behavior in the case of changing division by zero to IEEE 754 standard in PHP. However, PHP didn't actually distinguish between integer division and floating point division prior to intdiv. So in the case of division by zero the warning was useful to help someone catch their mistake. Now, the onus is on the person writing the code to decipher whether or not they created a potential division by zero scenario by deducing how they arrived at INF at some point in their code. This is creating an unnecessary burden when we've always provided the user with the useful error information in the past. I'm not sure why we should remove it now, but based on this conversation I can see that the confusion resonates around this urge to convert the warning to an exception and the conflict of it not being exceptional (in the case of floating point math) since there is now well defined behavior. So my conclusion is that... Yes, it's not exceptional. No, we shouldn't throw an exception for division by zero in floating point arithmetic. No, we shouldn't remove the warning since it still provides useful information to the person debugging the code. Debugging the code without this warning can be a monstrosity since you won't necessarily know at which point in a compounded operation the division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates an overflow resulting in INF. Though 0 / INF results in 0. So an operation like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where $x happened to be 0 in one particular case, makes both hunting down and reproducing the bug quite difficult without some direction. The warning has historically provided this direction in the past and I believe that removing it now will only further the confusion. I don't think people actually care about whether or not we keep the warning. I think what they would care about more is the consistency of the return value and defined behavior, which I believe we have already addressed very well. On Thu, Jul 2, 2015 at 4:44 AM, Jakub Kub=C3=AD=C4=8Dek wrote: > +1 for everything proposed here :-) > > > Kubo2 > > > 2015-07-02 9:59 GMT+02:00 Dmitry Stogov : > > On Thu, Jul 2, 2015 at 3:26 AM, Bob Weinand wrote= : > > > >> > Am 29.06.2015 um 19:14 schrieb Andrea Faulds : > >> > > >> > Hi again, > >> > > >> >> On 29 Jun 2015, at 18:02, Bob Weinand wrote: > >> >> > >> >> Yes, it generally makes sense... > >> >> Then I have other questions: > >> >> > >> >> - Why do we then still have a Warning? Either we have well-defined > >> behavior, or we throw an exception. Well-defined behavior *plus* a > warning > >> is IMO non-sense. > >> > > >> > That=E2=80=99s weird, yeah. We don=E2=80=99t throw warnings for the = math functions > when > >> you give them odd inputs, e.g. sin(INF) is just NAN, no warning. > >> > > >> > I think removing it would make sense. > >> > > >> >> - Is it intentional for intdiv and % to throw an Exception instead = of > >> Error or some more specific DivisionByZeroError or similar? (yes, I > know, > >> Error is only very recent, but the question still needs to be asked). > >> > > >> > Hmm. Using Error might make some sense given it used to raise > E_WARNING. > >> I think DivisionByZeroError sounds like a good idea. > >> > >> Hey, > >> > >> I just committed that to master=E2=80=A6 > >> > >> But I noticed that intdiv(PHP_INT_MIN, -1) isn't very well suited for = a > >> DivisionByZeroError. > >> > >> What do you think about adding an ArithmeticError for that case (and > >> making DivisionByZeroError subclass of it)? > >> That ArithmeticError could then be reused for negative bitshifts, whic= h > >> would solve the question what to do with that too. > >> > > > > I think we should introduce ArithmeticError, as you propose. > > > > Thanks. Dmitry. > > > > > >> > >> Thanks, > >> Bob > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --001a11c2abc2e6a67e051a12e6d6--