§38.2 concluded the objective is net-positive on severing a level's circulation: merging a corridor into a habitable sibling gains x6 (value_inside/value_circulation), while "level N not connected" costs x0.5, so break-even needs 0.5^w < 50/300, w > 2.58 -- "severing must cost at least 3 fails and costs 1". The arithmetic is right. The premise is wrong. Shipped anyway, EXPERIMENTAL and default off (byte-identical): fitness.connectivity_weight_for(value_inside, value_circulation) returns the smallest weight making severing net-negative -- 3.0 at the defaults, DERIVED from the rates rather than hard-coded so it tracks them if either is retuned. conf["connectivity_weight"] takes 1.0 / "auto" / a number and counts each connectivity failure as w failures in the 0.5^n penalty. MEASUREMENT: at auto (=3) the §38.2 deletion test does not move at all -- 5/25 rewarded either way, median x0.26 vs x0.27. Reason: the connectivity fail count is UNCHANGED in every rewarded deletion (115->107 fails but 5->5 connectivity; 107->99 but 3->3; 78->71 but 3->3). Weighting a fail that never fires changes nothing. And when a deletion DOES break connectivity, it is already punished. Every such case, 4 seeds per programme: harbor-house 2 of 32 sampled deletions, both punished (x0.00, x0.01); maple-court 5 of 32, all punished (x0.58 .. x0.07). Severing costs 1-2 connectivity fails PLUS the cascade after them, which already outweighs the x6 gain. The flat rule was never the problem. Where §38.2 went wrong: the x4.06 "well-daylit circulation leaf" that motivated the bead was a deletion that did NOT change the connectivity fail count. It was rewarded for removing the leaf's own quality failures -- §38.1's zero-value finding -- and I misread it as a pricing mechanism. §38.2 now carries the retraction inline. Two lessons recorded: a plausible closed-form arithmetic is not a measurement, and when a fix produces exactly no effect, suspect the premise before the implementation. Still standing from §38: §38.1 (buried leaves score zero quality and contribute no value) and §38.3 (frontage budget) are direct measurements. §39.7 remains the better lever on the same symptom -- it made the connectivity fails FIRE, where this would only have made them cost more. Re-opened as homemaker-py-yql: why level-not-connected persists in the best layout when severing is already punished. Evidence now points at reachability, not incentive, and it is newly measurable because §39.7 stopped store cupboards standing in for corridors. 353 passed (+3 new), same 7 pre-existing fixture failures, lint unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB |
||
|---|---|---|
| .beads | ||
| .claude | ||
| examples | ||
| experiments | ||
| src/homemaker_layout | ||
| tests | ||
| .gitignore | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| DESIGN.md | ||
| pyproject.toml | ||
| README.md | ||
homemaker-layout
Programme-driven building-layout search over slicing trees. A clean-room Python successor to the Perl Urb project, intended to eventually be 100% Python.
Why a rewrite
Urb represents a building as a binary slicing tree where room sizes are derived top-down from division ratios. That makes room area an emergent property of every cut above it, which:
- gives the genome low locality (a cut near the root rescales every descendant),
- makes target room sizes nearly impossible to hit, so the gaussian size penalty dominates fitness, and
- defeats crossover (transplanted subtrees lose their proportions).
homemaker inverts this: leaves carry target dimensions from the programme and division ratios are solved bottom-up for a fixed topology. The evolutionary search then only explores topology + types + adjacency.
Phase plan
Solver experiment: port Urb's geometry, re-solve ratios from programme targets, score the result against the original via the Perl oracle.✓Native Python fitness (retire the Perl oracle).✓Memetic search: canonical slicing genome + high-locality operators + Nelder-Mead inner loop.✓Penalty reshaping: lexicographic✓(-n_fails, fitness)outer-search comparison.Representation upgrade: canonical slicing encoding + bottom-up shape feasibility, scaled to larger programmes.✓- Search-quality experiments (current): a long running series of
opt-in levers tried against the
harbor-house,health-centre, andprogramme-houseexample corpora — leaf-sharing, finish-time cell→room collapse, ruin-and-recreate LNS, 2-opt polish, multi-use/co-located leaves, adjacency-graph and bubble-diagram fitness signals, and more. Most of these are negative/null results kept as opt-in flags or reference code rather than defaults. SeeDESIGN.md§11 onward for the full, numbered experiment log with methodology and results for each.
Layout
src/homemaker_layout/dom.py— read/write Urb.domYAML into aNodetree.src/homemaker_layout/geometry.py— faithful port of Urb's top-down geometry.src/homemaker_layout/programme.py— parsepatterns.configspace requirements.src/homemaker_layout/solver.py— bottom-up ratio solve (scipy).src/homemaker_layout/fitness.py— native Python fitness evaluator.src/homemaker_layout/fitness_cmd.py—homemaker-fitnessCLI (drop-in forurb-fitness.pl).src/homemaker_layout/collapse_cmd.py—homemaker-collapseCLI: finish-time global cell→room relabel of a.dom.src/homemaker_layout/graph.py— leaf-adjacency graph for programme-driven checks.src/homemaker_layout/genome.py— topology genome: base-floor tree + per-storey deltas.src/homemaker_layout/operators.py— high-locality mutation and subtree crossover.src/homemaker_layout/innerloop.py— ratio optimisation inner loop (Nelder-Mead / CMA-ES).src/homemaker_layout/driver.py— memetic search outer loop.src/homemaker_layout/evolve.py—homemaker-evolveCLI entry point.src/homemaker_layout/oracle.py— legacy Perl shim, kept for cross-validation only.src/homemaker_layout/bubble.py— 3D bubble-diagram adjacency fitness-signal prototype (DESIGN.md §27); validated null, not wired intofitness.py— reference only.
Room codes and reserved names
Leaf types live in three namespaces that share a first character. Only the first is enforced; the other two are conventions the fitness function reads, so a room's spelling can change how it is scored.
1. Generic structural types — C, O, S (reserved). The leaves the
search itself creates: C circulation, O outside, S sahn (an outside court
that also serves as circulation). Always uppercase. A programme code spelled
exactly C, O or S is rejected at load.
2. Programme room codes — anything else, lowercase. k1, b1, cr1,
of, and single-character codes like r or t. These may start with any
letter: since DESIGN.md §39.4 the generic tests match C/O/S exactly, so
naming a room cr1 no longer makes it circulation. (Before that fix it did —
and silently dropped it from the required-space check entirely.)
3. Access requirements — the usage: attribute. Every space declares one
of living, kitchen, bedroom, toilet, utility, none. Mandatory, no
fallback, and a missing or unknown value is a load error. It replaced a
first-character convention (b/t/l/k) under which a room silently
inherited another room's connectivity rules from its spelling — la1 "Laundry
Room" was trimmed as a living room (DESIGN.md §39.7).
spaces:
la1:
usage: utility # controlled, drives engine behaviour
name: Laundry Room # free text, building-specific
A usage value exists only where the engine treats it differently, so the vocabulary is closed: a new access class means new code, not new config. Check a programme with:
python experiments/audit_programme_config.py
which reports reserved-name collisions, the usage class each code picks up, and whether each room's size/width/proportion/crinkliness targets are mutually satisfiable at all.