As far as I know 1/0 is undefined (lim x->0 (1/x) is inf.), as well as 1.0e300*1.0e300 simply produces an overflow. Of course that is just a technicality, but still..

Regarding devide by zero and overflows, I would go even further and throw an exception, because that is what they are: exceptions. Nobody divides by zero or generates overflows on purpose. They usually occur on erroneous user input. Throwing exceptions would of course force the programmer to be more aware of this issue, since exceptions have a habit of stopping execution when they are not caught. Howerver I find it good to force the programmer to produce clean code, I mean, what is the downside??

Sincerely,
Benjamin Schulz

Various math operations can correctly generate +Inf or -Inf or NaN (Not a Number).

Seems to me 3 reasonable things to do with those results:

  1. Issue warning and return default result, as now done on 1.0/0.0;

  2. Raise an exception;

  3. Return the correct result, where possible, as a native float.  That is, NaN or Inf in 32 or 64 bits, which is possible on all current machines I know of (a small set).

I would prefer option 3.

Note that PHP now uses option 3 in many operations, including multiply [operator *], log10(), exp().

I don't agree that "no one divides by 0 or generates overflow on purpose".  As a contrived example, you may have a set of X-Y points where Y = f(X), some values of Y are Inf and some are not.  The user looks at a graph, with infinities marked, and understands.  User then applies another function Z = ff(Y) and expects the infinities to participate.  For example:


rad2deg(atan(Inf))  =>  90
 
  which can be seen in PHP by:

rad2deg(atan(exp(1.0e200)));


Furthermore, there are many cases where the user did not intend to create an Inf, but would still prefer that the Inf's be created and displayed instead of the whole calculation being tossed.  The example again could be graphing a lot of X-Y data where a few Inf or NaN will be understoo dby the user, and the remaining in-range data is useful and should be displayed.

Actually, 1.0/0.0 should be +Inf, 0.0/0.0 should be NaN.

I guess raising an exception might be better than issuing the warning, but the amount of extra code I would have to write to generate the Inf or NaN would be the same as the present implementation.  And, just adding the exception for divide by zero is inconsistent with the present * , log10(), exp(), etc...

I also think it's impolite to change existing behavior of divide by zero.

Ideally I see a programmer-settable choice, maybe at runtime, maybe only on startup, among 3 options:

 1. present behavior (sometimes warn, sometimes produce Inf or Nan);

 2. raise exception on any out of range result;

 3. generate correct out of range floating point bit pattern on all out-of-range results, unless the present hardware does not support it (see standard IEEE 754).

So if the programmer tries to set option 3 at runtime, and present hardware does not support it, an error should be returned from the option setter function.

One possible problem with my proposal: if some existing builtin function [say acosh()] is internally generating Inf's, and sucessfully using them to generate in-range values, option 2 would have to be implemented so those internal Inf's did not raise an exception.

My proposal is based on my former job writing a graphing calculator subsystem for engineers, using Smalltalk.  Not based on a current project need.  And, from years of discussion with Smalltalk programmers and vendors, I realize not all programmers know IEEE 754.

This issue will be adressed in PHP 7.0.0, see <https://github.com/php/php-src/blob/8cd62071abc3defd8d5f9a2dc3a788d8692af3c0/NEWS#L21-L24> and <http://3v4l.org/HfTug>.