Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73491
Return-Path: <inefedor@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 71020 invoked from network); 31 Mar 2014 12:16:18 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 31 Mar 2014 12:16:18 -0000
Authentication-Results: pb1.pair.com header.from=inefedor@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=inefedor@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
X-PHP-List-Original-Sender: inefedor@gmail.com
X-Host-Fingerprint: 209.85.215.44 mail-la0-f44.google.com  
Received: from [209.85.215.44] ([209.85.215.44:49036] helo=mail-la0-f44.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id A6/B3-44499-09C59335 for <internals@lists.php.net>; Mon, 31 Mar 2014 07:16:17 -0500
Received: by mail-la0-f44.google.com with SMTP id hr13so5695024lab.17
        for <internals@lists.php.net>; Mon, 31 Mar 2014 05:16:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=content-type:to:cc:subject:references:date:mime-version
         :content-transfer-encoding:from:message-id:in-reply-to:user-agent;
        bh=B+S7VG8gwX79ZS9PXeHJAxLs+lfeYdgZ7u8kkTMY4hg=;
        b=IFbvS/aR3sNCjc7F5DWSWOoFdTJtXaK/6i+ptzz2gnopIHiR1Vgs3qLGNDgmcAf8qf
         3ZprRUXt7XXsROvdo6hbWeSHDwkasL/m6a3O/YQVeX+CnqKwAkR7v51V3fzCTqUZ/wdN
         leR3k0NjXbuIvc0giBT480hzlxpuRX6uVwEfBuASwFNV7lORaD1BCiZEXN4Cn2Xgf4Vb
         LwQ8Mu3vCZ8jzM3wR6x2rGDB4xzOqZuvvI9sZ2S0jFnZ4GaT47/FBmr49X/dvHEchfCZ
         wL71HL8iZnyWk+jbLgnJbg9M5Wd2w15Ht2akaseR8bX4LZtk6m8Kx16r2j0Irax914iX
         8Ebw==
X-Received: by 10.112.6.98 with SMTP id z2mr111003lbz.84.1396268173687;
        Mon, 31 Mar 2014 05:16:13 -0700 (PDT)
Received: from nikita-pc (93-80-62-168.broadband.corbina.ru. [93.80.62.168])
        by mx.google.com with ESMTPSA id md15sm9815266lbb.28.2014.03.31.05.16.12
        for <multiple recipients>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Mon, 31 Mar 2014 05:16:12 -0700 (PDT)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: "Crypto Compress" <cryptocompress@googlemail.com>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
References: <op.xdkwnbfdc9evq2@nikita-pc> <5339497A.2040506@googlemail.com>
 <op.xdk2abhec9evq2@nikita-pc> <53394CED.8040502@googlemail.com>
Date: Mon, 31 Mar 2014 16:16:11 +0400
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.xdk5o9pyc9evq2@nikita-pc>
In-Reply-To: <53394CED.8040502@googlemail.com>
User-Agent: Opera Mail/12.16 (Win32)
Subject: Re: [PHP-DEV] usort callback should always return integer (not float)
From: inefedor@gmail.com ("Nikita Nefedov")

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?