INF behavior - Externals

13 years ago by Philip Olson — view source

unread

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

Regards,
Philip

13 years ago by Scott MacVicar — view source

unread

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix it.

13 years ago by Ferenc Kovacs — view source

unread

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the
test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev,
but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix it.

S

https://twitter.com/#!/SaraMG/status/73903500198821888
@PhilipOlson If anything it should be: inf==inf, but inf !== inf. After all,
not all infinities are the same, but they are all infinite.

and I agree with Sara on this one.

Tyrael

13 years ago by Richard Quadling — view source

unread

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the
test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev,
but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix it.

S

https://twitter.com/#!/SaraMG/status/73903500198821888
@PhilipOlson If anything it should be: inf==inf, but inf !== inf. After all,
not all infinities are the same, but they are all infinite.

and I agree with Sara on this one.

Tyrael

I wonder if INF is really any different to NULL.

If null==null && null===null, why can't $inf==$inf && $inf===$inf

php -r "var_dump(PHP_VERSION, NF, INF==INF, INF===INF, NULL,
NULL==NULL, NULL===NULL);"
string(9) "5.3.7-dev"
float(INF)
bool(false)
bool(true)
NULL
bool(true)
bool(true)

I think of NULL and INF as states (no value assigned vs the ultimate
value assigned). You can't really determine the value only the nature
of the value. And the nature of INF is INF, so INF==INF and INF===INF,
just as NULL==NULL and NULL===NULL

So, when you compare them, you can't compare the value (in the
traditional sense), just the states and the states are the same both,
so === should return true.

I think 5.4.0-dev has it right. As long as -INF != INF && -INF !== INF
(which I'm sure is right).

Of course, if you come from SQL, any comparison to NULL always fails.
Even to other NULLs.

--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

13 years ago by Derick Rethans — view source

unread

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix it.

I think it does make sense. == is the equal operator, and INF is not
equal to INF (just like SQL NULL is not equal to NULL). However, they
are identical (like you can test in SQL with NULL IS NULL).

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

13 years ago by Julien Pauli — view source

unread

Agree with Derick, strictly speaking, in maths science, INF != INF.

But I dont care if PHP tells me than yes, because PHP is not designed
to solve high level maths problems :)

Cheer,

Julien.Pauli

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix it.

I think it does make sense. == is the equal operator, and INF is not
equal to INF (just like SQL NULL is not equal to NULL). However, they
are identical (like you can test in SQL with NULL IS NULL).

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

13 years ago by Hannes Landeholm — view source

unread

Agree with Derick, strictly speaking, in maths science, INF != INF.

I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:

"Since a projective infinity doesn't have a sign, comparing a floating point
value other than infinity to a projective infinity is unordered. However, a
projective infinity is equal to itself."

Hannes

Agree with Derick, strictly speaking, in maths science, INF != INF.

But I dont care if PHP tells me than yes, because PHP is not designed
to solve high level maths problems :)

Cheer,

Julien.Pauli

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but
the test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in
5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be
documented/explained?

I think I changes this :-)

It didn't make sense that == and === produce different results.

Though if someone has a better understanding of maths then we can fix
it.

I think it does make sense. == is the equal operator, and INF is not
equal to INF (just like SQL NULL is not equal to NULL). However, they
are identical (like you can test in SQL with NULL IS NULL).

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

13 years ago by Gustavo Lopes — view source

unread

On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm landeholm@gmail.com
wrote:

Agree with Derick, strictly speaking, in maths science, INF != INF.

I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:

"Since a projective infinity doesn't have a sign, comparing a floating
point value other than infinity to a projective infinity is unordered.
However, a projective infinity is equal to itself."

Yes, as I argued, for purposes of IEEE 754, it's certainly the case that
INF = INF.

This may not be true for certain meanings of "infinity" or notions of
ordering, but we have a standard for floating point arithmetic with
well-defined terms and rules which we ought to follow.

As a curiosity, Mathematica defines the result of Equal[Infinity,
Infinity] and Equal[Overflow, Overflow], but not for ComplexInfinity or
Indeterminate (similar to NaN):

In[1]:= ComplexInfinity == ComplexInfinity
Out[1]= ComplexInfinity == ComplexInfinity
In[2]:= Infinity == Infinity
Out[2]= True
In[3]:= Overflow == Overflow
Out[3]= True
In[4]:= Indeterminate == Indeterminate
Out[4]= Indeterminate == Indeterminate

--
Gustavo Lopes

13 years ago by Tjerk Anne Meesters — view source

unread

On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm landeholm@gmail.com
wrote:

Agree with Derick, strictly speaking, in maths science, INF != INF.

I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:

"Since a projective infinity doesn't have a sign, comparing a floating
point value other than infinity to a projective infinity is unordered.
However, a projective infinity is equal to itself."

Yes, as I argued, for purposes of IEEE 754, it's certainly the case that INF
= INF.

This may not be true for certain meanings of "infinity" or notions of
ordering, but we have a standard for floating point arithmetic with
well-defined terms and rules which we ought to follow.

As a curiosity, Mathematica defines the result of Equal[Infinity, Infinity]
and Equal[Overflow, Overflow], but not for ComplexInfinity or Indeterminate
(similar to NaN):

In[1]:= ComplexInfinity == ComplexInfinity
Out[1]= ComplexInfinity == ComplexInfinity
In[2]:= Infinity == Infinity
Out[2]= True
In[3]:= Overflow == Overflow
Out[3]= True
In[4]:= Indeterminate == Indeterminate
Out[4]= Indeterminate == Indeterminate

That, and the fact that "a != b" should always imply "a !== b" imo.
And if you must compare with SQL it would be something more akin to
"is_infinite(a)"

--
Gustavo Lopes

--

--

Tjerk

13 years ago by Gustavo Lopes — view source

unread

Em Fri, 27 May 2011 04:03:01 +0100, Philip Olson philip@roshambo.org
escreveu:

Hello geeks,

A geek is needed to clarify PHP bug #45712. This is an edge case but the
test (bug45712.phpt) contains code similar to the following:

<?php
$inf = pow(0, -2);

var_dump($inf); // float(INF)
var_dump($inf == $inf); // bool(false)
var_dump($inf === $inf); // bool(true)
?>

That's how it's behaved since ~forever (AFAICT) and remains in
5.3.7-dev, but PHP 5.4.0-dev changes behavior so both now return true.

Is this is how we want it? And how should this be documented/explained?

What IEEE Std 754-2008 says is this:

«5.11 Details of comparison predicates

5.11.0
For every supported arithmetic format, it shall be possible to compare one
floating-point datum to another
in that format (see 5.6.1). Additionally, floating-point data
represented in different formats shall be
comparable as long as the operands’ formats have the same radix.

Four mutually exclusive relations are possible: less than, equal, greater
than, and unordered. The last case
arises when at least one operand is NaN. Every NaN shall compare unordered
with everything, including
itself. Comparisons shall ignore the sign of zero (so +0 = −0). Infinite
operands of the same sign shall
compare equal.

Languages define how the result of a comparison shall be delivered, in one
of two ways: either as a relation
identifying one of the four relations listed above, or as a true-false
response to a predicate that names the
specific comparison desired.

Table 5.1, Table 5.2, and Table 5.3 exhibit twenty-two functionally
distinct useful predicates and negations
with various ad-hoc and traditional names and symbols. Each predicate is
true if any of its indicated
relations is true. The relation “?” indicates an unordered relation. (...)

(...)

Table 5.1 - Required unordered-quiet predicate and negation

Unordered quiet predicate | Unordered-quiet Negation
-----------------------------------|---------------------------------------
True Relations | Names | True Relations | Names
---------------|-------------------|---------------------------------------
EQ | compareQuietEqual | LT GT UN | compareQuietNotEqual
| = | | ?<>, NOT(=), ≠

Given this, I think the behavior of 5.4 is correct because "[i]nfinite
operands of the same sign shall compare equal" and compareQuietEqual maps
EQ to true. 5.4 still gives false for NAN==NAN, which is also correct.

This is also what this C99 program gives:

#include<stdio.h>
#include<math.h>
void main() {
printf("%d %d\n", INFINITY == INFINITY, NAN == NAN);
}

./a.out
1 0

--
Gustavo Lopes

13 years ago by Philip Olson — view source

unread

Hello everyone,

There are differing opinions on this matter so I'll base a conclusion on current SVN:

Both (INF==INF and INF===INF) are true in PHP 5_4 because it's the correct behavior
PHP 5_3 will continue as is for BC reasons (INF==INF = false, INF===INF = true)

So unless something changes then this is how INF will be documented. And please inform the documentation team if this changes. ;)

Regards,
Philip

13 years ago by Hannes Magnusson — view source

unread

Hello everyone,

There are differing opinions on this matter so I'll base a conclusion on current SVN:

Both (INF==INF and INF===INF) are true in PHP 5_4 because it's the correct behavior

PHP 5_3 will continue as is for BC reasons (INF==INF = false, INF===INF = true)

So unless something changes then this is how INF will be documented. And please inform the documentation team if this changes. ;)

Did this change again or is the test for it still broken?

ext/standard/tests/math/bug45712.phpt is still marked as "XFAIL" with
the remark of the bug not being fixed.

-Hannes