Yes, we do. We'll talk about how to avoid overflow. So, how can we do that? The most obvious and in fact usual approach is just take the values that do overflow into some larger type. So, fixed in our previous example, could look like this. If the product of a and b doesn't fit in an int, but fits in a long long, let's just put it in a long long. The code given here and later, it's going to see it as C++, but in Java it'll be the same, only instead of a long long, they'll be long. However, that doesn't solve the problem. If you're on this code, the result will still be incorrect. Why is that? Because assignment works as follows. First, the value of the expression on the right is calculated, and only then it spots in the variable on the left. And when you multiply two integers a and b, the result has type ints because a and b also have type ints. And so, the floor does happen, but before the assignment and in a computation. And so, the result would still be incorrect because it puts in a larger value already overflowed results. Well, what if you write the prototype this without any variables just two integer constants? Maybe it will help. In fact now, because integer constants also have the type ints, and it happens almost in any language. Well, how to avoid the flow correctly. We've seen that if we multiplied two ints, the result will be an int. So, if we multiply the long longs, the result will be a long long. So, a possible solution could look like this, would just make our variables a and b of type long long, and the product will also be a long long. And so, everything will be fine. In fact, it's enough to do this with only one of the variables, but it's safer to put everything on long long so as to not forget it's somewhere. There is another option. It could still have both variables of type ints, but before the multiplication cast one of them to long long. What happens there is that the variable a is put on some temporary variable of type long long, and then multiplied by b. As one of the factors has type long long, the result will also be a long long. And so, there will be an overflow. So, if we don't have a to get flow, just use the 64-bit integer variable where needed. Some further remarks about that. Of course, large values don't come for free as their 64-bit integer type has twice more space, as the int type, and is also likely to be more slower. The most obvious sources of overflow are products. In fact, if you don't like to think about overflow when multiplying two integers, you could just take the limits on the variables from the input, and see if in some particular operation there will be overflow or not. However, sums could also lead to overflow. Take a look at the code on the slides. It's the same as the previous one, because multiply 50,000 by 50,000 is the same as adding 50,000, 50,000 times. But the variables that tells the result here has a type int. And as we know, the actual result could not fit in there. So, they also lead to overflow, even if you don't use the products. The solution here is like previous. Just like the variable which tells the results of type long long. For now, the only option we have, is to use 64-bit integers. But what if the result doesn't fit even in there? Likely, in Competitive Programming, nearly always, 64-bit integers are enough. If somewhere your value does exceed this range. You should think again in fact. Most likely you don't need this value at all, You could re-order computations or get it off this large values in some other ways. Of course, then in fact could be problems where even 64-bit integers are not enough, and you need some real large values. But they are uncommon and advanced. So, to sum up what we've learnt, when multiplying or adding integers, you should always think about possible overflow. To check whether overflow happens or not, you should take the worst case values of the input variables, which you can find as a statement and see if the result of some operation fits in an int or not. If the result of some operation doesn't fit, use 64-bit integer type. But remember to use it before the computation, not after. So, that's all for this video. In the remaining part of the lesson, we'll talk about non integers. And there, the things are even more interesting.