I've a list with 10 values (bytes, hex). The list is converted to decimal:
09 04 5A 14 4F 7D
to
9 4 90 20 79 125
After that. There is a method (parameter: List<Byte> byteList). Can anybody explain me the following code in that method:
"Test:" + ((((UInt16)byteList[(Int32)index] & 0x40) << 1) >> 7):
Especially & 0x40 and << 1 and >> 7
0x40 is hex 40 - aka 64 in decimal, or 01000000 in binary. & is bitwise "and", so {expr} & 0x40 means "take just the 7th bit". << is left shift, and >> is right shift. So this:
takes the 7th bit
left shifts 1
right shifts 7
leaving the 7th bit in the LSB position, so the final value will be either 0 (if the 7th bit wasn't set) or 1 (if the 7th bit was set)
frankly, it would be easier to just >> 6, or to just compare against 0. Likewise, casting to short (UInt16) is not useful here.
If I wanted to test the 7th bit, I would just have done:
bool isSet = (byteList[(int)index] & 0x40) != 0;
This is a test to verify if 7th bit of value is set. Result will be 1 if bit is set, and 0 if not.
Related
Im rewriting matlab code to C#. I have no idea about programming in matlab and I can't understand this part:
d9=[d9 d8];
d10=d9(:,2:10);
d5=[d6 d10 d7];
Variables d6, d7, d8 and d9 are 2-dimensional arrays.
Full Matlab code is here: link to codeforge.com
"I have no idea about programming in matlab and I can't understand this part"
a) d9=[d9 d8];
will concatenate the matrix d9 and d8 and store result in d9. Other way is that it just append matrix d8 to d9
Example :
>> a=[1 2;3 4]
a =
1 2
3 4
>> b=[5 6;7 8]
b =
5 6
7 8
>> a=[a b]
a =
1 2 5 6
3 4 7 8
b) d10=d9(:,2:10);
: is colon operator extensively used for vector manipulation, sub-scripting and creating for loops iterator
Here,
second subscript 2:10 means the columns number 2 3 4...10 in d9
first subscript : all rows in d10
So d10 is assigned by all elements in column 2 to 10 from all rows of d9.
Example :
>> c=a(:,2:4)
c =
2 5 6
4 7 8
c) d5=[d6 d10 d7];
Again similar to first one, concatenates matrices d6 d10 and d7 and assign the result to d5.
not yet able to comment directly under an answer but I think there is a typo in P0W's answer.
It should state:
" first subscript : all rows in d9 " (emphasis added) instead of " first subscript : all rows in d10 "
The rest of the answer is correct but just in case it confuses somebody unfamiliar with Matlab...
I want to know if one needs to mask a number before retrieving the value stored at a certain byte when doing bit shifting.
Take, for example, this code:
short b1 = 1;
short b2 = 2;
short b0 = (short)((b1 << 8) | b2); //store two values in one variable
Console.WriteLine(b0); //b1 and b2 combined
Console.WriteLine((b0 & (255 << 8)) >> 8); //gets the value of b1
As far as I am concerned, doing a right shift drops all bits that are less than the number of bits you've shifted. Therefore, right shifting b0 by 8 bits will drop the 8 bits of b2, leaving just b1.
Console.WriteLine(b0 >> 8); //this also gets b1!!
I want to find out, is there any need to mask b0 with 255 << 8 before shifting to get the value of b1?
NB:
The only need I can think of for masking before retrieving a value is if there is something else stored at a higher byte, such as trying to get back the value of b2, in which this code would be used:
Console.WriteLine(b0 & 255); //gets the value of b2
I want to find out, is there any need to mask b0 with 255 << 8 before shifting to get the value of b1?
No, there's no need. So the compiler will omit the masking. Some people think it makes the code easier to understand or protects them against some imagined failure scenario. It's completely harmless.
This code:
BitArray bits = new BitArray(new byte[] { 7 });
foreach (bool bit in bits)
{
Console.WriteLine(bit ? 1 : 0);
}
Gives me the following output:
11100000
Shouldn't it be the other way around? Like this:
00000111
I am aware that there is little and big endian, although those terms only refer to the position of bytes. As far as I know, they don't affect bits.
The documentation for BitArray states:
The first byte in the array represents bits 0 through 7, the second
byte represents bits 8 through 15, and so on. The Least Significant
Bit of each byte represents the lowest index value: " bytes [0] & 1"
represents bit 0, " bytes [0] & 2" represents bit 1, " bytes [0] & 4"
represents bit 2, and so on.
When indexing bits, the convention is to start at the least significant end, which is the right side when written in binary notation. However, when enumerating the array, you start at index 0, so they are printed out left-to-right instead of right-to-left. That's why it looks backwards.
For example, the word 01011010 00101101 (90 45) would be indexed as:
0 1 0 1 1 0 1 0 - 0 0 1 0 1 1 0 1
----------------------- -----------------------
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
And you would pass it to the constructor as new byte[] { 45, 90 } since you pass it least-significant first. When printed out, it would display in index order as: 1011010001011010, which is the reverse of the original binary notation.
The documentation is not explicit about it, but I guess the iterator iterates from the LSB to the MSB. Sound reasonable to me (personally!), unless you are printing out the bits. I had a look at BitArray.GetEnumerator Method.
No it's a bit array, not a numeric value represented as bits.
It's just like any regular array with some methods added for bit operations. Just like if you had an array of int. You wouldn't expect it to be in the reverse order, it just takes it position by position.
Eg:
Numbers (in a byte) converted to a BitArray would come out like:
2 = 01000000
5 = 10100000
8 = 00010000
etc.
It just stores the position of the value but not relative as you would except from a binary numeric value.
Here is a link describing the constructor you are using:
http://msdn.microsoft.com/en-us/library/b3d1dwck.aspx
The key point is:
The number in the first values array element represents bits 0 through
31, the second number in the array represents bits 32 through 63, and
so on. The Least Significant Bit of each integer represents the lowest
index value: " values [0] & 1" represents bit 0, " values [0] & 2"
represents bit 1, " values [0] & 4" represents bit 2, and so on.
Hey, I'm self-learning about bitwise, and I saw somewhere in the internet that arithmetic shift (>>) by one halfs a number. I wanted to test it:
44 >> 1 returns 22, ok
22 >> 1 returns 11, ok
11 >> 1 returns 5, and not 5.5, why?
Another Example:
255 >> 1 returns 127
127 >> 1 returns 63 and not 63.5, why?
Thanks.
The bit shift operator doesn't actually divide by 2. Instead, it moves the bits of the number to the right by the number of positions given on the right hand side. For example:
00101100 = 44
00010110 = 44 >> 1 = 22
Notice how the bits in the second line are the same as the line above, merely
shifted one place to the right. Now look at the second example:
00001011 = 11
00000101 = 11 >> 1 = 5
This is exactly the same operation as before. However, the result of 5 is due to the fact that the last bit is shifted to the right and disappears, creating the result 5. Because of this behavior, the right-shift operator will generally be equivalent to dividing by two and then throwing away any remainder or decimal portion.
11 in binary is 1011
11 >> 1
means you shift your binary representation to the right by one step.
1011 >> 1 = 101
Then you have 101 in binary which is 1*1 + 0*2 + 1*4 = 5.
If you had done 11 >> 2 you would have as a result 10 in binary i.e. 2 (1*2 + 0*1).
Shifting by 1 to the right transforms sum(A_i*2^i) [i=0..n] in sum(A_(i+1)*2^i) [i=0..n-1]
that's why if your number is even (i.e. A_0 = 0) it is divided by two. (sorry for the customised LateX syntax... :))
Binary has no concept of decimal numbers. It's returning the truncated (int) value.
11 = 1011 in binary. Shift to the right and you have 101, which is 5 in decimal.
Bit shifting is the same as division or multiplication by 2^n. In integer arithmetics the result gets rounded towards zero to an integer. In floating-point arithmetics bit shifting is not permitted.
Internally bit shifting, well, shifts bits, and the rounding simply means bits that fall off an edge simply getting removed (not that it would actually calculate the precise value and then round it). The new bits that appear on the opposite edge are always zeroes for the right hand side and for positive values. For negative values, one bits are appended on the left hand side, so that the value stays negative (see how two's complement works) and the arithmetic definition that I used still holds true.
In most statically-typed languages, the return type of the operation is e.g. "int". This precludes a fractional result, much like integer division.
(There are better answers about what's 'under the hood', but you don't need to understand those to grok the basics of the type system.)
I need to come up with a way to unpack a date into a readable format. unfortunately I don't completely understand the original process/code that was used.
Per information that was forwarded to me the date was packed using custom C/Python code as follows;
date = year << 20;
date |= month << 16;
date |= day << 11;
date |= hour << 6;
date |= minute;
For example, a recent packed date is 2107224749 which equates to Tuesday Sept. 22 2009 10:45am
I understand....or at least I am pretty sure....the << is shifting the bits but I am not sure what the "|" accomplishes.
Also, in order to unpack the code the notes read as follows;
year = (date & 0xfff00000) >> 20;
month = (date & 0x000f0000) >> 16;
day = (date & 0x0000f800) >> 11;
hour = (date & 0x000007c0) >> 6;
minute = (date & 0x0000003f);
Ultimately, what I need to do is perform the unpack and convert to readable format using either JavaScript or ASP but I need to better understand the process above in order to develop a solution.
Any help, hints, tips, pointers, ideas, etc. would be greatly appreciated.
The pipe (|) is bitwise or, it is used to combine the bits into a single value.
The extraction looks straight-forward, except I would recommend shifting first, and masking then. This keeps the constant used for the mask as small as possible, which is easier to manage (and can possibly be a tad more efficient, although for this case that hardly matters).
Looking at the masks used written in binary reveals how many bits are used for each field:
0xfff00000 has 12 bits set, so 12 bits are used for the year
0x000f0000 has 4 bits set, for the month
0x0000f800 has 5 bits set, for the day
0x000007c0 has 5 bits set, for the hour
0x0000003f has 6 bits set, for the minute
The idea is exactly what you said. Performing "<<" just shifts the bits to the left.
What the | (bitwise or) is accomplishing is basically adding more bits to the number, but without overwriting what was already there.
A demonstration of this principle might help.
Let's say we have a byte (8 bits), and we have two numbers that are each 4 bits, which we want to "put together" to make a byte. Assume the numbers are, in binary, 1010, and 1011. So we want to end up with the byte: 10101011.
Now, how do we do this? Assume we have a byte b, which is initialized to 0.
If we take the first number we want to add, 1010, and shift it by 4 bits, we get the number 10100000 (the shift adds bytes to the right of the number).
If we do: b = (1010 << 4), b will have the value 10100000.
But now, we want to add the 4 more bits (0011), without touching the previous bits. To do this, we can use |. This is because the | operator "ignores" anything in our number which is zero. So when we do:
10100000 (b's current value)
|
00001011 (the number we want to add)
We get:
10101011 (the first four numbers are copied from the first number,
the other four numbers copied from the second number).
Note: This answer came out a little long, I'm wikiing this, so, if anyone here has a better idea how to explain it, I'd appreciate your help.
These links might help:
http://www.gamedev.net/reference/articles/article1563.asp
http://compsci.ca/v3/viewtopic.php?t=9893
In the decode section & is bit wise and the 0xfff00000 is a hexadecimal bit mask. Basically each character in the bit mask represents 4 bits of the number. 0 being 0000 in binary and f being 1111 so if you look at the operation in binary you are anding 1111 1111 1111 0000 0000 ... with whatever is in date so basically you are getting the upper three nibbles(half bytes) and shifting them down so that 00A00000 gives you 10(A in hex) for the year.
Also note that |= is like += it is bit wise or then assignment rolled in to one.
Just to add some practical tips:
minute = value & ((1 << 6)-1);
hour = (value >> 6) & ((1<<5)-1); // 5 == 11-6 == bits reserved for hour
...
1 << 5 creates a bit at position 5 (i.e. 32=00100000b),
(1<<5)-1 cretaes a bit mask where the 5 lowest bits are set (i.e. 31 == 00011111b)
x & ((1<<5)-1) does a bitwise 'and' preserving only the bits set in the lowest five bits, extracting the original hour value.
Yes the << shifts bits and the | is the bitwise OR operator.