integer-arithmetic

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 5 years ago . If I multiplie two 16-bit numbers, the result will be 32-bit long. But why is this so? What is the clear explanation for this? And for my right understanding: The calculation for this is: n-bit number multiplied with a m-bit number gives a (n+m) bit number? 回答1: (2 n - 1)*(2 m - 1) = 2 n+m - 2 n - 2 m + 1 -(2 n

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 5 years ago . If I multiplie two 16-bit numbers, the result will be 32-bit long. But why is this so? What is the clear explanation for this? And for my right understanding: The calculation for this is: n-bit number multiplied with a m-bit number gives a (n+m) bit number? 回答1: (2 n - 1)*(2 m - 1) = 2 n+m - 2 n - 2 m + 1 -(2 n

问题 So when I read the book and it says that overflow can't occur when add different signs and subtraction of the same sign. But I have question when I do this: 185 - 122 I converted binary of 122 to 2s complement and did the addition, which is different signs: 185+(-122) and when I add them together, I got the sign bit overflow to 100111111. But if I cut off the MSB on the left, it is the correct answer. Is it an overflow? 回答1: No, it isn't overflow - the overflow resulting from the addition of

问题 Is it possible to create a predicate max/2 without an accumulator so that max(List, Max) is true if and only if Max is the maximum value of List (a list of integers)? 回答1: Yes, you can calculate the maximum after the recursive step. Like: max([M],M). % the maximum of a list with one element is that element. max([H|T],M) :- max(T,M1), % first calculate the maximum of the tail. M is max(H,M1). % then calculate the real maximum as the max of % head an the maximum of the tail. This predicate will

问题 I know that addition of two unsigned integers larger than the bus size of a given processor can be achieved via the carry flag. And normally, the same is true for signed integers using the overflow flag. However, the Intel 8085 only possesses a Sign flag, not an Overflow flag, so how does it deal with signed integer arithmetic? 回答1: As you know, the overflow flag is only relevant for signed integer arithmetic. On processors whose ALU has both overflow and carry flags (like x86), both of these

问题 I'm trying to multiply two 128-bit integers in C. Here is my algorithm: Split the two 128-bit sequences into S1 and S2. Then split S1 into S11 (front/higher half) and S12 (back/lower half) and split S2 into S21 (front/higher half) and S22 (back/lower half). Multiply S12 by S22... = S1222. Multiply S11 by S21... = S1121 and then bit shift it by multiplying it by 2^128 Combine S1222 and S1121 to be the front and back halves of a new array. Let's call it "Array1". The new array's length is twice

问题 I wanted to test if bitwise operations really are faster to execute than arithmetic operation. I thought they were. I wrote a small C program to test this hypothesis and to my surprise the addition takes less on average than bitwise AND operation. This is surprising to me and I cannot understand why this is happening. From what I know for addition the carry from the less significant bits should be carried to the next bits because the result depends on the carry too. It does not make sense to

问题 For example, A=10^17, B=10^17, C=10^18. The product A*B exceeds the limit of long long int. Also, writing ((A%C)*(B%C))%C doesn't help. 回答1: Assuming you want to stay within 64-bit integer operations, you can use binary long division, which boils down to a bunch of adds and multiply by two operations. This means you also need overflow-proof versions of those operators, but those are relatively simple. Here is some Java code that assumes A and B are already positive and less than M. If not, it

问题 Previously today I was trying to add two ushorts and I noticed that I had to cast the result back to ushort. I thought it might've become a uint (to prevent a possible unintended overflow?), but to my surprise it was an int (System.Int32). Is there some clever reason for this or is it maybe because int is seen as the 'basic' integer type? Example: ushort a = 1; ushort b = 2; ushort c = a + b; // <- "Cannot implicitly convert type 'int' to 'ushort'. An explicit conversion exists (are you

问题 Closed . This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 3 years ago . The C standard says that overflow in arithmetic is undefined. I would like to know how to implement wraparound arithmetic in a performance-friendly way. This means that overflow checking solutions like presented here are not an option (as they slow the operation by about an order