Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.140 as permitted sender)
Message-ID: <BLU436-SMTP121ED71E7D26AD9D99D9668E2AA0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B67682B9-89AF-4D92-94B1-5BDE41D1B9D8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <B4ACC432-714A-478B-9E1B-C9C532710598@ajf.me>
Date: Mon, 29 Jun 2015 19:02:01 +0200
CC: Dmitry Stogov <dmitry@zend.com>,
 PHP Internals <internals@lists.php.net>,
 Nikita Popov <nikita.ppv@gmail.com>,
 Anatol Belski <ab@php.net>
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>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_B67682B9-89AF-4D92-94B1-5BDE41D1B9D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hey Andrea,

> Am 29.06.2015 um 18:49 schrieb Andrea Faulds <ajf@ajf.me>:
>=20
> Hi Bob,
>=20
>> On 29 Jun 2015, at 16:54, Bob Weinand <bobwei9@hotmail.com> wrote:
>>=20
>> I would like to bring this topic back up, as there were users =
confused with it and it's absolutely not consistent what we have now.
>> See also https://bugs.php.net/bug.php?id=3D69957 (As I thought it was =
non-intentional, I went ahead and "fixed" it, was reverted later, hence =
discussing that now here.)
>>=20
>> So, looks like there was some quick decisions and discussion I =
totally had missed.
>> What we have now is:
>>=20
>>> Am 03.04.2015 um 23:13 schrieb Dmitry Stogov <dmitry@zend.com>:
>>>=20
>>> So the summary:
>>>=20
>>> 1) division by zero produces a warning and +/-INF IS_DOUBLE. =
Compile-time
>>> evaluation is disabled.
>>>=20
>>> 3) Modulo by zero produces Exception.Compile-time evaluation is =
disabled.
>>=20
>> Why? Why do we change the one but not the other?
>>=20
>> Why does 0 % 0 throw an Exception, but 0 / 0 NAN?
>> Why does 1 % 0 throw an Exception, but 1 / 0 INF?
>>=20
>> I'd like to either properly return 0, INF or NAN in both cases or in =
none.
>>=20
>> Having different rules for so similar operations is non-sense, I =
think. It just is inconsistent and causes confusion.
>=20
> Those operations are not as similar as you think!
>=20
> In PHP, the complement of % isn=E2=80=99t /, it=E2=80=99s intdiv(). =
intdiv() takes an integer divided and divisor, and produces an integer =
quotient. % also takes an integer dividend and divisor, but produces an =
integer remainder. intdiv() and % work with integer-only inputs and =
always produce integer outputs.
>=20
> /, on the other hand, takes an integer or float dividend and divisor, =
and produces an integer or float fractional result. It might as well =
work only on floats and always produce floats, really, given that it =
behaves the same as if it did.
>=20
> So intdiv() and % work on integers, and / works on integers and =
floats. This informs how they handle certain error cases.
>=20
> For integer division and modulo (PHP=E2=80=99s intdiv() and %), the =
accepted way to handle division by zero is to produce an error. =
There=E2=80=99s no correct or useful result you can produce. In PHP, we =
used to produce FALSE here, which is a different type (boolean). I =
don=E2=80=99t think that was a good idea because of PHP=E2=80=99s weak =
typing. If you use FALSE in some other arithmetic operation, it=E2=80=99ll=
 be coerced to zero, and produce weird results from other operations. =
Sure, there=E2=80=99s an E_WARNING produced, but your code keeps running =
and produces garbage. So, throwing an exception is safer and brings PHP =
into line with established practice in other programming languages.
>=20
> For floating-point division (PHP=E2=80=99s /), on the other hand, =
errors are usually handled differently. IEEE 754 defines special error =
values we can produce: +Infinity, -Infinity and NaN. These are still =
values of the float type, but they=E2=80=99re not normal numbers. They =
flow through floating-point operations in a well-defined manner. For =
example, if you do anything with a NaN and a NaN, you get a NaN, while =
if you divide by zero, you get =C2=B1Infinity, and if you divide by =
Infinity, you get =C2=B10. Again, PHP used to produce FALSE here, which =
has the problems described earlier. =C2=B1Infinity and NaN, on the other =
hand, flow properly through later arithmetic operations. If the error =
affects your result, it will most likely be obvious, because it=E2=80=99ll=
 be =C2=B10, =C2=B1Infinity, or NaN. Yes, you result is garbage, but =
it=E2=80=99s at least obviously so. And, like with the integer =
behaviour, this brings PHP into line with established practice.
>=20
> tl;dr: intdiv() and % have matching behaviour because they work with =
integers and that=E2=80=99s what=E2=80=99s usually does for them, / has =
different behaviour because it works with floats and that=E2=80=99s =
what=E2=80=99s done for them.
>=20
> I hope that makes sense.
>=20
> --
> Andrea Faulds
> http://ajf.me/ <http://ajf.me/>
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.
- 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).

Bob.=

--Apple-Mail=_B67682B9-89AF-4D92-94B1-5BDE41D1B9D8--