How is pairwise XOR calculated ? I googled but could not find anything relevant.
EDIT : How is it different from normal XOR?
Each bit of the number are pairwise XOR'd with each other. For example:
15 = 0000 1111
21 = 0001 0101
So, the XOR is
0001 1010 = 26
Related
I need to initialize an register with an specific decimal value in order to extract the bits of another register (by doing this). The only problem is, since I need to do an andoperation with a very large decimal, it turns out to be very difficult to convert a binary number into a decimal number without a calculator to perform this operation.
So I am interested to know if there is any way of initializing a register with a binary value directly
If your assembler/simulator does not allow you to write binary constants but it allows you to write hexadecimal ones then you may easily encode a binary number in hexadecimal.
Starting from the least significand bit, every 4 bits you encode its hexadecimal value using the following table:
0000 - 0
0001 - 1
0010 - 2
0011 - 3
0100 - 4
0101 - 5
0110 - 6
0111 - 7
1000 - 8
1001 - 9
1010 - A
1011 - B
1100 - C
1101 - D
1110 - E
1111 - F
If the original binary number does not have a multiple of 4 bits you fill the most significand bits to 0 until it fills the last packet.
For example, you may encode this words in hexadecimal converting them from binary numbers:
myvar: .word 0x1234 # binary 1 0010 0011 0100
other: .word 0xCAFEBABE # binary 1100 1010 1111 1110 1011 1010 1011 1110
I understood the purpose of gray codes in a clear way.
EE Times: Gray Code Fundamentals
But I am not able to conceptually understand why the gray code can be generated as below
Gi = Bi+1 ⊕ Bi , i = n − 1, . . . , 0, where Bn is taken as 0.
Could someone help me on this conceptually.
In standard binary, if you exclusive-or a number less than n**2 with n**2-1, then you effectively reverse the order of that count:
x x^11
00 11
01 10
10 01
11 00
So, for a two-bit number, if we exclusive-or the bottom bit with the next bit:
x x^(x>>1)
00 00
01 01
10 11
11 10
We are alternately reversing the order of the count for the bottom bit, depending on whether the bit above it is set or clear. This ensures that when bit 1 changes, bit 0 stays the same (where it would otherwise have wrapped around to zero and started counting up again).
For every bit that is added at the top of the counter, we need to repeat this reflection of the count of the bit below, to ensure that it doesn't become cleared as the new bit becomes set. The remaining bits follow in the same pattern, being reflected by the bit above them such that they count backwards rather than wrapping around.
When you look into Wikipedia, you will see that it is:
G0 = B0
Gi = Bi EXOR Gi-1
Does that make more sense?
Check this for the Graycodes given in the pages you've read - you'll see it holds.
Would you like to see a proof of the above, or is looking at the examples enough?
I find Vovanium's answer really helpful to understand the formula that generates Gray Code sequence. The idea is that we want to generate a sequence where G(n+1) only changes one bit from G(n), i.e. G(n+1) xor G(n) only has 1 bit set. Vovanium's answer is partially copied below.
If you look at binary counting sequence, you note, that neighboring codes differ at several last bits (with no holes), so if you xor them, pattern of several trailing 1's appear. Also, when you shift numbers right, xors also will be shifted right: (A xor B)>>N == A>>N xor B>>N.
N N>>1 gray
0000 . 0000 . 0000 .
| >xor = 0001 >xor = 0000 >xor = 0001
0001 . 0000 . 0001 .
|| >xor = 0011 | >xor = 0001 >xor = 0010
0010 . 0001 . 0011 .
| >xor = 0001 >xor = 0000 >xor = 0001
0011 . 0001 . 0010 .
||| >xor = 0111 || >xor = 0011 >xor = 0100
0100 0010 0110
Original Xor results and shifted results differ in single bit (i marked them by dot above). This means that if you xor them, you'll get pattern with 1 bit set. So,
(A xor B) xor (A>>1 xor B>>1) == (A xor A>>1) xor (B xor B>>1) == gray (A) xor gray (B)
I have answered the question but i could not understand the part where its says get the resulting sum in 16-bit binary, check your answer by converting the sum into decimal.
1.Add ‘A’ and ‘B’ in binary to get the resulting sum in 16-bit binary, check your answer by converting the sum into decimal.
Decimal number = 58927634
A= 5892 to Binary 1011 1000 0010 0
B= 7634 to Binary 1110 1110 1001 0
a + b = 11010011010110
thanks alot
Regards
Let me explain:
A = 00005892
B = 00007634
in base 10 number system, with 8 decimals to represent it.
and...
A = 0001 0111 0000 0100
B = 0001 1101 1101 0010
in base 2 number system, with 16 bits to represent it.
I hope it makes sense to you now.
And the sum of A and B, in base 2 number system with 16 bits to represent it....
0011 0100 1101 0110
although, we needed just 14 bits....
Your answer is correct, but its width is 14 bits long.
i'm studying computer science and i can't figure something out of my own.
There is this number : -233 using 10 bit representation
What i need to do is to represent with excess notation the number (2^n-1)
So, i came up with:
1 base 10 = 0000000001
2^10-1 = 1000000000
1 base 10 in my notation = 1000000001
So, my -256 is 0000000001
And my 255 is 1111111110
What is the -233 number following this notation?
The result on the book is 0 1 0 0 0 1 0 1 1 1
My result: 0 0 0 0 0 1 0 1 1 1
Hope you guys can help me.
I think you were on the right path, but just did a small error.
As I was not familiar with the notation, I had to take a look at it first. It seems like K is usually chosen as 2^(n-1) = 2^9 = 512. Which means 00 0000 0000 = -512 and 11 1111 1111 = 511. I don't know how you get -256, maybe there is your error.
Now, from -512 (00 0000 0000) to -233 there is a difference of 279 (01 0001 0111). This seems to be the result of your example.
For easier construction you can do this (assuming K = 2^(n-1)) - example number -12:
Use the binary representation of the positive value (12). 00 0000 1100
Add K (2^(n-1)): 10 0000 1100
Invert all bits: 01 1111 0011
Add 1 (because of the zero value): 01 1111 0100
I'm trying to understand these illustrations but there are parts which I don't understand:
"But the computer had to count backwards for the negative numbers"
Why does adding a 1 to the front of a binary mean the computer has to count backwards?
"Flip the bits and add 1!"
What does that mean add 1?
woops: http://csillustrated.berkeley.edu/PDFs/integer-representations.pdf
This may be easiest to show by example. Here are the numbers from -4 to 4 represented in binary:
4 0000 0100
3 0000 0011
2 0000 0010
1 0000 0001
0 0000 0000
-1 1111 1111
-2 1111 1110
-3 1111 1101
-4 1111 1100
So say we want to go from 1 to -1. We first flip all the bits of 1
1 0000 0001
flip bits
-----------
1111 1110
Then we add a 1:
1111 1110
+ 1
-----------
1111 1111
We now have -1.
I'm not seeing the illustrations, but you're probably talking about Two's complement representation. (http://en.wikipedia.org/wiki/Two's_complement)
Why does adding a 1 to the front mean the computer has to count backwards?
Due to how carrying works, FFFFFFFFF + 1 == 0
and 0 - 1 == FFFFFFFF. All the bits get flipped, including the first bit.
If you simply define the negative numbers as those starting with a 1 bit (80000000 - FFFFFFFF) then you get a nice uniform behavior for addition with a natural overflow.
Flip the bits and add 1: in 2's complement, this negates a number
~x+1 == -x; // always true
What you're talking about is called signed integers.