Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52517
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type:content-transfer-encoding;
        b=jBocyl/5aYYs2cWEcIM5hcuQwWx8lwuxEmUTyCUdUuav+FCCzT0jPchVaFiaDOzGqD
         3FyqX8s4dcnjV6NyAFHUt4uvKZ9sWSAi+0IuteAm1cIrDKVtwnplfILa80rqnfBtgtF0
         3ycIb84vI7gctA+NxFW6MD94EcZGJp3JLogdI=
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <BANLkTin2t5byLvf60_jfwd7dTfkG+RJATA@mail.gmail.com>
References: <BA175FCA-75BB-43E6-BE2A-03D1997F6C15@roshambo.org>
 <2EFE9027-13EA-4570-B6D2-2C56D85C7DAE@macvicar.net> <BANLkTin2t5byLvf60_jfwd7dTfkG+RJATA@mail.gmail.com>
Date: Fri, 27 May 2011 10:27:02 +0100
Message-ID: <BANLkTikD-Mq_OcWs++zq+Lf+T=Q25KeihQ@mail.gmail.com>
To: Ferenc Kovacs <info@tyrael.hu>
Cc: Scott MacVicar <scott@macvicar.net>, Philip Olson <philip@roshambo.org>, 
	PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] INF behavior
From: rquadling@gmail.com (Richard Quadling)

On 27 May 2011 08:17, Ferenc Kovacs <info@tyrael.hu> wrote:
> On Fri, May 27, 2011 at 6:10 AM, Scott MacVicar <scott@macvicar.net> wrot=
e:
>
>> On 26 May 2011, at 20:03, Philip Olson <philip@roshambo.org> wrote:
>>
>> > Hello geeks,
>> >
>> > A geek is needed to clarify PHP bug #45712. This is an edge case but t=
he
>> test (bug45712.phpt) contains code similar to the following:
>> >
>> > <?php
>> > $inf =3D pow(0, -2);
>> >
>> > var_dump($inf); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// float(INF)
>> > var_dump($inf =3D=3D =C2=A0$inf); // bool(false)
>> > var_dump($inf =3D=3D=3D $inf); // bool(true)
>> > ?>
>> >
>> > That's how it's behaved since ~forever (AFAICT) and remains in 5.3.7-d=
ev,
>> 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 =3D=3D and =3D=3D=3D produce different results=
.
>>
>> Though if someone has a better understanding of maths then we can fix it=
.
>>
>> S
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> https://twitter.com/#!/SaraMG/status/73903500198821888
> @PhilipOlson If anything it should be: inf=3D=3Dinf, but inf !=3D=3D 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=3D=3Dnull && null=3D=3D=3Dnull, why can't $inf=3D=3D$inf && $inf=3D=
=3D=3D$inf

php -r "var_dump(PHP_VERSION, NF, INF=3D=3DINF, INF=3D=3D=3DINF, NULL,
NULL=3D=3DNULL, NULL=3D=3D=3DNULL);"
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=3D=3DINF and INF=3D=3D=
=3DINF,
just as NULL=3D=3DNULL and NULL=3D=3D=3DNULL

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 =3D=3D=3D should return true.

I think 5.4.0-dev has it right. As long as -INF !=3D INF && -INF !=3D=3D IN=
F
(which I'm sure is right).



Of course, if you come from SQL, any comparison to NULL always fails.
Even to other NULLs.



--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea