Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I got this code somewhere from the internet
final int time = 80 << 3 + 1;
<< is a left shift operator
The signed left shift operator "<<" shifts a bit pattern to the left,
and the signed right shift operator ">>" shifts a bit pattern to the
right. The bit pattern is given by the left-hand operand, and the
number of positions to shift by the right-hand operand.
So 24 << 8 means shift binary value of 24 towards left by 8 bits position.
Follow reference to learn more about it.
24 << 8 means shifting the number 24 to the left for 8 bits, which is equivalent to 24 * (2^8) = 6144.
In the provided code snippet, it encodes a time hh:mm into an integer hh << 8 + mm.
Since there are 24 hours in one day, the array to represent the activity of every minute in one day requires (24 << 8) + 1 elements. The +1 is to make the array index for 24:00 legal.
It means bit-shift the constant integer value 24 left by 8 bits.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 10 months ago.
Improve this question
To find all the prime factors of a number we traverse from 2 to sqrt(number). What makes all the prime factors accommodated within sqrt(number)?
If you express a number as z = x*y, either x or y has to be <=sqrt(z), otherwise the product becomes greater than z
For all (x,y) pairs such that z = x*y, if you traverse x between [2, sqrt(z)], you can cover all y by getting z/x
"What makes all the prime factors accommodated within sqrt(number)". This fact is wrong, a simple counter example is 7 for 28. By using the first two points however, when you test the divisibility of 4 (which is <=sqrt(28)), you get 7 by doing 28/4
Suppose c = a * b. If a | c, then b | c i.e. (c / a) | c.
We leverage this fact to reduce the time complexity to find all the factors of a number.
For example, take the number 12.
Square root of 12 is 3.46 approximately.
1 and 12 (the number itself) are already factors.
So we can iterate from 2 until 3.
Since 12 % 2 is 0, 2 is a factor and 12 / 2 = 6 is also a factor.
12 % 3 is 0, so 3 is a factor and 12 / 3 = 4 is also a factor.
This way, we have found all the factors.
In a sense, we iterate till the multiplicative middle point which lies at the square root for a single number and leverage the above property.
To find all prime factors, we must iterate over prime numbers from 2 until square root of the number.
Suppose I have two signed binary which is:
A: 1100
B: 1000
And I want to subtract B from A.
After 2's complementing B, this would be:
1100 + 1000 = '1'0100
I thought that there would be an overflow from this because the sign for A and B is negative while the answer is positive, but my worksheet answer key says otherwise.
My question is, will the overflow be 1 or is the answer key mistaken?
There's no overflow in this computation.
1100 is -4 decimal.
1000 is -8 decimal.
-4 - (-8) = 4
So the result is 0100, without any overflow. (All the values involved are representable as signed-4-bit, which covers the range -8 to 7 inclusive.)
Note that subtraction never overflows (neither overflow, nor underflow) if the operands have the same sign, which is the case here.
It appears you're confusing the extra bit at the end of the addition with determining whether overflow happened. This simply isn't the case in general; for each operation there are different rules to determine if an overflow/underflow happened. Here's a good paper to read, which details the exact conditions under which underflow/overflow occurs for signed and unsigned binary arithmetic of bit-vectors: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/z3prefix.pdf
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 3 years ago.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Improve this question
I want to convert number -0.25. So 0.25 (for 4 bit int and 4 bit frac) equals to:
0000_0100
For negative number -1 answer is
1111
But what is -0.25? How can I convert this negative number with a fraction in 2's complement?
To answer this question, I need to clarify that the numbers are represented in a fixed-point. Almost all logic nowadays uses two's complement. Therefore, in the two's complement version negative numbers are considered for example:
signed 4'b1100 = -4 (-1*2^3 + 1*2^2 + 0*2^1 + 0*2^0).
Number for example 0.25 in fixed-point binary will be represented:
8'b0000_0100 (int 4 bit is zeros and frac 4 bit -> 0*2^-1 + 1*2^-2 + 0*2^-3 + 0*2^-4).
Other way to calculate can be multiply the number to integer find negative and then divide this number (remember, that multiplication on 2 is shift to the right, and division on 2 is shift to the left).
For my example -0.25 would be as follows:
-0.25*2*2= -1.
-1 = 4'b1111.
shift 2*2 to left = 4'b11_11 = -0.25.
Or we can calculate: -1*2^1 + 1*2^0 + 0*2^-1 + 1*2^-2.
1 in MSB is signed bit. We must remember this when operate with signed logic.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
for my computer science class I need to finish a project where I desperately need to understand logic of one´s complement and two´s complement. I already know how to construct these and also how hardware adder works when dealing with two´s complement. The thing that is bothering me and I need help with is the logic behind one´s complement addition. Why do we have to add the bit we would carry over (and discard when using two complement coding) to the sum to get the correct result? I don´t understand why binary addition behaves like this when adding one´s complement and why is that last adding of carry over bit so crucial. I need to understand the logic behind it. Thanks
A 1's complement number (say,16 bits) can be described as below - in terms of the relationship between the binary code c (which is 0..0xFFFF, or 0..65535) and the 'value' x which the code represents, x is in range -32767.. 32767.
if the value x is 0..32767, the code c is numerically equal to x, and thus has a zero in the MSB
if the value x is negative, -1 .. -32767, then c is 65535 - x, and the MSB of c is 1.
The code c=65535 = 0xFFFF is to be interpreted as zero; since it has a 1 in the MSB I will call it '-0'.
Now consider what happens to the x values when you add two codes using a a binary adder:
If both x1, x2 are positive, the adder adds the codes: c = c1 + c2. both MSBs are zero at the input, so there will be no carry. So the value of c will be the sum x1+ x2 and this is how it will be interpreted (assuming the sum doesn't overflow into the MSB).
If both x1, x2 are negative, then by adding c1+c2 you are adding (65535+x1)+(65535+x2). There will always be a carry-out; by discarding this you end up with a binary value equal to 65534+(x1+x2). To get the code we want to represent this negative sum, i.e. 65535+(x1+x2), we need to add 1 more.
If the signs are different, the sum of codes is 65535+(x1+x2). There may or may not be a carry-out. Since the MSBs are different, the carry-out occurs if, and only if, the MSB of the sum is zero. In the case where the true sum (x1+x2) < 0, you won't have a carry-out, and the value 65535+(x1+x2) is the proper code for (x1+x2). If the sum (x1+x2)>0, there will be a carry-out; the sum of the codes (after discarding the carry out) will be (x1+x2)-1, and thus you have to add 1 to get the proper code (x1+x2).
So, looking at all the cases, it works out that whenever a carry-out occurs, (and you effectively subtract 65536 by discarding it) you need to add 1 to get the proper code to represent the sum.
When x1+x2 = 0 -- with one <0 and the other >0 - the sum of codes will always be 65535, which is left as is and is to be interpreted as zero ("-0").
When both are zero, you have three cases:
0 + 0 = 0 Fairly simple...
-0 + -0: codes are 0xFFFF + 0xFFFF = (carry+ 0xFFFE) = 0xFFFF after adding carry back in, interpreted as -0.
-0+ 0: codes are 0xFFFF + 0 = 0xFFFF (-0)
So the only case where the 1's complement sum is a 'proper' 0 is when both inputs are proper 0. All other cases adding up to zero give a '-0'.
Mathematically, you could say that 1's complement uses (c = x) mod 65535, with c constrained to 0...0xFFFF. And so the addition needs to be done modulo 65535. Each time you have a carryout, you subtract 65536 (by discarding it from the top) and add 1 (by adding it at the bottom); since you subtract 65535 in the process, the modulo 65535 value is preserved.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
Ok right now I'm storing lat and lng columns as DECIMAL(10,8)
I'm trying to insert this:
-117.1779216 However it keeps inserting as this : -99.99999999
Why is this? I see every other board storing it as DECIMAL, but it won't go back more when I'm giving it 10 places before the period... So I would think it could go -117.. None of them are marked as unsigned either.
Precision (10) - Scale (8) = 2
2 is the number of digits you can have to the left of the decimal
If you increase the precision, you can have more digits to the left of the decimal.
The declaration syntax for a DECIMAL column is DECIMAL(M,D). The ranges of values for the arguments in MySQL 5.1 are as follows:
M is the maximum number of digits (the precision). It has a range of 1 to 65. (Older versions of MySQL permitted a range of 1 to 254.)
D is the number of digits to the right of the decimal point (the scale). It has a range of 0 to 30 and must be no larger than M.
Taken from the manual :D
You set it to DECIMAL(10,8) with the number -117.1779216. MySQL reads this as -117.17792160 because it needs 8 digits of precision, but you said it should only have 10 digits, so anything over 99 makes it 11 digits and invalid.