`num[0] == '0'`

at the very beginning would make "011235" invalid, which actually is valid. Then, I realized actually `num[0] == '0'`

should still be checked at the beginning of the outer loop for being leading 0 so that "0235813" would be claimed as invalid.
It seems like leetcode is missing these two test cases for now, though the expected answers would be right for both cases.

]]>`num[0] == '0'`

at the very beginning would make "011235" invalid, which actually is valid. Then, I realized actually `num[0] == '0'`

should still be checked at the beginning of the outer loop for being leading 0 so that "0235813" would be claimed as invalid.
It seems like leetcode is missing these two test cases for now, though the expected answers would be right for both cases.

]]>So, I guess there are two options for Leetcode:

a) modifying the description to say input string starting with '0' is invalid and updating its solution for getting expected answers.

b) adding test cases like "011235" and "0235813" into its pool.

]]>If the problem doesn't allow any number in the additive sequence to have leading zeros but the input number does (int the test case), some people might think that's unfair :)

If the solution passes existing test cases, it's supposed to work for test cases like "011235" as long as the idea of the algorithm is correct.

Please correct me if I am wrong, thanks mate!

]]>My original solution passed all the test cases, but did not work for test cases like "011235". The reason is I check whether the input string starts with '0' at the very begining:

```
class Solution(object):
def isAdditiveNumber(self, num):
"""
:type num: str
:rtype: bool
"""
if num is None or len(num) < 3 or num[0] == '0':
return False
n = len(num)
for i in range(1, n):
for j in range(i+1, n):
first, second, third = 0, i, j
if num[second] == '0' and third > second + 1:
break
while third < n:
result = str(int(num[first:second]) + int(num[second:third]))
if num[third:].startswith(result):
first, second, third = second, third, third + len(result)
else:
break
if third == n:
return True
return False
```

]]>Strictly speaking based on this interpretation, "011235" should be considered as valid, because it represents the integer 11235. And therefore, the valid sequence should be "1, 1, 2, 3, 5", not "0, 1, 1, 2, 3, 5". And "0235813" should also be considered as valid, because it represents 235813, which is an additive number.

Anyway, this is how the problem should be strictly interpreted, but I don't think this is the intention when the problem was created. I would like to see if we can add more restriction or clarification to the problem.

]]>