Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59909
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Stas Malyshev" <smalyshev@sugarcrm.com>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
References: <CAPv8svUUPqiNORr+6D9LYeMqRn=3AJywQ0AibdnGesOQCSxZMA@mail.gmail.com> <CAEZPtU5Eyhu6Pkj76L3RYMkNLEJ1sFeftVruBMtbbg6K7HrarQ@mail.gmail.com> <op.wco98yb3idpuyk@slws007.slhq.int> <4F884FB4.70901@sugarcrm.com>
Date: Fri, 13 Apr 2012 21:59:54 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.wcpy54iridpuyk@damnation.mshome.net>
In-Reply-To: <4F884FB4.70901@sugarcrm.com>
User-Agent: Opera Mail/11.62 (Win32)
Subject: Re: [PHP-DEV] '9223372036854775807' == '9223372036854775808'
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Fri, 13 Apr 2012 18:09:24 +0200, Stas Malyshev <smalyshev@sugarcrm.com>  
wrote:

>> There are other situations where the result of the comparison may be
>> "inaccurate" -- in the sense that two strings may be constructed as
>> representing different numbers, but they compare equal.
>>
>> * Comparing two different real numbers that map to the same double
>> precision number:
>> var_dump("1.9999999999999999" == "2"); //true
>
> For floats, there's no accurate comparison anyway, it is a known fact.

However, you are not comparing floats, you're comparing strings. As I  
showed, floats in strings are already treated differently depending on  
whether they're in string form or not (1e400 == 1e400 vs "1e400" ==  
"1e400"). What's under discussion is once again whether to treat  
distinctly a proper integer from a integer in string form.

> [...]
>> However, taking the last case an example, this is the same that happens  
>> if
>> you compare:
>> var_dump((int)"9223372036854775807" == (double)"9223372036854775808");
>> //true
>
> This, however is a different case since you explicitly coerce the types
> and you must know that both conversions are lossy. It's like doing
> substr($a, 0, 1) == substr($b, 0, 1) - of course it can return true even
> if $a and $b different. When you convert bigger type (string) to smaller
> type (int) you must accept the potential loss or check for it if it's
> important.
> However I think it would make sense not to use this conversion in string
> comparisons when we know it's lossy - it seems to be outside of the use
> case for such comparisons and it seems apparent by now that it is hard
> for people to understand why it works this way.

First, I don't think this discussion gets any clearer by using ambiguous  
terms such as "lossy" and saying "lossy is bad". Is (int) " 02" a lossy  
conversion -- you lose the space and 0? What about even (float) "1" -- 1.  
is mapped from a infinite number of real numbers due to rounding error and  
you have no way to know which one was the original? And in case, I don't  
think you mean that (int)"9223372036854775807" is a lossy conversion as it  
results in 9223372036854775807 (depending on the width of long, of course).
(by the way, these are rhetorical questions, I don't care about  
establishing a definition of "lossy" in this thread)

In any case, your selective quoting destroyed the main point of my e-mail  
-- that is, this problem implicates these questions: is  
"9223372036854775808" different from 9223372036854775808? Is  
"9223372036854775808" still deemed to represent an integer, even though we  
cannot represent it as an integer type?

I think most people can agree that this behavior is correct:

var_dump(9223372036854775807 == 9223372036854775808); //true

therefore, we need some -- principled -- distinction to treat case  
"9223372036854775807" == "9223372036854775808" differently. The  
distinction I propose is answering "yes" to the questions above -- they  
represent different entities and when no conversion of the integer string  
to the integer type can't be done we should fall back to memcmp(). This is  
what is already done with the overflowing "1e400". I don't find it  
particularly convincing, though.

-- 
Gustavo Lopes