Re: usort callback should always return integer (not float)

On Mon, 31 Mar 2014 15:09:33 +0400, Crypto Compress <cryptocompress@googlemail.com> wrote:

Am 31.03.2014 13:02, schrieb Nikita Nefedov:

On Mon, 31 Mar 2014 14:54:50 +0400, Crypto Compress <cryptocompress@googlemail.com> wrote:

Am 31.03.2014 11:00, schrieb Nikita Nefedov:

Hi, I've just stumbled upon this limitation in sorting (compare) callbacks. Is there any reason why we can't handle floats in this case? I think it would be nice to be able to return float from the callback because it's often happens that all it does is just `return $a->someMethod() - $b->someMethod();` (where someMethod() returns float) or `return $a["something"] - $b["something"];` and to make it work I need to write additional if statement. I think the reasoning could be complex behavior of doubles? Especially comparing doubles. But will we see any double-related pitfalls when all our code does with it is `return retval < 0 ? -1 : retval > 0 ? 1 : 0;` (so essentially - compares them to zero)? I made a PR [1] on github for 5.6 version. I think this change is pretty small and could go into 5.6 not breaking our release process rules? Though it WILL introduce some BC breaks for userland code that uses floats. But this code was already broken when it was relying on old behavior. [1] https://github.com/php/php-src/pull/638

Hi, try this: <?php $retval = 1.0 - 0.7 - 0.3; var_dump($retval < 0 ? 'lt' : $retval > 0 ? 'gt' : 'equal'); // result is *not* equal cryptocompress

Yes, I understand the pitfalls of floating point number arithmetics. But isn't it userland's problem?

Don't get your point. This is a very simple example you can try and add a test for. Have fun :)

I mean this is a userland code. Developer should know how float numbers are represented and how they work, shouldn't he?