Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73489
Return-Path: <cryptocompress@googlemail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 65400 invoked from network); 31 Mar 2014 11:09:49 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 31 Mar 2014 11:09:49 -0000
Authentication-Results: pb1.pair.com smtp.mail=cryptocompress@googlemail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=cryptocompress@googlemail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.49 as permitted sender)
X-PHP-List-Original-Sender: cryptocompress@googlemail.com
X-Host-Fingerprint: 209.85.214.49 mail-bk0-f49.google.com  
Received: from [209.85.214.49] ([209.85.214.49:54596] helo=mail-bk0-f49.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 17/E2-44499-CFC49335 for <internals@lists.php.net>; Mon, 31 Mar 2014 06:09:49 -0500
Received: by mail-bk0-f49.google.com with SMTP id my13so1155862bkb.36
        for <internals@lists.php.net>; Mon, 31 Mar 2014 04:09:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=wu7YV5uj4WhD4e9aZb4Tzm9GV7QX8ZsYz015uGITW/Y=;
        b=q/Ud5Da8M1SaxzJUECAKKRsjnonaiKqdsV/TyS26jFlcQMNbRVT65HTAuyhyy5Pp1e
         MS+eofY9qLpSw5lbis4NCQqtTLzDF/tPBnwzBWDl6aoiCdMkkMrKLDDE5nqAg/WHXIPl
         eO/MUBM8cuS5VO7kbCD9AiqbUqts+Hn77ebjTJeq9A+eZb5RWmq0456OKUVC46pHJzbr
         gl1knYRuPJgnj3IEMUgtUBERsSCK9KFlQOL+CoCAI+Jui9KNPn/EJ/4KLOckq5AsF7+b
         lac6yEWID1QdWJJAqNeefs9tlpHVGRabp1VhzwkVuQShdAX6j6qQUE67nlxpkg4O2vDA
         5auQ==
X-Received: by 10.205.47.193 with SMTP id ut1mr21161bkb.168.1396264185464;
        Mon, 31 Mar 2014 04:09:45 -0700 (PDT)
Received: from [192.168.1.115] (mnch-5d8769de.pool.mediaWays.net. [93.135.105.222])
        by mx.google.com with ESMTPSA id el11sm13311417bkb.8.2014.03.31.04.09.43
        for <multiple recipients>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Mon, 31 Mar 2014 04:09:44 -0700 (PDT)
Message-ID: <53394CED.8040502@googlemail.com>
Date: Mon, 31 Mar 2014 13:09:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Nikita Nefedov <inefedor@gmail.com>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <op.xdkwnbfdc9evq2@nikita-pc> <5339497A.2040506@googlemail.com> <op.xdk2abhec9evq2@nikita-pc>
In-Reply-To: <op.xdk2abhec9evq2@nikita-pc>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] usort callback should always return integer (not float)
From: cryptocompress@googlemail.com (Crypto Compress)

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 :)