I am currently reading a book about "bit fiddling" and the following formula appears:
x-y = x+¬y+1
But this doesn't seem to work. Example:
x = 0100
y = 0010
x-y = 0010
¬y = 1101
¬y+1 = 1110
x+1110 = 10010
But 10010 != 0010...
Where did I make a mistake (if any)?
(The book is "Hacker's Delight" by Henry S. Warren.)
You only have a four bit system! That extra 1 on the left of your final result can't exist. It should be:
x = 0100
y = 0010
~y = 1101
~y + 1 = 1110
x + 1110 = 0010
The other bit overflows, and isn't part of your result. You may want to read up on two's complement arithmetic.
You are carrying the extra bit. In real computers if you overflow the word, the bit disappears. (actually it gets saved in a carry flag.) .
Assuming the numbers are constrained to 4 bits, then the fifth 1 would be truncated, leaving you with 0010.
It's all about overflow. You only have four bits, so it's not 10010, but 0010.
Just to add to the answers, in a 2's complement system:
~x + 1 = -x
Say x = 2. In 4 bits, that's 0010.
~x = 1101
~x + 1 = 1110
And 1110 is -2
Related
I've been browsing around the internet looking to validate my interpretation of 2's Complement.
Everywhere I look (including my educational class) I see the following:
Invert all bits in the # (1->0 and simultaneously 0->1, i.e. swap all 1s and 0s for all bits)
Add 1 to the now-inverted #.
However, my interpretation is to not do any of that but rather think of the MSB (Most Significant Bit, the Bit with the highest place value) as the same place value but multiplied by -1, then add the rest of the bits normally (typical place value addition).
The maximum # and minimum # achieved by my interpretation is the exact same as with 2's complement (as shown by first 3 examples).
E.g.
0000 = 0(-23) + 0(22)+0(21)+0(20) = 0
1000 = 1(-23) + 0(22)+0(21)+0(20) = -8
0111 = 0(-23) + 1(22)+1(21)+1(20) = +7
1111 = 1(-23) + 1(22)+1(21)+1(20) = -8+7 = -1 (example for signed 4-bit #s)
...........................................................................................................................................................................................................
1111 1111 = -27 + 26+25+24 + 23+22+21+20 = -128 + 64+32+16+8+4+2+1
= -128+(27-1) = -128+127 = -1 (example for signed 8-bit #s)
...........................................................................................................................................................................................................
1111 1111 1111 1111 = -215 + 214+213+212+211+210+29+28+27+26+25+24+23+22+21+20
= -32768 + 16384+8192+4096 + 2048+1024+512+256 + 128+64+32+16 + 8+4+2+1
= -32768+(215-1) = -32768 + 32767 = -1 (example for signed 16-bit #s)
...........................................................................................................................................................................................................
1111 1111 1111 1111 1111 1111 1111 1111 =
=-231+230+229+228+227+226+225+224+223+222+221+220+219+218+217+216+215+214+213+212+211+210+29+28+27+26+25+24+23+22+21+20
= -2,147,483,648 + ... + 32768+16384+8192+4096 + 2048+1024+512+256 + 128+64+32+16 + 8+4+2+1
= -2,147,483,648 + (2,147,483,648-1) = -1 (example for signed 32-bit #s)
...........................................................................................................................................................................................................
My interpretation appears to work perfectly.
At least to me, this interpretation is much easier to understand, but why haven't I ever seen anybody else use it? Is the interpretation flawed in some non obvious way?
Finally, is this the way 2's complement was invented with another method being taught instead?
So the exercise says: "Consider binary encoding of real numbers on 16 bits. Fill the empty points of the binary encoding of the number -0.625 knowing that "1110" stands for the exposant and is minus one "-1"
_ 1110_ _ _ _ _ _ _ _ _ _ _ "
I can't find the answer and I know this is not a hard exercise (at least it doesn't look like a hard one).
Let's ignore the sign for now, and decompose the value 0.625 into (negative) powers of 2:
0.625(dec) = 5 * 0.125 = 5 * 1/8 = 0.101(bin) * 2^0
This should be normalized (value shifted left until there is a one before the decimal point, and exponent adjusted accordingly), so it becomes
0.625(dec) = 1.01(bin) * 2^-1 (or 1.25 * 0.5)
With hidden bit
Assuming you have a hidden bit scenario (meaning that, for normalized values, the top bit is always 1, so it is not stored), this becomes .01 filled up on the right with zero bits, so you get
sign = 1 -- 1 bit
exponent = 1110 -- 4 bits
significand = 0100 0000 000 -- 11 bits
So the bits are:
1 1110 01000000000
Grouped differently:
1111 0010 0000 0000(bin) or F200(hex)
Without hidden bit (i.e. top bit stored)
If there is no hidden bit scenario, it becomes
1 1110 10100000000
or
1111 0101 0000 0000(bin) = F500(hex)
First of all you need to understand that each number "z" can be represented by
z = m * b^e
m = Mantissa, b = bias, e = exponent
So -0.625 could be represented as:
-0.625 * 10^ 0
-6,25 * 10^-1
-62,5 * 10^-2
-0,0625 * 10^ 1
With the IEEE conversion we aim for the normalized floating point number which means there is only one preceding number before the comma (-6,25 * 10^-1)
In binary the single number before the comma will always be a 1, so this number will not be stored.
You're converting into a 16 bit float so you have:
1 Bit sign 5 Bits Exponent 10 Bits mantissa == 16Bits
Since the exponent can be negative and positive (as you've seen above this depends only on the comma shifting) they came up with the so called bias. For 5 bits the bias value is 01 111 == 15(dez) with 14 beeing ^-1 and 16 beeing ^1 ...
Ok enough small talk lets convert your number as an example to show the process of conversion:
Convert the pre-decimal position to binary as always
Multiply the decimal place by 2 if the result is greater 1, subtract 1 and notate 1 if it's smaller 0 notate 0.
Proceed this step until the result is == 0 or you've notated as many numbers as your mantissa has
shift the comma to only one pre-decimal and count the shiftings. if you shifted to the left add the count to the bias if you have to shift to the right subtract the count from the bias. This is your exponent
Dertmine your sign and add all parts together
-0.625
1. 0 to binary == 0
2. 0.625 * 2 = 1.25 ==> -1
0.25 * 2 = 0.5 ==> 0
0.5 * 2 = 1 ==> -1
Abort
3. The intermediary result therefore is -0.101
shift the comma 1 times to the right for a normalized floating point number:
-1.01
exponent = bias + (-1) == 15 - 1 == 14(dez) == 01110(bin)
4. put the parts together, sign = 1(negative), (and remember we do not store the leading 1 of number)
1 01110 01
since we aborted during our mantissa calculation fill the rest of the bits with 0:
1 01110 01 000 000 00
The IEEE 754 standard specifies a binary16 as having the following format:
Sign bit: 1 bit
Exponent width: 5 bits
Significand precision: 11 bits (10 explicitly stored)
Equation = exp(-1, signbit) x exp(2, exponent-15) x (1.significantbits)
Solution is as follows,
-0.625 = -1 x 0.5 x 1.25
significant bits = 25 = 11001
exponent = 14 = 01110
signbit = 1
ans = (1)(01110)(0000011001)
What are w-bit words in computer architecture ?
For two 7 bit words
1011001 = A
1101011 = B , how does multiplication returns
10010100110011 ?
Isn't there simple binary multiplication involved in these ?
Please provide an example.
w-bit is just the typical nomenclature for n-bit because w is usually short for word size
Both adding and multiplying are done just the same as in decimal (base 10). You just need to remember this truth table:
Multiplying
-----------
0 x 0 = 0
0 x 1 = 0
1 x 0 = 0
1 x 1 = 1
Adding
-----------
0 + 0 = 0
0 + 1 = 1
1 + 0 = 1
1 + 1 = 0 (w/ carry)
First adding. To add, you add just like you would in normal arithmetic, except follow the truth table above:
00000101 = 5
+ 00000011 = 3
--------------
00001000 = 8
How this works is that you start from the right and work left. 1 + 1 = 0, but you carry a 1 over to the next column. So the next column is 0 + 1, which would be 1, but since you carried another 1 from the previous column, its really 1 + 1, which is 0. You carry a 1 over the next column, which is 1 + 0, but really 1 + 1 because of the carry. So 0 again and finally move the 1 to the next column, which is 0 + 0, but because of our carry, becomes 1 + 0, which is 1. So our answer is 1000, which is 8 in decimal. 5 + 3 = 8, so we know we are right.
Next, multiplying:
00000101 = 5
x 00000011 = 3
----------
101 = 5
+ 1010 = 10
----------
1111 = 15
How this works is you multiply the top number 00000101 by the right most digit in the second row. So 00000011 is our second row and 1 is the right most digit, so 00000101 times 1 = 101. Next you put a 0 placeholder in the right most column below it, just like in normal multiplication. Then you multiply our top original number 00000101 by the next digit going left in our original problem 00000011. Again it produce 101. Next you simply add 101 + 1010 = 1111 ...That is the answer
Yes, it's simple binary multiplication:
>>> 0b1011001
89
>>> chr(_)
'Y'
>>> 0b1101011
107
>>> chr(_)
'k'
>>> ord('Y') * ord('k')
9523
>>> bin(_)
'0b10010100110011'
If you want to multiply, you simply do the multiplication the same as with decimal numbers, except that you have to add the carries in binary:
1011001
x1101011
-------
1011001
1011001.
0000000..
1011001...
0000000....
1011001.....
1011001......
--------------
10010100110011
w-bit words aren't anything by themselves. Assuming that the value of w has been previously defined in the context in which "w-bit word" is used, then it simply means a word that is composed of w bits. For instance:
A version of RC6 is more accurately specified as RC6-w/r/b where the word size
is "w" bits, encryption consists of a nonnegative number of rounds "r," and
"b" denotes the length of the encryption key in bytes. Since the AES
submission is targetted at w=32, and r=20, we shall use RC6 as shorthand to
refers to such versions.
So in the context of that document, a "w-bit word" is just a 32-bit value.
As for your multiplication, I'm not sure what you are asking. Google confirms the result as correct:
1011001 * 1101011 = 10010100110011
I am using bloom filters to check for duplicated data in a set. However, there is a need to combine the results of two sets of data into a single filter to check for duplication across the two sets. I devised a function in pseudo-Python to perform this task:
def combine(a : bloom_filter, b : bloom_filter):
assert a.length == b.length
assert a.hashes == b.hashes
c = new bloom_filter(length = a.length, hashes = b.hashes)
c.attempts = a.attempts + b.attempts
c.bits = a.bits | b.bits
# Determining the amount of items
a_and_b = count(a & b)
a_not_b = count(a & !b)
not_a_b = count(!a & b)
neither = count(!a & !b)
c.item_count = a_not_b / a.length * a.item_count
+ not_a_b / b.length * b.item_count
+ a_and_b / c.length * min(a.item_count, b.item_count)
return c
Does this even sound correct? I am having considerable internal debate as to whether is is even possible to do what I intend, since much of the information about the source data is lost (which is the point of a bloom filter).
You can derive a formula for estimating the amount of items a Bloom Filter:
c = log(z / N) / ((h * log(1 - 1 / N))
N: Number of bits in the bit vector
h: Number of hashes
z: Number of zero bits in the bit vector
This provides a fairly accurate estimate of the number of items in the Bloom Filter. You can come up with an estimate for contribution with simple subtraction.
It could be possible..... sort of..
lets say set A contains apples and oranges
lets say set B contains peas and carrots
construct a simple 16 bit bloom filter as an example and CRC32 as the hash
crc32(apples) = 0x70CCB02F
crc32(oranges) = 0x45CDF3B4
crc32(peas) = 0xB18D0C2B
crc32(carrots) = 0x676A9E28
Start w/ empty bloom filter (BF) (say 16 bits) for both sets (A, B)
BFA = BFB = 0000 0000 0000 0000
then, breaking the hash into some bit length, we'll use 4 here
we can add apples to the BF.
e.g.
Get Apples BF Index list by splitting up the hash:
0x70CCB02F = 0111 0000 1100 1100 1011 0000 0010 1111
7 0 C C B 0 2 F
----------------------------------------------------
Add Apples to BFA by setting BF bit indexes [ 7, 0, 12, 12, 11, 0, 2, 15]
(set the index bit of an empty BF to 1)
Apples = 1001 1000 1000 0101 (<- see indexes 0,2,7,11,12,15 are set)
BF = 0000 0000 0000 0000 (or operation adds that item to the BF)
================================
Updated BFA = 1001 1000 1000 0101
Add Oranges to BF same way:
0x45CDF3B4 = 0100 0101 1100 1101 1111 0011 1011 0100
4 5 12 13 15 3 11 4
----------------------------------------------------
Add oranges to BF by setting BF bit indexes [ 4,5,12,13,15,3,11,4]
Oranges = 1011 1000 0011 1000
BFA = 1001 1000 1000 0101 (or operation)
================================
Updated BFA = 1011 1000 1011 1101
So now apples and oranges are inserted into BF1
w/ Final Value of 1011 1000 1011 1101
Do the same for BFB
crc32(peas) = 0xB18D0C2B becomes =>
set [11,2,12,0,13,1,8] in BFB
0011 1001 0000 0011 = BF(peas)
crc32(carrots) = 0x676A9E28 becomes =>
set [8,2,14,9,10,6,7] in BFB
0100 0111 1100 0100 = BF(carrots)
so BFB =
0011 1001 0000 0011 BF(peas)
0100 0111 1100 0100 BF(carrots)
=================== ('add' them to BFB via locial or op)
0111 1111 1100 0111
you could now search B for A entries in a loop and vice verse:
Does B contain "oranges" =>
1011 1000 0011 1000 (Oranges BF representation)
0111 1111 1100 0111 (BFB)
===================== (and operation)
0011 1000 0000 0000
Because this result (0011 1000 0000 0000) doesn't match the
Original BF of Oranges, you can be certain that B doesn't contain any oranges
... ... (do for rest of items)
and following, B doesn't contain any of A items,
just as B doesn't contain any of the apples.
I don't think that's what you asked though, and looks like you could computer a difference
BF, which is more to your point. Seems like you could do a xor op and that would give you a 'single' array containing both differences:
0111 1111 1100 0111 (BFB)
1011 1000 1011 1101 (BFA)
========================
1100 0111 0111 1010 (BFA xor BFB) == (items in B not in A, and items in A not in B)
meaning with this single BF, you could detect the non-existance of an item 100% of the time,
just not the existance of the item 100%.
The way you would use it, is as follows (check if peas is 'missing from A):
1100 0111 0111 1010 (BFA xor BFB)
0011 1001 0000 0011 (Peas)
============================== (And operation)
0000 0001 0000 0010 (non-zero)
since (BFA xor BFB) && (Peas) != 0 you know one set does not contain 'peas'...
again, you'd be testing for item by item, maybe you could do aggregation but probably not a good idea...
Hope this helps!
just a quick question , your code does add up bits to numbers which are higher than 2 which is binary's limit ,for instance suppose n1 = 1111 and n2 is the same , then your code will show the result of 1234321 , though its not a valid binary number , How should we make the result be in binary ? thanks
In Java you can do the following to get output in binary
int i1 = 1111;
int i2 = 1111;
int result = i1 * 12;
System.out.println("result in binary " + Integer.toBinaryString(result));
The algorithm is the same as with decimal numbers, like you learned in school. You carry the overflow. But really, that has nothing to do with multiplication. That's just addition. For instance, 1111 x 1111 = 1111 + 11110 + 111100 + 1111000.
You are msisunderstanding binary math. 1111 is not a binary, anyway not the 1111 which can be multipled by 1111 and results 1234321.
a binary 1111 would be 15 in Decimal. try using the windoes Calc to change between Dec. and Bin.
[1111 (Dec) = 10001010111 (Bin)
1111 (Bin) = 15 (Dec)
1234321 (Dec) = 100101101010110010001 (Bin)
1234321 (bin) is invlid][1]
Anyway you will need to go through the binary Math in order to understand how this work.
Try this link and see how multiplication works