> On Jul 4, 2015, at 6:30 PM, Bob Weinand <bobw...@hotmail.com> wrote: > > >> Am 05.07.2015 um 00:50 schrieb Andrea Faulds <a...@ajf.me>: >> >> Hey Sherif, >> >>> On 4 Jul 2015, at 21:56, Sherif Ramadan <theanomaly...@gmail.com> wrote: >>> >>> 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. >> >> >> Yeah, keeping it around makes sense. >> >> Thing is, if it’s a problem, you can silence it with @, so @($a / $b). If >> that’s 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. > -- > 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 of NaN or Inf it is trivial to write a function for that purpose. Perhaps PHP could provide such a function. Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
