From: Richard Quadling > On 24 August 2010 21:42, Andy McKenzie <amckenzie4@xxxxxxxxx> wrote: >> On Tue, Aug 24, 2010 at 3:55 PM, Ford, Mike <M.Ford@xxxxxxxxxxxxxx> wrote: >>>> From: Andy McKenzie [mailto:amckenzie4@xxxxxxxxx] >>> >>>> 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
