This is a basic question and probably very easy but I am really confused.
I have an 8-bit hex number 0x9F and I need to interpret this number as an unsigned decimal number.
Do I just convert that to the binary form 1001 1111? and then the decimal number is 159?
I'm sorry if this question is trivial but my professor said I couldn't e-mail him questions and I don't know anyone in my class. He made it sound like when converting from hex to binary that it will be the 2's compliment. So I don't know if I need to convert it back to normal or not before converting to decimal.
We had a signed decimal number and converted it to binary, then took the 2's compliment and converted to hex. Is that only with signed numbers?
It's simply 9 * 16 + F where F is 15 (the letters A thru F stand for 10 thru 15). In other words, 0x9F is 159.
It's no different really to the number 314,159 being:
3 * 100,000 (10^5, "to the power of", not "xor")
+ 1 * 10,000 (10^4)
+ 4 * 1,000 (10^3)
+ 1 * 100 (10^2)
+ 5 * 10 (10^1)
+ 9 * 1 (10^0)
for decimal (base 10).
The signedness of such a number is sort of "one level up" from there. The unsigned value of 159 (in 8 bits) is indeed a negative number but only if you interpret it as one.
Related
Let's say I want to add 4 binary numbers in 2's Complement: a+b+c+d. I have a circuit that can add 2 binary numbers at a time, and that detects whether overflow has occurred for the corresponding sum (by using XOR with the last carry bits).
When adding multiple numbers in 2's Complement, it is possible that the intermediate sums overflow, while the final result does not. For example:
4 + 5 + (-6) expressed with 4 bits and C2:
0100 +
0101
====
1001 (-7 : overflow)
1001 +
1010
====
0011 (3, the correct result)
My question is: how can I know, when adding 4 binary numbers with N bits, whether the final result overflows or not? Is there any logical expression or circuit that can automatically detect when overflow occurs?
In your example, 0100 + 0101, represented with 4 bits, gives the hardware result of 1001.
It is now up to you how you interpret these bits.
If you interpret them as 2’s complement integers, the result is wrong (decimal -7, overflow).
If you interpret them as unsigned integers, the result is correct (decimal 9).
If you add then 1010, you have to think about how to interpret these bits.
Unsigned, they are decimal 10, 2’s complement, they are decimal -6.
Still, it is up to you, how you interpret the result. It is 0011 plus a carry bit, since 1001 + 1010 gives 10011.
Thus the problem arises because you change the interpretation of the bits during the computation.
This cannot be handled by any logical expression or circuit.
this is a school assignment. I've been given homework and one of the problems is to figure out the value after adding two hexadecimal values.
0x80000000 and 0xD0000000. I understand that D = 13, but I don't understand how the answer is 15, because 8 + 13 = 23? Could someone explain what I am doing wrong, and what I should do instead?
Thanks!
It's easy if you think that every digit represents a quadruple, for example
0xDEADBEEF = 13*16⁷+14*16⁶+10*16⁵+13*16⁴+11*16³+14*16²+14*16¹+15*16⁰.
The above hexadecimal value needs an algorithm to translate to a format the the ALU can add, for instance binary numbers.
D is 13 in decimal because D is digit number 13 if A replaces 10 and so on (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). The position of D is 7, so the number is 13*16⁷.
We notice that it is easier to LSB if we do this, and recognize that F is 15 in hexadecimal notation and therefore the number to the left will be 15*16⁰=15.
0xFF therefore means 15*16¹+15*16⁰=15*16+15=255 (you can check this with a calculator).
Now the algorithm is hopefully clear.
3735928559 is the decimal value of DEADBEEF because ==13*16^7+14*16^6+10*16^5+13*16^4+11*16^3+14*16^2+14*16^1+15*16^0=3735928559.
Some times I convert the hexadecimal into binary base 2 this because I feel more confident to do arithmetic with binary base 2than hexadecimal.
In order to do so you need to arrange every hexadecimal into group of 4 bits binary number.
hex 0x8 + 0xD
Convert to binary
binary 1000 + 1101 = 10101 = 21
group it again as 4 bits
0001 0101 = 0x15
I ignored if it's signed number and didn't used two's complement.
I am changing an 8-digit hexadecimal number to a real number Y.
The number is 0xAC0396ED
My question is: Shall I take into consideration the 0x? What is the significance of the 0x?
I researched it and based on wikipedia, I got this:
"use the prefix 0x for numeric constants represented in hex"
What I plan on doing is take the part AC0396ED and change it to binary, then from binary manipulate the 32 bit number byte dividing the number intro 3 parts: sign, exponent, and fraction.
My last question is why do we need hexacdecimal, decimal, octal? Why don't we just stick to binary in all our arithmetic and operations?
Thank you.
My question is: Shall I take into consideration the 0x? What is the significance of the 0x?
No - you should not take that into consideration - its only a notation for hexadecimal base system
What I plan on doing is take the part AC0396ED and change it to binary, then from binary manipulate the 32 bit number byte dividing the number intro 3 parts: sign, exponent, and fraction.
Here is how you calculate it:
AC0396ED =>
10 12 0 3 9 6 14 13 in decimal. Then to binary
1010 1100 0000 0011 1001 0110 1110 1101
here you have all bits i.e 32 bits
1 | 01011000 | 00000111001011011101101
so the first bit is 1 => the number is negative
the second is the exponent
the third is the mantissa
My last question is why do we need hexacdecimal, decimal, octal? Why don't we just stick to binary in all our arithmetic and operations?
Its much more easy to stick to hexadecimal system - compare the 32 bits to the AC0396ED
Right now I'm preparing for my AP Computer Science exam, and I need some help understanding how to convert between decimal, hexadecimal, and binary values by hand. The book that I'm using (Barron's) includes an example but does not explain it very well.
What are the formulas that one should use for conversion between these number types?
Are you happy that you understand number bases? If not, then you will need to read up on this or you'll just be blindly following some rules.
Plenty of books would spend a whole chapter or more on this...
Binary is base 2, Decimal is base 10, Hexadecimal is base 16.
So Binary uses digits 0 and 1, Decimal uses 0-9, Hexadecimal uses 0-9 and then we run out so we use A-F as well.
So the position of a decimal digit indicates units, tens, hundreds, thousands... these are the "powers of 10"
The position of a binary digit indicates units, 2s, 4s, 8s, 16s, 32s...the powers of 2
The position of hex digits indicates units, 16s, 256s...the powers of 16
For binary to decimal, add up each 1 multiplied by its 'power', so working from right to left:
1001 binary = 1*1 + 0*2 + 0*4 + 1*8 = 9 decimal
For binary to hex, you can either work it out the total number in decimal and then convert to hex, or you can convert each 4-bit sequence into a single hex digit:
1101 binary = 13 decimal = D hex
1111 0001 binary = F1 hex
For hex to binary, reverse the previous example - it's not too bad to do in your head because you just need to work out which of 8,4,2,1 you need to add up to get the desired value.
For decimal to binary, it's more of a long division problem - find the biggest power of 2 smaller than your input, set the corresponding binary bit to 1, and subtract that power of 2 from the original decimal number. Repeat until you have zero left.
E.g. for 87:
the highest power of two there is 1,2,4,8,16,32,64!
64 is 2^6 so we set the relevant bit to 1 in our result: 1000000
87 - 64 = 23
the next highest power of 2 smaller than 23 is 16, so set the bit: 1010000
repeat for 4,2,1
final result 1010111 binary
i.e. 64+16+4+2+1 = 87 in decimal
For hex to decimal, it's like binary to decimal, only you multiply by 1,16,256... instead of 1,2,4,8...
For decimal to hex, it's like decimal to binary, only you are looking for powers of 16, not 2. This is the hardest one to do manually.
This is a very fundamental question, whose detailed answer, on an entry level could very well be a couple of pages. Try to google it :-)
Can someone explain to me the steps to convert a number in decimal format (such as 2+(2/7)) into IEEE 754 Floating Point representation? Thanks!
First, 2 + 2/7 isn't in what most people would call "decimal format". "Decimal format" would more commonly be used to indicate a number like:
2.285714285714285714285714285714285714285714...
Even the ... is a little bit fast and loose. More commonly, the number would be truncated or rounded to some number of decimal digits:
2.2857142857142857
Of course, at this point, it is no longer exactly equal to 2 + 2/7, but is "close enough" for most uses.
We do something similar to convert a number to a IEEE-754 format; instead of base 10, we begin by writing the number in base 2:
10.010010010010010010010010010010010010010010010010010010010010...
Next we "normalize" the number, by writing it in the form 2^e * 1.xxx... for some exponent e (specifically, the digit position of the leading bit of our number):
2^1 * 1.0010010010010010010010010010010010010010010010010010010010010...
At this point, we have to choose a specific IEEE-754 format, because we need to know how many digits to keep around. Let's choose "single-precision", which has a 24-bit significand. We round the repeating binary number to 24 bits:
2^1 * 1.00100100100100100100100 10010010010010010010010010010010010010...
24 leading bits bits to be rounded away
Because the trailing bits to be rounded off are larger than 1000..., the number rounds up to:
2^1 * 1.00100100100100100100101
Now, how does this value actually get encoded in IEEE-754 format? The single-precision format has a leading signbit (zero, because the number is positive), followed by eight bits that contain the value 127 + e in binary, followed by the fractional part of the significand:
0 10000000 00100100100100100100101
s exponent fraction of significand
In hexadecimal, this gives 0x40124925.