Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74235
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain marc-bennewitz.de does not designate 80.237.132.171 as permitted sender)
Message-ID: <53751109.5080503@marc-bennewitz.de>
Date: Thu, 15 May 2014 21:10:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Chris Wright <daverandom@php.net>
CC: PHP Internals <internals@lists.php.net>
References: <534A8121.6090205@marc-bennewitz.de>	<CAGAGxbaY8j+ngSGDpPQiGLXKroiQ0RnLhRTwrprMHL4dFu7X5g@mail.gmail.com>	<534C2E6B.5020400@marc-bennewitz.de>	<CAGAGxbaix3befM0xPBJgYDkObfY1sYMo-Roap4YfWHXsRL98mg@mail.gmail.com>	<534F99A1.4070904@marc-bennewitz.de> <CAGAGxbbTnb5QQhvvH5bchRG9mYFOEocinj_CHGe-L12zwEVz+A@mail.gmail.com>
In-Reply-To: <CAGAGxbbTnb5QQhvvH5bchRG9mYFOEocinj_CHGe-L12zwEVz+A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Shifting bits of a binary string
From: php@marc-bennewitz.de (Marc Bennewitz)

sorry for the late response.

On 17.04.2014 11:22, Chris Wright wrote:
> On 17 April 2014 10:06, Marc Bennewitz <php@marc-bennewitz.de> wrote:
>>
>>
>> On 15.04.2014 02:04, Chris Wright wrote:
>>>
>>> On 14 April 2014 19:52, Marc Bennewitz <php@marc-bennewitz.de> wrote:
>>>>
>>>> - Bit shift left on strings:
>>>>     - act byte-by-byte in a O(n) manner
>>>>     - shifting out left bit(s)
>>>>     - append NULL bits to the right
>>>>     - preserve string length
>>>>
>>>> - Bit shift right on strings:
>>>>     - act byte-by-byte in a O(n) manner
>>>>     - shifting out right bit(s)
>>>>     - prepend NULL bits to the left (don't preserve the first bit)
>>>>     - preserve string length
>>>
>>>
>>> Agreed.
>>>
>>>> - Bit shifting on other types:
>>>>     - error/warning
>>>
>>>
>>> Probably agreed.
>>>
>>>> - If the number of bits to shift isn't an integer, than:
>>>>     - error
>>>
>>>
>>> Floats would also need to be permitted here, albeit converted to
>>> integers for the purposes of performing the operation.
>>
>> Ho do you handle values like 3.5? Is it an error if fractions exists?
>
> This would be handled as it is currently, with a standard integer
> conversion, i.e. rounded towards zero. It doesn't make sense to check
> for fractions and error out IMO, as floating point precision errors
> would likely cause someone somewhere some unexpected behaviour. In the
> case of float(3.5) it's obvious this isn't "correct", but in the case
> of float(3.005) the user probably did some calculation that they
> expected to result in int(3), so emitting an error would be
> unexpected. While a margin of error threshold could be defined, it's
> an extra branch and a somewhat arbitrary limitation.

After thinking more about on operating bit operations a developer have 
to know about how data are represented in bits. That means the datatype 
to run bit operations on should never be converted automatically only an 
error/warning should be generated if it's not possible to run bit 
operations on it (like objects).

That also means first bit should not be preserved as it was implemented 
to preserve signs of numbers.

And more ... bit shifting of floating point numbers should simply be 
done. Because it makes little sense to do that an error could be 
discussable but in some special cases it could make good sense. (This 
would require to define data structure of floating point numbers 
"double" to be the same 100% on all systems)

Greetings
Marc