feat(algorithms, backtracking): is additive number#193
Conversation
Algorithm to check if a string is an additive number
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughA new Additive Number algorithm is added to the backtracking category, featuring two distinct implementations (DFS-based and backtracking-based) that determine whether a numeric string forms a valid additive sequence. The addition includes documentation, unit tests, and repository index updates. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (3)
algorithms/backtracking/additive_number/test_additive_number.py (1)
8-16: Add explicit leading-zero rejection cases.Please add at least one negative case like
("1023", False)to directly lock in the “no leading zero” rule for non-zero numbers.✅ Suggested test-case additions
IS_ADDITIVE_NUMBER_TEST_CASES = [ ("112358", True), ("199100199", True), ("11235813", True), ("12345", False), ("000", True), + ("101", True), + ("1023", False), ("1", False), ("0", False), ]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@algorithms/backtracking/additive_number/test_additive_number.py` around lines 8 - 16, Add a negative test asserting leading-zero rejection by updating the IS_ADDITIVE_NUMBER_TEST_CASES list in test_additive_number.py (the variable name is IS_ADDITIVE_NUMBER_TEST_CASES) to include at least ("1023", False) so the test suite explicitly covers the rule that multi-digit numbers cannot have leading zeros; place the new tuple among the existing cases.algorithms/backtracking/additive_number/__init__.py (1)
14-18: Tighten DFS prefix loop to the remaining substring length.Line 14 currently iterates to
n(full input length), which performs redundant slice/int work after the remaining suffix is exhausted.♻️ Suggested fix
- for i in range(1, n + 1): + for i in range(1, len(number) + 1): if a + b == int(number[:i]): if dfs(b, a + b, number[i:]): return True🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@algorithms/backtracking/additive_number/__init__.py` around lines 14 - 18, The DFS loop currently uses n (original full input length) causing unnecessary slices when the remaining suffix is shorter; in dfs(a, b, number) replace the loop "for i in range(1, n + 1):" with a loop bounded by the remaining substring length (e.g., remaining = len(number); for i in range(1, remaining + 1):) so you only attempt prefixes that exist, and keep using dfs, a, b and number unchanged otherwise.algorithms/backtracking/additive_number/README.md (1)
77-80: Clarify complexity assumptions in this paragraph.Line 77 currently states
O(n^3), while Line 80 also notes per-conversion costs up toO(n). Consider clarifying the model used (fixed-width arithmetic vs big-int/parse costs) to avoid mixed signals.✏️ Suggested wording update
-The time complexity of the solution is O(n^3) in the worst case, where n is the length of the string num. The outer two -levels of recursion effectively choose the lengths of the first two numbers, which gives O(n^2) combinations. For each -combination, verifying the rest of the string takes O(n) time since the additive property uniquely determines each -subsequent number. Additionally, converting substrings to integers takes up to O(n) per conversion. +The time complexity is commonly described as O(n^3): O(n^2) choices for the first two numbers, and O(n) to validate the +rest for each choice. If you also account for substring-to-integer parsing cost, the practical bound can be higher.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@algorithms/backtracking/additive_number/README.md` around lines 77 - 80, Clarify the complexity paragraph by stating the arithmetic model: specify whether we assume fixed-width integer arithmetic (so substring-to-integer parsing is O(1) and overall time O(n^3) dominated by combination + verification), or we account for parsing/big-int costs (so each substring conversion is O(n) and total becomes O(n^4)); update the wording around the terms "O(n^3)", "O(n) per conversion", and the variable "num" to explicitly state which model is used and how it affects the final complexity bound.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@algorithms/backtracking/additive_number/__init__.py`:
- Around line 14-18: The DFS loop currently uses n (original full input length)
causing unnecessary slices when the remaining suffix is shorter; in dfs(a, b,
number) replace the loop "for i in range(1, n + 1):" with a loop bounded by the
remaining substring length (e.g., remaining = len(number); for i in range(1,
remaining + 1):) so you only attempt prefixes that exist, and keep using dfs, a,
b and number unchanged otherwise.
In `@algorithms/backtracking/additive_number/README.md`:
- Around line 77-80: Clarify the complexity paragraph by stating the arithmetic
model: specify whether we assume fixed-width integer arithmetic (so
substring-to-integer parsing is O(1) and overall time O(n^3) dominated by
combination + verification), or we account for parsing/big-int costs (so each
substring conversion is O(n) and total becomes O(n^4)); update the wording
around the terms "O(n^3)", "O(n) per conversion", and the variable "num" to
explicitly state which model is used and how it affects the final complexity
bound.
In `@algorithms/backtracking/additive_number/test_additive_number.py`:
- Around line 8-16: Add a negative test asserting leading-zero rejection by
updating the IS_ADDITIVE_NUMBER_TEST_CASES list in test_additive_number.py (the
variable name is IS_ADDITIVE_NUMBER_TEST_CASES) to include at least ("1023",
False) so the test suite explicitly covers the rule that multi-digit numbers
cannot have leading zeros; place the new tuple among the existing cases.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 27de1407-791f-4680-bc38-d383b85d7735
📒 Files selected for processing (4)
DIRECTORY.mdalgorithms/backtracking/additive_number/README.mdalgorithms/backtracking/additive_number/__init__.pyalgorithms/backtracking/additive_number/test_additive_number.py
…ions and doc update
Describe your change:
Algorithm to check if a string is an additive number
Checklist:
Fixes: #{$ISSUE_NO}.Summary by CodeRabbit
Documentation
New Features
Tests