Just off the top of my head, bitmap indexes and bit-sets are practical applications where one single bit can mean -254. It's all a matter of convention after all.

@abgemacht: I was expecting some serious flak; thank you for the positive response.

A number doesn't mean anything until you give it meaning, which is what everyone here is more or less correctly claiming. A standard answer that should be accepted would be 00000010 as a reasonable 2's complement negative representation for -254, since any other 8-bit combination couldn't really be interpreted as -254 in any standard way.

There are only 10 types of people.
Those who understand binary and those who don't.

^That's a good one actually.

Now I need to get back to learning for a test... I've had my break...

Your teacher probably won't accept this answer, but...

In Coral66 you can define a fixed point variable by specifying the position of the binary point. So 'FIXED' (8,1) Fred; would declare a variable called Fred whose least significant bit is worth 1/2, rather than 1. 'FIXED'(8,2) John; would have a least significant bit of 1/4.

You can also declare a fixed point variable with a binary point is to the right of but outside of the bit pattern. So 'FIXED' (8,-1) Bill; declares a variable called Bill whose least significant bit is worth 2.

When stored in Bill, 254 would be held as 0111,1111. -254 would be the 2's compliment of 254, which is a bit pattern of 1000,0001.

P.S. The largest variable I ever saw declared for use in real-world programming (rather than in training or anything) was 'FIXED'(16,-23).

Oh well, I lost interest. Will just have to see what the teacher thinks of my answer, I suppose he will count it as wrong as it is, but maybe not because he never explained this kind of case...

twos compliment forces the MSB to be 1 for negative numbers. That means you can't go up to 2^n in both directions where n is the number of bits. You only have half of the possibilities in each direction (0 goes with the positives). So if you're using 2's Comp, with 8 bits you can only express -128 to 127 (1000 0000 to 0111 1111)

that's not to say you cant do other stuff to represent -254, but if you do, then you aren't doing what computers and computer languages do. And that's all I pretend to know about ;-)

I once wrote a program in Java using a byte type, thinking it would behave the same as the C++ version where I wanted to loop from 0 to 255 and write it to a file. Since Java doesn't have unsigned types, it resulted in an endless loop because of the MSB being used to represent negative numbers.

for (byte b=0; b<255; ++b) //write b to file

once I incremented past 127 (0111 1111) The computer didn't care how the language interpreted it, it went through the incrementer and came out to (1000 0000) as it should have, but the the Java runtime evatluated the loop to see if b was less than 255 and it was, it was now -128, so it keeps incrementing all the way up to what would be 255 in the unsigned world (1111 1111) which is -1 in the signed world, then the incrementer did it's trick again, and incremented it, but dropping the leading 1 since there was no where to put it in 8 bits, so it became 0 (0000 0000) which is how you want the incrementer to add 1 to -1 : the answer is zero, after all, so the loop just kept going back to 127 again, and flipped again to -128 ... THAT was annoying!

@ sevas - I disagree. There are actually 10 types of people in the world
1) Those who understand ternary
2) those who don't
10) those who thought this was a binary joke

(Credit to whoever I stole that from)

@philcore, is that a rather annoying example of an overflow error?

No error. It just keeps on counting. an overflow error is when you overrun the bounds of a memory segment, especially the stack or heap. If you try to allocate more than you are allowed to, you get an overflow. In my case it was just a difference between the computer incremental the way it should, but the java runtime interpreting the results incorrectly (incorrectly for my intention, that is, the JRE did exactly what it purported to do).

Had it been an overflow or an index out of range in the case of an array, then the program would have stopped when it hit the exception. As it was it just kept on cracking out 0 to 255, then repeating. Making it harder for me to track down, but at the same time giving me a deeper appreciation for binary math, and two's compliment with signed integer types.

@phil

I agree that conventionally, you'd want the MSB to be 1 for a negative number, but as far as digital logic goes, I don't think it really matters. You'll get the correct answer either way, even if it is a bit harder to parse.

@Phil, you said it incremented from 127 to -128, now correct me if i'm wrong but that's not an increment.

And the overflow is where you attempted to go from 1111 1111 +1 -> 0000 0000, and lost the 9th 1, because it was 'out of array' - or more to the point, an 8-bit system ignores the 9th bit when needed.

if your counting system was able to go from 127 to 128 and on... you wouldn't have had the error, but that would have required more bits.

@abge: but when the language runtime sees (1111 1111) as -1 instead of 255, it does matter, because the condition b<255 will evaluate to true instead of false, and it will never break the loop because the next increment will be back to zero. And this can be extended to any number greater than 127 with a signed byte type. (1000 0001) is 129 in unsigned, but in signed it's -127. So while the digital logic might work out fine, the programmatic logic is screwed. digitally (1000 0001) is "greater than" (0111 1111) but to the runtime, if there is no unsigned byte type, than it is "less than"

@Orth: It's not an error to go from (1111 1111) to (0000 0000) after an increment operation. This is exactly what you'd expect: -1 + 1 = 0. You WANT the computer to do it exactly like that if the type is signed. That's the reason 2's compliment is used for negative numbers at the digital level. So that at the "math level" that we think in, the transition from negative to positive works the way it should.

At the digital level, you only have 8 transistors flipping from 1 to 0. There is no 9th transistor to ignore, at least conceptually. With 32 and 64 bit processors, it's probably implemented in a more complex way - but you can extend the digital reasoning to where all 32 (or 64) bits are 1: still -1 to the run time, and when you add 1 you should get 0, not an overflow error.

Remember that primitive types aren't represented as arrays, so you can't go out of bounds with them. THey're just going to flip at the digital level the way your program tells them to. Even if the results are unintended.

Yeah, I see what you're saying. Oh well, I hope steephie learned a lesson about listening to people who sound like they know what they're talking about on the internet : )

@Orth - sorry I missed the forst question. At the digital level, it is definitely an increment. It will go throw the increment register, rather than even use a seperate register as a place holder to do the addition - way more optimized. 1 assembly instruction, instead of 3.

But aside from it's implementation - even just looking at the digital math, if your program says that (0111 1111) = 127 and you add one to that ... digitally, the next number is (1000 0000). With an unsigned byte, that equals 128, but if it's a signed integer type, then it equals -128. So that's my entire point, I assumed it would be 129, and then 128 + 1 = 129 and so on (1000 0000) + (0000 0001) = (1000 0001). But if you're using two's compliment to represent negatives (which every C-based language does), then other than the odd flip from the MAX positive to the MIN negative when the MSB bit flips, every thing works out as expected, because -128 + 1 = -127 (1000 0000) + (0000 0001) = (1000 0001)

It's actually a very cool and useful system - but it does have the pitfall when you can't tell your runtime, that you want it to be signed versus unsigned. That was a major drawback for java for me compared to C++ when Java was just a baby (hopefully, that's no longer an issue, but I haven't ever checked to see if they changed it, I just started programming C# instead - which does have unsigned integer types)

'It's actually a very cool and useful system - but it does have the pitfall when you can't tell your runtime, that you want it to be signed versus unsigned.'

i thought the pitfall was that it isn't obvious to the programmer what's going on under the hood, so mistakes crop up which defy debugging...

Well they don't "defy" debugging. They just force you to learn what's going on under the hood in order to debug. And that's a valuable exercise.

Hey, Phil. I guess you know this by now, but you should have used Byte.MAX_VALUE as your greater-than comparison value OR used an larger integer type if all you wanted to do was count numbers.
BTW: what kind of application needs to simply write 0-255 to a file? Perhaps to write "Hello World" 256 times with a line number? :)

@numbat: I was writing a binary file. They weren't the ASCII codes for the representations of the numbers, but just a single byte value. The purpose of it was as a test for an encryption/file splitter implementation. I wanted a simple app that would write arbitrarily large binary files which were immediately recognizable with a binary editor, so that when I did the split/encrypt then the decrypt/join, I could visually inspect the files to se that everything was cool before trying the same on large pdf files. If the file was several megs it would actually write many 0s, then many 1s and so on so I could still visually inspect them with a binary editor.

It was a port of a C++ program that I had written prior to it, so part of my frustration was that it dint just work - and the fact that Java had a type called Byte that was signed in the first place. I mean its a Byte! You want it to go from 0 to 255 damnit!

I did figure out how to make it work, but it made it less elegant unnecessarily. I think I ended up checking inside the loop for it to equal 127, then just assigned it to -128 so that the byte values worked out. Now that I think about it, I most likely had to make it a while loop so that I could manually increment it or reassign it as a for loop would have caused it to skip -128 and go right to -127 ... Unless I wrote the value after the assignment. Then the for loop incrementing would have been fine. I don't remember exactly, but it seemed like a hack after coming from C++

And no operator overloading? Why the hell not? I was glad when C# came along and had both of those back in but still had the more simple aspects of Java.

@phil I totally understand the frustration with negative Byte range and having no alternative in Java. I wish Java had turned out better. It held so much promise when it first came out but I have rarely found a use for it in my problem domain: trading systems.