Re: '9223372036854775807' == '9223372036854775808'

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