Implicit default bounds are not surfaced to users
Problem
When a user runs a search without specifying bounds, the system silently applies hardcoded defaults:
--max-n: 1,000,000
--max-m: 10,000
These defaults are asymmetric (100x difference) and invisible in non-verbose mode. A does_exist query returning "Not found" gives no indication that the search was bounded — a user could reasonably interpret this as "no such value exists" when it actually means "not found within [1, 1000000]."
The asymmetry likely reflects the project's origin: n indexes into primesum(n,2) (the primary use case, requiring large ranges), while m is typically used for cross-sequence matching where smaller ranges suffice. But this rationale is not documented.
Current behavior
# User expects exhaustive search, gets bounded search with no indication
python prime-square-sum.py --expr "does_exist primesum(n,2) == 999999999"
# Output: Not found
# (actually: not found in n=[1, 1000000])
# Enumeration silently stops at bounds
python prime-square-sum.py --expr "for_any tri(n) + tri(m)" > results.txt
# Produces 10,000 x 1,000,000 = 10B combinations (m outer, n inner)
# No indication of bounds in output
Desired behavior
does_exist "Not found" should include the search range, at minimum a hint like (searched n in [1, 1000000])
for_any completion should show the search space covered
- The
--max-n / --max-m asymmetry should be explained in docs
- Consider: always show bounds in non-verbose mode when the user has NOT explicitly set them
Scope
This is about transparency of existing defaults, not about adding unbounded iteration (that's #25) or changing iteration strategies (that's #42).
Affected code
utils/cli.py — DEFAULT_BOUNDS, build_bounds_from_args()
prime-square-sum.py — argparse defaults (lines 157-169), verbose output (lines 331-334)
docs/expressions.md — Variables and Bounds section
Related issues
Implicit default bounds are not surfaced to users
Problem
When a user runs a search without specifying bounds, the system silently applies hardcoded defaults:
--max-n: 1,000,000--max-m: 10,000These defaults are asymmetric (100x difference) and invisible in non-verbose mode. A
does_existquery returning "Not found" gives no indication that the search was bounded — a user could reasonably interpret this as "no such value exists" when it actually means "not found within [1, 1000000]."The asymmetry likely reflects the project's origin:
nindexes intoprimesum(n,2)(the primary use case, requiring large ranges), whilemis typically used for cross-sequence matching where smaller ranges suffice. But this rationale is not documented.Current behavior
Desired behavior
does_exist"Not found" should include the search range, at minimum a hint like(searched n in [1, 1000000])for_anycompletion should show the search space covered--max-n/--max-masymmetry should be explained in docsScope
This is about transparency of existing defaults, not about adding unbounded iteration (that's #25) or changing iteration strategies (that's #42).
Affected code
utils/cli.py—DEFAULT_BOUNDS,build_bounds_from_args()prime-square-sum.py— argparse defaults (lines 157-169), verbose output (lines 331-334)docs/expressions.md— Variables and Bounds sectionRelated issues