logical calculation using &, ~ in sybase - logic

I am executing the below statements.
SELECT 10 & ~3 . this gives the output as 8
SELECT 10 & ~5 . this gives the output as 10
SELECT 10 & ~2 . this gives the output as 8
Can anyone explain the logic behind this?

this is bitwise operations, and ~ is inverse.
3 is the same as 0011 in binary, and inverse of that is 1100
2 is the same as 0010 in binary, and inverse of that is 1101
5 is the same as 0101 in binary, and inverse of that is 1010
10 is the same as 1010 in binary.
10 & ~3 => 1010 & 1100 = 1000 => 8
10 & ~5 => 1010 & 1010 = 1010 => 10
10 & ~2 => 1010 & 1101 = 1000 => 8
bitwise is bit for bit
you can think in decimal as well, but you have to have your mindset in binary as well (sequence 1, 2, 4, 8, 16, 32, 64, 128...). 10 consist of "8 | 2" and 3 consist of "1 | 2". Inverse of 3 is all but "1 | 2". Common part between 10 and 3 is 2 so you will have all parts from 10 that is not in 3, thus giving us 8.

Related

Is there an algorithm to find the shortest binary representation for every entry within a given range?

I have an encoding scheme, but I don't know the name of it. I know there must be an algorithm to encode/decode integers into this binary scheme. The scheme is as follows:
1 2 3 4 5 6 7 8 9 etc.
0 - 0 0 00 00 00 00 000 000
1 1 10 01 01 01 010 001 001
2 11 10 10 100 011 010 010
3 11 110 101 100 011 011
4 111 110 101 100 100
5 111 110 101 101
6 111 110 110
7 111 1110
8 1111
etc.
Example:
When you have a range of 6 integers (0 to 5) you can use column 6. With this you can save a bit on the numbers 0 and 1. When using column 9, you will save a bit on every number except on 7 and 8.
The 'you will save a bit' is opposed to using 2, 3, 4, or N bit words.
I tried to Google this, but I can't find the right search keywords. Could someone point me in the right direction?
Thanks!
This appears to be Huffman Encoding with assumed uniform distribution across all values in any given range.
So for instance, the 5th column is just a huffman encoding for the character set [0-5] (inclusive), which assumes all 6 numbers are of equal probability to occur.

Hashing binary numbers with don't care bits

How can I find out if a binary number is contained in a set, where it is possible that an element of the set has don’t care bits?
I thought about using hash table, but there is a need to duplicate the numbers with don’t care bits in the hash table in order to cover all the possibilities.
For example:
The set of numbers is:
0 00x1
1 10xx
2 110x
3 1010
4 11x1
5 0010
and the number is 0011, the result should be 0.
If number of digits of binary number are limited then you can duplicate those don't care bits and convert the binary numbers to integers then use these integers as keys for map and other as values.
Example
0 00x1
1 10xx
can be converted to
0001 0
0011 0
1000 1
1001 1
1010 1
1011 1
and saved as
i j
1 0
3 0
8 1
9 1
10 1
11 1
where i is the key and j is the value
Let's say you have the binary number 1xxx, that would match 8 numbers. So, do not go with duplicating for each option.
You have to keep the "do not care" bits somewhere. Use another number for this, set the "do not care" bits to 1. If we go over your example:
i x y
0 00x1 0010
1 10xx 0011
2 110x 0001
3 1010 0000
4 11x1 0010
5 0010 0000
And you need to decide what to use for x, 0 or 1. You can use any of them, once you keep the information in the second number it does not matter.
Now use bitwise operations:
if ((n ^ x[i]) | y[i]) == y[i] then match
This solution is based on checking the existence of any non-matching bits except do-not-care bits. (n xor x[i]) gives the non-matching bits, then or'ing it with y[i] should not be different than y[i].
If we go over your example, and assuming you choose 0 for x, the check becomes
i:0 -->> ((0011 ^ 0001) | 0010) == 0010 -->> match!
i:1 -->> ((0011 ^ 1000) | 0011) != 0011 -->> no match!
i:2 -->> ((0011 ^ 1100) | 0001) != 0001 -->> no match!
i:3 -->> ((0011 ^ 1010) | 0000) != 0001 -->> no match!
i:4 -->> ((0011 ^ 1101) | 0010) != 0001 -->> no match!
i:5 -->> ((0011 ^ 0010) | 0000) != 0000 -->> no match!

Understanding XOR logical operator

I don't understand this
2.0.0p247 :616 > 5 ^ 2
=> 7
2.0.0p247 :617 > 5 ^ 1
=> 4
What 7 and 4 means in those scenarios?
I try reading here http://en.wikipedia.org/wiki/Exclusive_disjunction but cannot figure out by looking into the diagrams what is the subtract here. Sorry if this is simple math question.
It has to do with the binary representation of the values.
5 = 0101
2 = 0010
1 = 0001
Now the XOR works like this:
0 ^ 0 = 0
0 ^ 1 = 1
1 ^ 0 = 1
1 ^ 1 = 0
so to compute 5 ^ 2, let's apply the ^ operation to each column:
0101 (this is 5)
0010 (this is 2)
----
0111 ==> which is the binary representation of 7
How did this work? In the leftmost column, we computed 0^0=0. In the second column, 1^0=1. In the third column 0^1=1, and so on.
and 5 ^ 1
0101 (this is 5)
0001 (this is 1)
----
0100 ==> which is the binary represenation of 4

What does & do in ruby (between integers)

I would like to know what & does in the use case:
7 & 3
=> 3
8 & 3
=> 0
Or as seen in the general use case:
Integer & Integer
=> ??
I know that array & array2 gives the intersection between the two arrays, but I am unsure of exactly what is going on here when used with integers.
& is bitwise AND which examines the two operands bit-by-bit and sets each result bit to 1 if both the corresponding input bits are 1, and 0 otherwise. You can also think of it as bit-by-bit multiplication.
111 (7)
AND 011 (3)
------------
= 011 (3)
1000 (8)
AND 0011 (3)
------------
= 0000 (0)

Length values from deflate algorithm

I compressed the text "TestingTesting" and the hex result was: 0B 49 2D 2E C9 CC 4B 0F 81 50 00. I can't figure out the length and distance codes. The binary below is reversed because the RFC says to read the bits from right to left (thanks Matthew Slattery for the help). Here is what was parsed so far:
1 BFINAL (last block)
01 BTYPE (static)
1000 0100 132-48= 84 T
1001 0101 149-48= 101 e
1010 0011 163-48= 115 s
1010 0100 164-48= 116 t
1001 1001 153-48= 105 i
1001 1110 158-48= 110 n
1001 0111 151-48= 103 g
These are the remaining bits that I don't know how to parse:
1000 0100 0000 1000 0101 0000 0000 0
The final 10 bits (end of block value is x100) is the only part I can parse. I think the length and distance values should be 7 (binary 0111) since the length of "Testing" is 7 letters, and it gets copied 7 characters after the current position, but I can't figure out how its representing this in the remaining bits. What am I doing wrong?
The distance code is 5, but a distance code of 5 is followed by one "extra bit" to indicate an actual distance of either 7 or 8. (See the second table in paragraph 3.2.5 of the RFC.)
The complete decoding of the data is:
1 BFINAL
01 BTYPE=static
10000100 'T'
10010101 'e'
10100011 's'
10100100 't'
10011001 'i'
10011110 'n'
10010111 'g'
10000100 another 'T'
0000100 literal/length code 260 = length 6
00101 distance code 5
0 extra bit => the distance is 7
0000000 literal/length code 256 = end of block

Resources