Many programming languages I've encountered contain multiple integer types, including a distinction between "signed" and "unsigned integers".
I've never heard the term "unsigned integer" before I've gotten into programming, and to me it seems that unsigned integers are equivalent to natural numbers in math (aka ℕ0).
So why did we make up the term "unsigned integer" rather then just using the term "natural"? Where did it come from? Is there a valid rationale behind that term or is it just another accident of history?
In a signed integer, the first bit is a sign denoting whether the number is positive or negative. That naturally makes an unsigned integer, which lacks said sign and cannot distinguish between positive and negative values. "Natural number" would be rather misleading, since a (very) finite integer cannot possibly express anywhere near the full set of natural numbers.
Related
I already know the concept of negative binary numbers, The 0 at the position most significant bit represents that the binary is positive and 1 at the position of most significant bit represents that the binary is negative.
BUT THE PROBLEM THAT INTIMIDATED ME TO ASK A QUESTION ON STACKOVERFLOW IS THIS:
what about the times that we might want to represent a huge number that it's representation has occurred to have 1 in msb.
let me explain it in this way: by considering the above rule for making negative counterparts of our binary numbers we could say that ;
in an 8-bit system we have, For example, a value of positive 12 (decimal) would be written as 00001100 in binary, but negative 12 (decimal) would be written as
10001100 but what makes me confused a bit is that 10001100 could also be interpreted as 268 in decimal while we know that its the negative form of 12 in binary using this method of conversion.
I just want to know how to deal with this tricky, two-faced possible ways of interpreting a binary number, just like the example i gave above(it seem's to be negative, OH! but wait it might also not be:).
It depends on the type you use. If you're using an 8-bit representation which is signed, then the largest number you can store is 1111111 (i.e. the first bit is set aside).
In our example, that would convert to an integer value of 127.
If you use an unsigned type, then you have the extra bit available, allowing you to store 11111111, or 255 expressed as an integer.
A strongly typed language with a good compiler should catch you trying to assign, say, 134 to a signed 8 bit integer and vomit errors all over you.
If you're doing something strange fiddling around with bits yourself, you're on your own! There's no way of reconstructing, post hoc, whether it was intended to be a negative or a large positive, so you'll have to choose a system and stick with it.
The general convention nowadays is to stick with signed representations always - although I have seen code (usually for extreme compute tasks like astrophysical calculations) use unsigned values simply to save memory. And of course images will use unsigned values by convention, usually.
In two's-complement notation, there's always an odd-man-out value to compensate for the 0/origin value that is conceptually neither positive nor negative. We treat 0 as positive for the sake of pragmatism, and we treat its counterpart, which is a 1 in the top bit and 0 in the rest, as negative, but conceptually, they are both special values that have no sign, because in both cases, -v==v.
For instance, in a signed 32-bit value, this number might be represented in one of these based forms:
0b10000000000000000000000000000000
0x80000000
-2147483648
I've personally been using my own term for this odd value for a while, which I will share below as my own answer, and let you all decide whether it's worthy, but I wouldn't be surprised if there's already an accepted name for it.
I leave the rest to you...
Edit: On further research, I did find some sites claiming that "it is sometimes called the weird number", but these blurbs are consistently copied verbatim from a Wikipedia entry on two's complement notation, which itself only references a 2006 college research paper that's unavailable at the given location, but I found here, where it's only referred to in passing as such. Wikipedia also references a single book, but that book's usage appears to be based on the text of the Wikipedia entry, which existed before the book was written. I'm not convinced that anyone other than one University of Tokyo student ever called it "the weird number" in practice.
Depending on context, I might refer to it neutrally as the dead value or, if I'm feeling like anthropomorphizing it, I call it Death. I think of that lone top bit as a scythe of sorts.
I call it this for two reasons:
On the ring that is two's-complement notation, its counterpart is 0, which we commonly refer to as the origin. One antonym for origin is death.
This particular value, being ambiguous as it is, tends to catch out a lot of programmers. It is literally the death of a lot of unsuspecting algorithms.
When writing terse assembly, I tend to abbreviate it as just "D", for instance if I had a condition that was satisfied by all values greater that zero, and Death, I might call the flag "GZD".
I simply call that the minimum integer or minimum value, since that is indeed what it is in two's complement.
It's also described that way in the C standard limits.h (and C++ equivalent) header, such as with SCHAR_MIN, INT_MIN, LONG_MIN and so on.
How do I write 0xFA in signed mantissa. I converted it to binary = 1111_1010. Not sure where to go from here.
The question is "If the register file has 8 bits width total, write the following in signed mantissa."
Also, an explanation of signed mantissa would be great!
So what you have to work with is a byte of data with an unknown type, apparently.
In order to write a number in signed mantissa (see Significand) one would expect that your dealing with a floating point type such as single or double. However you've only got a single byte.
A single is 8 bytes so surely it can't be that and double is double trouble. Also a half requires 16 bits. The only logical alternative type would be SByte but in that case you will never get any numbers that have any mantissa (significant digits) after the decimal. In fact there is no decimal. So Perhaps this is a trick question?
If you go on the assumption of SByte, you get -6x10^0
Just in case you want proof, or if your curious how this looks during debug:
private void SByte2Dec()
{
sbyte convertsHexToSByte = Convert.ToSByte("0xFA", 16);
Single yourAnswer = Convert.ToSingle(convertsHexToSByte);
label1.Text = Convert.ToString(youranswer);
}
In this example I had a windows form with nothing but label1 on it.
Then I put SByte2Dec(); right under InitializeComponent();
The solution is -122. Not sure how to get there...any ideas?
Working backwards from the answer it's simple to see what your professor has done. He is assuming the MSB is the sign bit and the rest is treated like a 7 bit integer. There is a precedent for this, called "Signed Magnitude Representation" but it's not used in modern computing. These days pretty much everyone is using Two's compliment.
I take it this is a beginners course and rather than go though all the trouble of explaining two's compliment and data types your professor is mainly trying to drive home the point of the MSB being a sign bit. If you got the whole sign bit thing and don't know anything else about the way modern computer hardware performs calculations, then you would probably arrive at the same answer.
My guess is that your professor also took to wording the question in a strange way so as to throw you off the path if you tried to Google the answer. If you want to get him back, ask him what the difference between "1000 0000" and "000 0000" is. Also if you or anyone else in the class answered -6 and he counted it wrong, he should be fired. Those students should be awarded bonus points for teaching themselves about two's compliment.
Why would the signed mantissa be -6? I see that the 2's complement is -6 but signed mantissa is different?
I have you read the wiki article I linked to on "Significand"?
The important thing to realize is that "signed mantissa" is not a data type. However, there are (were?) many different machine-specific data types that implemented their own versions of storing floating point numbers before the IEEE standard became widely adopted. These early data types were often referred to as DFP or decimal floating point numbers as opposed to binary floating point. Read this paper and for more in-depth understanding. Also this paper covers the topic quite well.
As I stated earlier, your professor most likely used the terminology "signed mantissa" to throw you off if you went searching the internet for the answer. Apparently you were expected to read between the lines and know that what he was really asking for was a form of decimal floating point, or Signed Magnitude Representation.
"Signed Mantissa" ≠ Two's Compliment
"Signed Mantissa" is to be interpreted as some form of Decimal Floating Point
Where as, Two's Compliment is a form of Binary Floating Point
I understand what a datatype is (intuitively). But I need the formal definition. I don't understand if it is a set or it's the names 'int' 'float' etc. The formal definition found on wikipedia is confusing.
In computer programming, a data type is a classification identifying one of various types of data, such as floating-point, integer, or Boolean, that determines the possible values for that type; the operations that can be done on values of that type; the meaning of the data; and the way values of that type can be stored.
Can anyone help me with that?
Yep. What that's saying is that a data type has three pieces:
The various possible values. So, for example, an eight bit signed integer might have -127..128. This of that as a set of values V.
The operations: so an 8-bit signed integer might have +, -, * (multiply), and / (divide). The full definition would define those as functions from V into V, or possible as a function from V into float for division.
The way it's stored -- I sort of gave it away when I said "eight bit signed integer". The other detail is that I'm assuming a specific representation by the way I showed the range of values.
You might, if you're into object oriented programming, notice that this is very much like the definition of a class, which is defined by the storage used by each object, adn the methods of the class. Providing those parts for some arbitrary thing, but not inheritance rules, gives you what's called an abstract data type.
Update
#Appy, there's some room for differences in the formalities. I was a little subtle because it was late and I was suddenly uncertain if I'd assumed one's complement or two's complement -- of course it's two's complement. So interpretation is included in my description. Abstractly, though, you'd say it is a algebraic structure T=(V,O) where V is a set of values, O a set of functions from V into some arbitrary type -- remember '==' for example will be a function eq:V × V → {0,1} so you can't expect every operation to be into V.
I can define it as a classification of a particular type of information. It is easy for humans to distinguish between different types of data. We can usually tell at a glance whether a number is a percentage, a time, or an amount of money. We do this through special symbols %, :, and $.
Basically it's the concept that I am sure you grock. For computers however a data type is defined and has various associated attributes, like size, like a definition keywork (sometimes), the values it can take (numbers or characters for example) and operations that can be done on it like add subtract for numbers and append on string or compare on a character, etc. These differ from language to language and even from environment to env. (16 - 32 bit ints/ 32 - 64 envs./ etc).
If there is anything I am missing or needs refining please ask as this is fairly open ended.
5 (decimal) in binary 00000101
-5 (two's complement) in binary 11111011
but 11111011 is also 251 (decimal)!
How does computer discern one from another??
How does it know whether it's -5 or 251??
it's THE SAME 11111011
Thanks in advance!!
Signed bytes have a maximum of 127.
Unsigned bytes cannot be negative.
The compiler knows whether the variable holding that value is of signed or unsigend type, and treats it appropriately.
If your program chooses to treat the byte as signed, the run-time system decides whether the byte is to be considered positive or negative according to the high-order bit. A 1 in that high-order bit (bit 7, counting from the low-order bit 0) means the number is negative; a 0 in that bit position means the number is positive. So, in the case of 11111011, bit 7 is set to 1 and the number is treated, accordingly, as negative.
Because the sign bit takes up one bit position, the absolute magnitude of the number can range from 0 to 127, as was said before.
If your program chooses to treat the byte as unsigned, on the other hand, what would have been the sign bit is included in the magnitude, which can then range from 0 to 255.
Two's complement is designed to allow signed numbers to be added/substracted to one another in the same way unsigned numbers are. So there are only two cases where the signed-ness of numbers affect the computer at low level.
when there are overflows
when you are performing operations on mixed: one signed, one unsigned
Different processors take different tacks for this. WRT orverflows, the MIPS RISC architecture, for example, deals with overflows using traps. See http://en.wikipedia.org/wiki/MIPS_architecture#MIPS_I_instruction_formats
To the best of my knowledge, mixing signed and unsigned needs to avoided at a program level.
If you're asking "how does the program know how to interpret the value" - in general it's because you've told the compiler the "type" of the variable you assigned the value to. The program doesn't actually care if 00000101 as "5 decimal", it just has an unsigned integer with value 00000101 that it can perform operations legal for unsigned integers upon, and will behave in a given manner if you try to compare with or cast to a different "type" of variable.
At the end of the day everything in programming comes down to binary - all data (strings, numbers, images, sounds etc etc) and the compiled code just ends up as a large binary blob.