Hi!
> 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 for edge cases like one mentioned in the subject, I think it may
make sense to make an exception, since it indeed is kind of obscure why
it works this way and I do not see why this behavior - while having its
(obscure) reasons - would be useful to anybody.
> 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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
