Hey! Great explanation. But I had a solution which was a little easy for me to go with. Do you mind comparing and telling me which one is better in terms of everything? ## Reverse Integer class Solution: def reverse(self, x: int) -> int: x = str(x) if len(x) == 1: return int(x) sign = '' if x[0] == '-': sign = x[0] x = x[1:] rev_num = x[::-1] final_answer = int(sign + rev_num) if final_answer < -2**31 or final_answer > 2**31 - 1: return 0 return final_answer
The problem with this solution is that we have to assume that the environment cannot hold anything past the 32-bit signed integer range. When you reverse the string and cast it back into an integer, you may have unknowingly caused overflow. Since final_answer shouldn't be able to hold anything past the 32-bit signed integer range, final_answer would never be less than -2 ** 31 or greater than 2 ** 31 - 1. This is actually a problem geared more towards languages like Java or C++, where you actually have an int data type that physically cannot go past the 32-bit signed integer range. In Python, we don't have this restriction, which is why in your code, final_answer can go past the valid range and works in the LeetCode environment. You may understand the problem better if you attempt it in Java or C++, but I just used Python since that's what I use for all my solutions.
Saw your solution on Leetcode and realized that your overflow checker is not good. It only checks if reverse > MAX_INT/10 or reverse*10 > MAX_INT but doesn't check if reverse*10 + digit might overflow before it's calculated. Essentially you should be using reverse > MAX_INT/10 - digit/10 as your checking expression.
I address this point at 9:27. We don't need to check the value of the last digit because the last digit of MAX_INT, 7, is greater than the first digit, 2. In other words, if the reversed number has the same number of digits as MAX_INT, but adding on the very last digit causes overflow, then the last digit to be reversed must be an 8 or a 9. But if that were true, then the original number given must have had an 8 or a 9 as its first digit, and that would already be outside of the 32-bit range, so it would be impossible to receive that number as an input. In fact, if the input number has the same number of digits as MAX_INT, then I KNOW that the last digit to be reversed must be 2 or less.
@@AlgoEngineAhh makes sense. I ended up skimming through the video. I think one point to note is that we generally won’t know the value of 2^^x if x is large in a test or interview so it will be safer to code in the digit check but you made a very good point. Gives me a new way of looking at it. Another interesting thing I found is the // operator does not work in Python3 for this problem but math.trunc does even though they behave similarly. Any idea why?
@@kaustuvprateeq6756 Yes, that point is discussed at 4:38 and 7:14. For positive numbers, math.trunc and floor division (//) work the same, but the difference is with negative numbers. Floor division always rounds down AWAY from zero, but when dealing with negative numbers in this problem, we actually want to round up TOWARDS from zero. For example, -45.6 should be rounded up to -45. Math.trunc simply throws away everything past the decimal point, so it works exactly as we want for this problem.
