I need help to calculate Processor Affinity value
0 (0000) Not allowed (that would mean use no processors)
1 (0001) Use processor 1
2 (0010) Use processor 2
3 (0011) Use both processors 1 and 2
4 (0100) Use processor 3
5 (0101) Use both processors 1 and 3
6 (0110) Use both processors 2 and 3
7 (0111) Use processors 1,2 and 3
8 (1000) Use processor 4
With 1, 2, 3 and result is 7. I wonder what formula is?
It seems to be a simple 4-digit binary number.
A 1 at the right-most position means 1, a 1 at the second position from the right means 2, at the 3rd it means 4 and at the 4th position from right (i.e. the first digit from left) it means 8. The total value is simply the sum of all those positions.
The basic idea (in pseudo-code, because we can't format formulas correctly here is):
totalValue
for every digit at position i (counted from the right, starting with 0)
totalValue = totalValue + 2^i*(digit at position i)
For example 3 (0011) the value is 0x2^3 + 0x2^2 + 1*2^1 + 1*2^0 = 0 + 0 + 2 + 1 = 3
For example 4 (0100) the value is 0x2^3 + 1x2^2 + 0*2^1 + 0*2^0 = 0 + 4 + 0 + 0 = 4
Processor_Affinity := Use_processor_1 + Use_processor_2 + Use_processor_3
So 1010; interpret it as:
0 at 1st position as OFF
1 at 2nd position as ON
0 at 3rd position as OFF
1 at 4th position as ON
Related
Like the documentation stated 'When nInputDim is provided, inputs larger than that value will be considered batches where the actual dim to be padded will be dimension dim + 1.'
My understanding is the inputs dimensional larger than the provided nInputDim, the dimension dim will become dim + 1, but why is it ?
By the way, I think the doc you mentioned should be this link.
Let's suppose you want to make 3 default zero padding at the end of 1(first) dim, so you will make a padding module like below:
require 'nn';
dim = 1
pad = 3
module = nn.Padding(dim, pad)
given_tensor = torch.ones(4, 2)
print(given_tensor)
res_tensor = module:forward(given_tensor)
print(res_tensor)
If you run these lines in torch interpreter, you will get result like below, you add 3 paddings at 1(first) dim successfully as you transform 4x2 tensor to 7x2 tensor.
1 1
1 1
1 1
1 1
[torch.DoubleTensor of size 4x2]
1 1
1 1
1 1
1 1
0 0
0 0
0 0
[torch.DoubleTensor of size 7x2]
What happen if you specify nInputDim to 1 as below?
require 'nn';
dim = 1
pad = 3
nInputDim = 1
module = nn.Padding(dim, pad, nInputDim)
given_tensor = torch.ones(4, 2)
print(given_tensor)
res_tensor = module:forward(given_tensor)
print(res_tensor)
if you run them, you will get result like below
1 1
1 1
1 1
1 1
[torch.DoubleTensor of size 4x2]
1 1 0 0 0
1 1 0 0 0
1 1 0 0 0
1 1 0 0 0
[torch.DoubleTensor of size 4x5]
You want nInputDim to be 1, but your input Dim is 2, It will take first dimension, 4, as batch size and make 3 padding to every item in the batch, it makes 4 size of 2 tensors to 4 size of 5 tensors. It works as if you make 3 padding to 2(dim = dim + 1, second) dim of tensor 4x2, which will output the same result, 4x5.
Please consider the following code snippet from a SQL Query:
WHERE TableType_ti = 1
AND TableID_int MOD 2 = 0
AND TaskScheduled_dt < NOW()
I don't understand, what does the line AND TableID_int MOD 2 = 0 is actually doing? If I have understood correctly, TableID_int MOD 2 value is getting evalueted first and then it is compared with 0 .
Please let me know if I am wrong.
Thanks
The modulus operator returns the remainder when two integers are divided by each other. So:
5 mod 2 = 1
9 mod 3 = 0
10 mod 6 = 4
When you take an integer mod 2, you are testing for whether it is even or odd. Even is 0 and odd is 1.
Using 8 bit registers and signed magnitude representation.
I thought 25 in BCD is 010 0101 but my text book says it as 001 1001. Can somebody explain?
25 / 2 = 12r1 (12 with a remainder of 1)
12 / 2 = 6r0 (6 with a remainder of 0)
6 / 2 = 3r0 (3 with a remainder of 0)
3 / 2 = 1r1 (1 with a remainder of 0)
1 / 2 = 0r1 (0 with a remainder of 0)
So 11001 (working backward up the tree) is the binary equivalent to 25.
Another way to think about it is with powers of 2:
(1*16) + (1*8) + (0*4) + (0*2) + (1*1) = 25
And it's worth noting, just as in base 10, leading zeros do not change the value of a number. (00025 == 25) (0011001 == 11001).
The leading zeros are there in your case because your needing to populate an 8 bit register (there needs to be 8 binary digits regardless of their value).
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
How can I do division by 2 in Binary Signed digit (Redundant Binary representation) ? Shifting won't work right ?
A redundant binary representation is just an expression of the form:
\sum_{i=0}^n d_i 2^n
where the d_i's are drawn from a larger set than just {0,1}.
Dividing by two or shifting right takes that to
\sum_{i=0}^{n-1} d_{i+1} 2^n + f(d_0)
The trick comes in how to deal with adjusting for the redundant representation for d_0.
If your RBR has digits the form {0,1,2} and has a 2 for the least significant digit you will then have to add 1 to the result to compensate, so f(0) = 0, f(1) = 0, f(2) = 1 should work.
4 = 12_base2, so 12_base2 >> 1 = 1 + f(2) = 1 + 1 = 2_base2 = 2 as expected.
6 = 102_base2, so 102_base2 >> 1 = 10_base2 + f(2) = 11_base2 = 3
You can get something similar for signed redundant binary representations (i.e. with d_i in {-1,0,1}) by setting f(-1) = -1.
1 = 1(-1)_base2, so 1(-1)_base2 >> 1 = 1 + f(-1) = 1 - 1 = 0
So ultimately the naive approach of just shifting does work, you just need a fudge factor to account for any redundant encoding of the shifted digits.
If your chosen RBR includes more options, you'll need to adjust the fudge factor accordingly.