Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87021 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3804 invoked from network); 4 Jul 2015 23:30:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2015 23:30:10 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.148 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.148 blu004-omc4s9.hotmail.com Received: from [65.55.111.148] ([65.55.111.148:61832] helo=BLU004-OMC4S9.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 77/70-33330-18C68955 for ; Sat, 04 Jul 2015 19:30:10 -0400 Received: from BLU436-SMTP93 ([65.55.111.137]) by BLU004-OMC4S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 4 Jul 2015 16:30:07 -0700 X-TMN: [b14tr6LjG7z53HM3PvbTx7lKr8zd+92A] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) In-Reply-To: Date: Sun, 5 Jul 2015 01:30:02 +0200 CC: Sherif Ramadan , =?utf-8?Q?Jakub_Kub=C3=AD=C4=8Dek?= , Dmitry Stogov , PHP Internals , Nikita Popov , Aaron Piotrowski , Levi Morrison Content-Transfer-Encoding: quoted-printable References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> To: Andrea Faulds X-Mailer: Apple Mail (2.2098) X-OriginalArrivalTime: 04 Jul 2015 23:30:05.0235 (UTC) FILETIME=[5B61D830:01D0B6B1] Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2) From: bobwei9@hotmail.com (Bob Weinand) > Am 05.07.2015 um 00:50 schrieb Andrea Faulds : >=20 > Hey Sherif, >=20 >> On 4 Jul 2015, at 21:56, Sherif Ramadan = wrote: >>=20 >> I'm proposing that we reconsider removing the warning from floating = point division and here's why. >>=20 >> 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. >>=20 >> 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. >>=20 >> So my conclusion is that... >>=20 >> 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. >>=20 >> 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. >=20 >=20 > Yeah, keeping it around makes sense. >=20 > Thing is, if it=E2=80=99s a problem, you can silence it with @, so = @($a / $b). If that=E2=80=99s slow, we could optimise it (make it call = div_function_no_error or something?) At that point it's just a bit weird. The @ operator IMO shouldn't be the = recommended way to handle fundamental operations. You ideally just check if the divisor is 0 and then do the operation. And at that point, we should just throw the DivisionByZeroError. Honestly, a warning is just the wrong thing to use. Either you enable it = (like double division in C) or disable it completely (runtime exception = in C). I can get behind both, but not behind a warning. Thanks, Bob.=