Edit report at https://bugs.php.net/bug.php?id=34179&edit=1
ID: 34179
Updated by: cmb@php.net
Reported by: pww8 at cornell dot edu
Summary: want 1.0/0.0 == INF as an option
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package: *General Issues
Operating System: *
PHP Version: *
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
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>.
Previous Comments:
------------------------------------------------------------------------
[2005-09-07 23:15:45] pww8 at cornell dot edu
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.
------------------------------------------------------------------------
[2005-09-04 23:52:36] yaXay at gmx dot net
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
------------------------------------------------------------------------
[2005-08-18 00:44:16] pww8 at cornell dot edu
Description:
------------
It appears floating-point infinity (INF) is not returned from divide by zero (in PHP 5.0.0).
Instead a warning is given and Boolean FALSE is returned.
This is no doubt well-known behavior to most users, probably would be confusing to change the
default. But it would be useful for me to throw a switch or set an .ini file variable to some
non-default state, and get the correct answer instead of FALSE.
Note that you can get INF from multiply, e.g. 1.0e300*1.0e300 [Linux on Intel]. Might also be nice
to get INF when it is the correct answer!
Reproduce code:
---------------
// Expected result would be after I set some non-default
// floating point handling mode above...
$varxx = 1.0 / 0.0;
$if (isset($varxx))
{ boolean = is_bool($varxx) ? "Boolean" : "Not Boolean" ;
print "\nSET $varxx $boolean";
}
else
{ print "\nNOT SET"; }
print "\nanother test, exp of very large number is : " . exp(1.0e300);
print "\ntry for infinity using * : " . 1.0e300*1.0e300;
Expected result:
----------------
SET INF Not Boolean
another test, exp of very large number is : INF
try for infinity using * : INF
Actual result:
--------------
SET Boolean
another test, exp of very large number is : INF
try for infinity using * : INF
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=34179&edit=1