Prev: Dear Lazy Web: Pseudo Randomisation Strategies onListing Websites
Next: add function to solr extension
From: Richard Quadling on 25 Aug 2010 07:27
On 24 August 2010 21:42, Andy McKenzie <amckenzie4(a)gmail.com> wrote:
> On Tue, Aug 24, 2010 at 3:55 PM, Ford, Mike <M.Ford(a)leedsmet.ac.uk> wrote:
>>> -----Original Message-----
>>> From: Andy McKenzie [mailto:amckenzie4(a)gmail.com]
>>> Sent: 24 August 2010 17:24
>>> To: php-general(a)lists.php.net
>>> Subject: Re: [PHP] Bitwise NOT operator?
>>
>>
>>> From your example, this would have shown me what I needed to know:
>>>
>>> "Then taking the value of E_NOTICE...
>>> 1000
>>> ... and inverting it via ~:
>>> 11111111111111111111111111110111"
>>>
>>> As it was, I assumed the 32-bit number was there because the author
>>> wanted it there, not because PHP assumes those extra bits.
>>
>> That's not PHP. That's the underlying computer architecture, and PHP has no choice in the matter. (Well, assuming you leave BCMath and so on out of the equation!)
>>
>> Cheers!
>>
>> Mike
>
>
> True, but largely irrelevant from my point of view:  I'm talking to
> PHP.  Even if I'd thought about it in terms of the architecture, I
> would have assumed that PHP would treat a two-bit number as a two-bit
> number, even if it had to do some weirdness in the background because
> it's not.  If I enter a decimal two, I know the computer deals with it
> as binary, and now I know it probably deals with it as a 32-bit binary
> number, but it doesn't show me all the extra bits:  it just shows me a
> two.
>
> My point here, much as it might sound like it, isn't that PHP is wrong
> for doing things the way it does.  Even if I thought it is, I don't
> know what I'm talking about, and I know it.  What I'm saying is that
> the documentation doesn't even begin to indicate to people like me
> that things won't work the way we expect.  Maybe that's not necessary;
> certainly I've never needed it until now, and the confusion was easily
> cleared up.  But adding to the docs might avoid a lot of confusion for
> the next guy who doesn't really know what he's doing.
>
> -Alex
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


I think trying to explain to someone with no knowledge of the rules is
going to be a little beyond the role of the PHP documentation. A
rudimentary understanding has to be assumed.

You are talking about decimal numbers (2, 3, 4) and then applying the
NOT operator and then expressing the result in base 10 and base 2.

Decimal numbers are column based. By worldwide and historic
convention, leading zeros are not needed. In fact, worldwide
convention has dictated that a leading 0 implies an octal number and
not a decimal one.

Binary numbers are block based. Historic/worldwide convention dictates
bits are either singular (true/false) or in blocks (bytes, words,
double-words, quad-words, etc.) OK. Nibbles/nybbles/nybles too.

You say a "two-bit number". Well, there is no such entity. As soon as
you talk in terms of bits, you are dealing in binary and this is block
based, not column based.

Applying a not operator has the effect of inverting all the bits. We
see that perfectly fine in ...

~00000001 = 11111110

But, when you then express that pattern in decimal, the rules
regarding 2's compliment kick in. -128 to 127 = 256 options. Not -127
to 127 ... what happened to -0?



--
Richard Quadling.
From: Peter Lind on 25 Aug 2010 07:37
Please stop arguing this pointless topic on the php mailing list.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
From: "Bob McConnell" on 25 Aug 2010 08:22
From: Richard Quadling
> On 24 August 2010 21:42, Andy McKenzie <amckenzie4(a)gmail.com> wrote:
>> On Tue, Aug 24, 2010 at 3:55 PM, Ford, Mike <M.Ford(a)leedsmet.ac.uk> wrote:
>>>> From: Andy McKenzie [mailto:amckenzie4(a)gmail.com]
>>>
>>>> From your example, this would have shown me what I needed to know:
>>>>
>>>> "Then taking the value of E_NOTICE...
>>>> 1000
>>>> ... and inverting it via ~:
>>>> 11111111111111111111111111110111"
>>>>
>>>> As it was, I assumed the 32-bit number was there because the author
>>>> wanted it there, not because PHP assumes those extra bits.
>>>
>>> That's not PHP. That's the underlying computer architecture, and
> PHP has no choice in the matter. (Well, assuming you leave BCMath
> and so on out of the equation!)
>>>
>>
>> True, but largely irrelevant from my point of view:  I'm talking to
>> PHP.  Even if I'd thought about it in terms of the architecture, I
>> would have assumed that PHP would treat a two-bit number as a two-bit
>> number, even if it had to do some weirdness in the background because
>> it's not.  If I enter a decimal two, I know the computer deals with it
>> as binary, and now I know it probably deals with it as a 32-bit binary
>> number, but it doesn't show me all the extra bits:  it just shows me a
>> two.
>>
>> My point here, much as it might sound like it, isn't that PHP is wrong
>> for doing things the way it does.  Even if I thought it is, I don't
>> know what I'm talking about, and I know it.  What I'm saying is that
>> the documentation doesn't even begin to indicate to people like me
>> that things won't work the way we expect.  Maybe that's not necessary;
>> certainly I've never needed it until now, and the confusion was easily
>> cleared up.  But adding to the docs might avoid a lot of confusion for
>> the next guy who doesn't really know what he's doing.
>>
> I think trying to explain to someone with no knowledge of the rules is
> going to be a little beyond the role of the PHP documentation. A
> rudimentary understanding has to be assumed.
>
> You are talking about decimal numbers (2, 3, 4) and then applying the
> NOT operator and then expressing the result in base 10 and base 2.
>
> Decimal numbers are column based. By worldwide and historic
> convention, leading zeros are not needed. In fact, worldwide
> convention has dictated that a leading 0 implies an octal number and
> not a decimal one.
>
> Binary numbers are block based. Historic/worldwide convention dictates
> bits are either singular (true/false) or in blocks (bytes, words,
> double-words, quad-words, etc.) OK. Nibbles/nybbles/nybles too.
>
> You say a "two-bit number". Well, there is no such entity. As soon as
> you talk in terms of bits, you are dealing in binary and this is block
> based, not column based.
>
> Applying a not operator has the effect of inverting all the bits. We
> see that perfectly fine in ...
>
> ~00000001 = 11111110
>
> But, when you then express that pattern in decimal, the rules
> regarding 2's compliment kick in. -128 to 127 = 256 options. Not -127
> to 127 ... what happened to -0?

To make it simple, the computer hardware doesn't know or care if you want two bits or 128, so neither can PHP. If you are only interested in the lower bits, you need to mask your answer to throw away the rest. For example, doing a bitwise AND with 3 will discard all but the last two bits, 7 will give you the last three bits, etc.

Bob McConnell
From: Colin Guthrie on 25 Aug 2010 09:46
'Twas brillig, and Andy McKenzie at 24/08/10 21:42 did gyre and gimble:
> Even if I'd thought about it in terms of the architecture, I
> would have assumed that PHP would treat a two-bit number as a two-bit
> number

You two-bit hustler!

In all seriousness tho', where do you ever provide a two bit number?

$n = 2;

The above is a number, it's not implicitly a two bit number...

I mean, if I do:

$n = 2;
$n += 2;

What do I get then? $n == 0? That's what *should* happen if $n was
indeed two bits. It would overflow and wrap around.

Your number in $n is in fact represented by whatever the variable type
is. In this case it's a 32 bit integer number.

Col


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

From: Andy McKenzie on 25 Aug 2010 10:13
On Wed, Aug 25, 2010 at 9:46 AM, Colin Guthrie <gmane(a)colin.guthr.ie> wrote:
> 'Twas brillig, and Andy McKenzie at 24/08/10 21:42 did gyre and gimble:
>> Even if I'd thought about it in terms of the architecture, I
>> would have assumed that PHP would treat a two-bit number as a two-bit
>> number
>
> You two-bit hustler!
>
> In all seriousness tho', where do you ever provide a two bit number?
>
> $n = 2;
>
> The above is a number, it's not implicitly a two bit number...
>
> I mean, if I do:
>
> $n = 2;
> $n += 2;
>
> What do I get then? $n == 0? That's what *should* happen if $n was
> indeed two bits. It would overflow and wrap around.
>
> Your number in $n is in fact represented by whatever the variable type
> is. In this case it's a 32 bit integer number.
>
> Col
>

You're right, of course: internally, PHP has to treat every number as
being some specific number of bits. My point was that, not knowing a
lot about the low-level systems and internals, it's easy to assume
that something I enter as two bits (or three, or four, or whatever)
will be treated as such and returned as such.

My background isn't computer architecture: what little relevant
experience I've had was two years in an electrical engineering program
(I decided it wasn't for me, and got out), but I never looked at
computer system architecture. Based on my background, I tend to think
of a string of bits as just that -- a string of bits, basically
disconnected from anything else. Therefore, if I feed five bits into
a NOT gate, I should get five bits back, and they should be the
opposite of what I fed it. ~(10110) = 01001. What I do with it after
that is up to me. Math is different, and may require adding extra
bits, but a NOT isn't a mathematical function in my mind, it's a
function performed one bit at a time on exactly what you feed it.

As Gary points out, there ARE languages and places where that's doable
-- I've used the bit-field tool he mentioned, I think, although it was
a long time ago in that EE program -- so I had some reason for my
(incorrect) assumption.

However: As Peter says, this is all fairly pointless, and totally
unnecessary on this list. Colin gave me a meaningful answer in his
first response, and we've strayed pretty far from the topic. At this
point, I'm not going to convince anyone of my view, and no one else is
going to convince me more than they have of their view, so let's let
the thread die in peace. If other people want to continue the
discussion, go for it, but I'm going to try to keep quiet. 8-)

Thanks again to everyone who chimed in, though -- I appreciate the help.

-Alex McKenzie
First  |  Prev  | 
Pages: 1 2 3
Prev: Dear Lazy Web: Pseudo Randomisation Strategies onListing Websites
Next: add function to solr extension