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.
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 justreturn $a->someMethod() - $b->someMethod();(where someMethod() returns
float) orreturn $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 isreturn 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.
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
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 justreturn $a->someMethod() - $b->someMethod();(where someMethod() returns
float) orreturn $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 isreturn 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.Hi,
try this:
<?php
$retval = 1.0 - 0.7 - 0.3;
var_dump($retval < 0 ? 'lt' : $retval > 0 ? 'gt' : 'equal'); // result
is not equalcryptocompress
Yes, I understand the pitfalls of floating point number arithmetics. But
isn't it userland's problem?
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 justreturn $a->someMethod() - $b->someMethod();(where someMethod() returns
float) orreturn $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 isreturn 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.Hi,
try this:
<?php
$retval = 1.0 - 0.7 - 0.3;
var_dump($retval < 0 ? 'lt' : $retval > 0 ? 'gt' : 'equal'); //
result is not equalcryptocompress
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 :)
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 justreturn $a->someMethod() - $b->someMethod();(where someMethod() returns
float) orreturn $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 isreturn 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.Hi,
try this:
<?php
$retval = 1.0 - 0.7 - 0.3;
var_dump($retval < 0 ? 'lt' : $retval > 0 ? 'gt' : 'equal'); // result
is not equalcryptocompress
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?