Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87023
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain icicle.io designates 199.38.81.6 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <BLU436-SMTP9370569677CE484F3C02E2E2950@phx.gbl>
Date: Sat, 4 Jul 2015 21:10:20 -0500
Cc: Andrea Faulds <ajf@ajf.me>, Sherif Ramadan <theanomaly.is@gmail.com>,
 =?utf-8?Q?Jakub_Kub=C3=AD=C4=8Dek?= <kelerest123@gmail.com>,
 Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>,
 Nikita Popov <nikita.ppv@gmail.com>, Levi Morrison <levim@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <717AC9A1-9AF0-4AF5-B8D7-A1EACB1EE44A@icicle.io>
References: <CA+9eiLvd0YPKtED9CgU_thC9HUfTquaMJNf_9zQC0jyeX+rTuw@mail.gmail.com> <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <CA+9eiLsEDb-GuP4pRi-C8GQ2N+q7K=f-gmUMMxzxyy54CDy67w@mail.gmail.com> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <CA+9eiLt3ScjNDuYLW=fLY2BUepzcRz=XPxbQCjSoy++0p67YNw@mail.gmail.com> <BLU437-SMTP1001E15E94ACA9AEE4676D6E2AA0@phx.gbl> <B4ACC432-714A-478B-9E1B-C9C532710598@ajf.me> <BLU436-SMTP121ED71E7D26AD9D99D9668E2AA0@phx.gbl> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> <BLU436-SMTP69FBA3B51DA1D27C3A73A4E2970@phx.gbl> <CA+9eiLtZb+VNLNb_i0F+GfobroxffT50Sj564L64GSYmnRR2Sg@mail.gmail.com> <CAHvhOfj288YjxJXngVxULTgJo4QvWeo0=Zu3atwF3Mb-GeR+vQ@mail.gmail.com> <CAL+t6cGy=VFJ2+gHdQJjayc8927_u4p2SnU08nR_5bbC7sAzag@mail.gmail.com> <DE04F14B-1321-42D9-AD09-CF645F03B33A@ajf.me> <BLU436-SMTP9370569677CE484F3C02E2E2950@phx.gbl>
To: Bob Weinand <bobwei9@hotmail.com>
Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
From: aaron@icicle.io (Aaron Piotrowski)



> On Jul 4, 2015, at 6:30 PM, Bob Weinand <bobwei9@hotmail.com> wrote:
>=20
>=20
>> Am 05.07.2015 um 00:50 schrieb Andrea Faulds <ajf@ajf.me>:
>>=20
>> Hey Sherif,
>>=20
>>> On 4 Jul 2015, at 21:56, Sherif Ramadan <theanomaly.is@gmail.com> wrote:=

>>>=20
>>> I'm proposing that we reconsider removing the warning from floating poin=
t 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 providi=
ng useful error information to the user, which may help them debug potential=
ly buggy code. It's true that it's not exceptional since there is now well d=
efined behavior in the case of changing division by zero to IEEE 754 standar=
d in PHP. However, PHP didn't actually distinguish between integer division a=
nd floating point division prior to intdiv. So in the case of division by ze=
ro 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 n=
ot they created a potential division by zero scenario by deducing how they a=
rrived at INF at some point in their code. This is creating an unnecessary b=
urden when we've always provided the user with the useful error information i=
n the past. I'm not sure why we should remove it now, but based on this conv=
ersation I can see that the confusion resonates around this urge to convert t=
he warning to an exception and the conflict of it not being exceptional (in t=
he 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 divis=
ion by zero in floating point arithmetic. No, we shouldn't remove the warnin=
g since it still provides useful information to the person debugging the cod=
e. Debugging the code without this warning can be a monstrosity since you wo=
n't necessarily know at which point in a compounded operation the division b=
y 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 c=
ase, 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 warn=
ing. I think what they would care about more is the consistency of the retur=
n 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_functio=
n_no_error or something?)
>=20
> At that point it's just a bit weird. The @ operator IMO shouldn't be the r=
ecommended way to handle fundamental operations.
>=20
> You ideally just check if the divisor is 0 and then do the operation.
> And at that point, we should just throw the DivisionByZeroError.
>=20
> 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)=
.
>=20
> I can get behind both, but not behind a warning.
>=20
> Thanks,
> Bob.
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

+1

In my opinion division by zero should result in some notification. I think a=
 DivisionByZeroError seems the most appropriate. If a user wants the result o=
f NaN or Inf it is trivial to write a function for that purpose. Perhaps PHP=
 could provide such a function.

Aaron Piotrowski=