Reorganize library into area folders and wrap everything in namespace wala

[devin-ai-integration]

Summary

Reorganizes src/ into area folders and puts the whole library in namespace wala.

New hierarchy (things without a clean category stay at the top level):

• num/: arithmetic value types — modnum, nim_prod, quaternion_hurwitz, fraction
• nt/: dirichlet_series, jacobi, lattice_cnt
• linalg/: char_poly
• ds/: seg_tree, bit, rmq, cnt_min, order_statistic
• seq/ (array + compare-elements: strings/permutations): suffix_array, manacher, alphabetic_huffman_code, perm_tree, cartesian_tree
• tree/: lct, top_tree, static_tree, level_ancestor
• graph/: mcmf joins make_st_dag
• fft/ (all R[[x]]-style things): gains bm
• top level: tensor, hash_map, bit_cast, yc, reverse_comparator, optimize, smawk
• geometry/, combo_games/: unchanged

verify/ is grouped into the same folders by each solution's primary header (e.g. verify/fft/convolution_mod.test.cpp, verify/tree/lca-static_tree.test.cpp; min_plus_convolution_convex_arbitrary stays top-level with smawk).

Namespace: namespace ecnerwala is renamed to wala, and every remaining header is wrapped in namespace wala; existing small namespaces nest (wala::seg_tree, wala::lct, wala::smawk, wala::dirichlet_series). Exceptions: yc.hpp keeps its intentional namespace std injection, and fft/all.hpp / the pragmas in optimize.hpp stay at file scope. Tests and verify solutions now qualify library names with wala::.

Includes are src-relative paths (#include "ds/seg_tree.hpp") resolved via the existing -I src; same-directory includes keep bare names (matching fft/'s existing convention). No -I flag, CMake glob, or verifier config changes were needed. AGENTS.md, README.md, and scripts/bundle.py docs updated to match.

Verified locally: full CMake build + all 106 Catch2 tests pass; bundle.py (single and --all) works with the new paths; oj-resolve finds all 34 verify solutions.

Link to Devin session: https://app.devin.ai/sessions/bf5c18e3f8f44dd0a14f73e05c6a9ea4
Requested by: @ecnerwala

---

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[beta-devin-ai-integration]

Devin Review found 2 potential issues.

[beta-devin-ai-integration]

🟡 Combining the suffix-array header with any FFT header no longer builds

Two identical copies of the same small helper end up in the same namespace once the suffix array header is wrapped (namespace wala { at src/seq/suffix_array.hpp:16), so any program that pulls in both this header and an FFT header fails to build.
Impact: Users can no longer use the suffix array together with the FFT/series/poly part of the library in one program.

Duplicate definition of the `sz` function template in namespace wala

src/seq/suffix_array.hpp:19 defines template<class T> int sz(T&& arg) and src/fft/common.hpp:39 defines a byte-identical template<class T> int sz(T&& arg). Before this PR the suffix-array copy lived in the global namespace and the fft copy in namespace ecnerwala, so they coexisted. Now both live in namespace wala, and a function template cannot be defined twice in the same namespace within one translation unit, so e.g. #include "seq/suffix_array.hpp" plus #include "fft/all.hpp" is a redefinition error.

No current test or verify solution includes both headers, so CI does not catch this; scripts/bundle.py --all bundles headers one at a time.

Fix by having one header include the other's definition (e.g. factor sz out into a shared top-level header, or have suffix_array.hpp reuse the one from fft/common.hpp).

Prompt for agents

`src/seq/suffix_array.hpp` and `src/fft/common.hpp` both define an identical `template<class T> int sz(T&& arg)` helper. Previously these lived in different namespaces (global vs `ecnerwala`), but after wrapping every header in `namespace wala` they are two definitions of the same function template in the same namespace, which is a redefinition error for any translation unit that includes both headers (e.g. a solution using both `seq/suffix_array.hpp` and `fft/all.hpp`). Deduplicate the helper: either move it to a single shared top-level header that both include, or have one of the two headers include and reuse the other's definition. Watch out that both headers should keep working stand-alone (they are bundled individually by scripts/bundle.py).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[beta-devin-ai-integration]

🟡 Library call in a unit test left unqualified, contrary to the repository's naming rule

One library call in the Berlekamp-Massey test is still written without the wala:: prefix (linearRec(S, tr, 1000) at src/fft/bm.test.cpp:13) even though the neighbouring call was updated, so the test does not follow the repository's stated convention.
Impact: Inconsistent style that only keeps working by accident and breaks the documented convention.

AGENTS.md requires qualifying library names in tests and verify solutions

AGENTS.md (style conventions) states: "The library lives in namespace wala; qualify library names with wala:: in tests and verify solutions". In src/fft/bm.test.cpp wala::BerlekampMassey was qualified but linearRec on the next line was not; it only resolves through argument-dependent lookup on wala::modnum. The same unqualified pattern remains in several verify solutions touched by this PR (ps_compose in verify/fft/composition_of_formal_power_series.test.cpp:20 and ..._large.test.cpp:20, ps_exp/ps_log/ps_inv/ps_pow in the corresponding verify/fft/*_of_formal_power_series.test.cpp, kth_term_of_linear_recurrence in verify/fft/kth_term_of_linearly_recurrent_sequence.test.cpp:26).

Prompt for agents

AGENTS.md requires library names to be qualified with `wala::` in tests and verify solutions. `src/fft/bm.test.cpp` qualifies `wala::BerlekampMassey` but leaves `linearRec(S, tr, 1000)` unqualified (it currently resolves only via ADL). Several verify solutions under `verify/fft/` similarly call `ps_compose`, `ps_exp`, `ps_log`, `ps_inv`, `ps_pow`, and `kth_term_of_linear_recurrence` unqualified. Qualify these library calls (e.g. `wala::linearRec`, `wala::series::ps_exp`) so all tests and verify solutions follow the documented convention.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[github-actions]

GCC Code Coverage Report

📂 Overall coverage

Metric	Coverage
Lines	🟡 8167/9961 (82.0%)
Functions	🟢 1115/1220 (91.4%)
Branches	🟡 6406/8281 (77.4%)