Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 20 Feb 2013 10:44:11 +0100
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP Internals <internals@lists.php.net>
Organization: =?UTF-8?Q?N=C3=BAcleo_de_Engenharia_Biom=C3=A9dica_do_Insti?=
 =?UTF-8?Q?tuto_Superior_T=C3=A9cnico?=
In-Reply-To: <51248616.907@sugarcrm.com>
References: <511666DE.8080809@fedoraproject.org>
 <51172819.4000806@sugarcrm.com> <51174790.8040805@fedoraproject.org>
 <511751C5.1020906@fedoraproject.org> <51175BDD.9040705@sugarcrm.com>
 <op.wsad6bs3idpuyk@damnation.nl.lo.geleia.net>
 <op.wsao7qs7idpuyk@damnation.nl.lo.geleia.net>
 <5117BA92.8080307@fedoraproject.org>
 <op.wsa1omtoidpuyk@damnation.nl.lo.geleia.net>
 <511890AC.7080506@fedoraproject.org> <51189847.5030506@sugarcrm.com>
 <op.wsobyaxwidpuyk@damnation.nl.lo.geleia.net>
 <5122DE69.3080901@sugarcrm.com>
 <op.wsr1y3q7idpuyk@damnation.nl.lo.geleia.net> <51248616.907@sugarcrm.com>
Message-ID: <8bb50302d7ff520ca862d112ee005f3a@nebm.ist.utl.pt>
User-Agent: RoundCube Webmail/0.8-rc
Subject: Re: [PHP-DEV] double val to long val conversion issue
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

Em 2013-02-20 9:15, Stas Malyshev escreveu:
> Hi!
>
>>> Also, I'm not sure I understand what 64-bit test is supposed to 
>>> return
>>> and why - why negative number is converted to positive one? What 
>>> exactly
>>> this change is supposed to improve?
>>
>> The least significant bytes are preserved. Take int(-2056257536) and
>> int(2943463994971652096):
>>
>> In[6]:= BitAnd[2^32 - 1, {-2056257536, 2943463994971652096}]
>>
>> Out[6]= {2238709760, 2238709760}
>
> I'm not sure I understand, what this syntax means and how it explains
> why we're doing these conversions?

It doesn't, of course. I was just showing why there are changes in 
sign.

> I.e. what requires this change and
> how it is beneficial? I understand that it preserves least 
> significant
> bits, but why we should preserve them and discard sign, for example?

First of all, there are no change for the ]LONG_MAX, ULONG_MAX] range. 
Doubles in that range (notice they're positive numbers) already got 
converted to negative numbers.

The problem was that for numbers outside the [LONG_MIN, ULONG_MAX] 
range, the code relied on undefined behavior that did vary between 
platforms. This change does away with the undefined behavior and 
provides a uniform treatment of the finite double domain. (int)$dval is 
now round*($dval) mod 2^(PHP_INT_SIZE*8) converted to a signed integer 
of size PHP_INT_SIZE*8 bits assuming a two's complement representation, 
for all finite $dval double values.

You could argue that another behavior like clipping at 
LONG_MAX/LONG_MIN is preferable. But we can't do it for BC reasons. And 
especially for 32-bit long systems, the current behavior is very useful. 
For instance let's say you had some network protocol that used an 
unsigned 32-bit int on which you needed to do some bitwise operations. 
You can use a double to represent the range 2^31..2^32-1 that you got 
from, from instance, adding two large PHP integers, cast it to int and 
do your bitwise operation.

* Actually, I just realized the code probably needs a small adjustment 
to make the double always round towards zero. This is only important in 
32-bit systems though; for the others, the doubles outside the long 
range have no fractional part.

-- 
Gustavo Lopes