Exploración del reach que Balegas marca no resuelto (constraints over multiple
counters), en módulo aislado, sin tocar la API que Tawasuyu consume.
- reach::CoupledInvariants (politopo C·x ≤ slack, C ≥ 0) + VectorBudget:
escrow-por-restricción. certificado_politopo (proptest): reparto válido +
gastos ≤ presupuesto ⟹ todas las restricciones aguantan. La corrección.
- reach::{coboundary, sheaf_laplacian, SheafRouter}: el Laplaciano de haces
vectorial (L=δᵀδ) reusando nalgebra y la idea del coboundary del MVP.
diffuse conserva cada recurso y reduce la energía; ker L = totales
conservados = el H⁰ del MVP.
VEREDICTO HONESTO (REACH.md): la corrección es escrow sobre el politopo, NO
necesita haces. Con restricciones identidad (lo que un presupuesto real tiene),
el Laplaciano de haces colapsa a d_r Laplacianos escalares = el router de T9b
d_r veces (test identidad_colapsa_...). El haz sólo importaría con coupling en
bases incompatibles, que no es requisito real. Consistente con todo el arco: el
haz nunca fue lo que sostuvo la garantía. Recomendación: si Tawasuyu necesita
multi-invariante, usar el certificado del politopo + routers escalares; NO
promover reach.rs a estable ni venderlo como 'potenciado por haces'. Frontera
abierta dicha: restricciones no monótonas (C con signos mixtos) no cubiertas.
85 tests, clippy limpio.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
79 lines
4.7 KiB
Markdown
79 lines
4.7 KiB
Markdown
# REACH — invariantes acoplados y el Laplaciano de haces vectorial (EXPERIMENTAL)
|
||
|
||
Estado: **experimental** (`src/reach.rs`). **No toca M4** ni la API que Tawasuyu
|
||
consume. Este archivo es el veredicto honesto de si el haz aporta algo en el reach
|
||
multi-invariante — el sitio que Balegas (SRDS 2015) marca como no resuelto
|
||
("constraints over multiple counters... store them in a single object").
|
||
|
||
Fuimos "directo al Laplaciano de haces vectorial" a propósito, aceptando el riesgo
|
||
de repetir el patrón "el haz era la trampa". Aquí está lo que salió.
|
||
|
||
## Qué se construyó (y qué prueba cada test)
|
||
|
||
| Pieza | Qué es | Test |
|
||
|---|---|---|
|
||
| Certificado del politopo | escrow-por-restricción: `C·Σ b_v ≤ slack`, gasto `s_v ≤ b_v` ⟹ todas las restricciones aguantan (`C ≥ 0`) | `certificado_politopo` |
|
||
| Laplaciano de haces `L = δᵀδ` | stalks vectoriales `ℝ^{d_r}`; ker = totales conservados | `el_nucleo_son_los_totales_conservados` |
|
||
| Difusión vectorial | `x ← x − αLx`: conserva cada recurso, reduce la energía | `la_difusion_conserva_los_totales` |
|
||
| Colapso identidad | con restricciones `I`, `L` = `d_r` Laplacianos escalares | `identidad_colapsa_a_d_difusiones_escalares` |
|
||
|
||
## El veredicto (sin adornos)
|
||
|
||
**1. La corrección NO necesita haces.** El multi-invariante coordination-free se
|
||
resuelve con **escrow-por-restricción sobre el politopo**: presupuesto vectorial
|
||
por dispositivo, un gasto es local-seguro sii cabe en el presupuesto de *cada*
|
||
restricción que toca. El certificado (`C·consumed ≤ slack`) sale de que `C ≥ 0` y
|
||
`Σ gastos ≤ Σ presupuestos`. Es la extensión natural de T9–T11 a varios
|
||
contadores, y es **exactamente** el "razonar sobre todos juntos / un solo objeto"
|
||
que Balegas dice que hace falta. Real, usable, sobrio — y **prior-art conceptual**,
|
||
no novedad.
|
||
|
||
**2. El haz, con las restricciones que un presupuesto de verdad tiene (identidad),
|
||
NO aporta corrección ni nada nuevo.** El Laplaciano de haces del haz constante es
|
||
`Laplaciano_de_grafo ⊗ I`: difundir el presupuesto vectorial es, literalmente,
|
||
correr `d_r` veces el **router escalar de T9b** (`identidad_colapsa_...` lo prueba
|
||
entrada por entrada). El haz sólo se separaría del caso escalar con **restricciones
|
||
no triviales `R_e ≠ I`** — dispositivos que miden recursos acoplados en **bases
|
||
incompatibles**. Eso no es un requisito de ningún sistema de presupuestos real que
|
||
conozcamos; es una solución buscándose un problema.
|
||
|
||
**3. Lo único genuinamente bonito es una conexión, no una capacidad.** `ker L` =
|
||
secciones globales = los `d_r` totales conservados = el `H⁰` del MVP (§7.2). La
|
||
misma álgebra lineal que en el motor lineal era un **detector con falso-positivo**
|
||
aquí lee las **cantidades que la difusión conserva**. Es un cierre de arco elegante
|
||
y honesto — pero es interpretación, no un teorema nuevo.
|
||
|
||
## Consistente con todo el proyecto
|
||
|
||
El patrón se repite por última vez, y conviene nombrarlo: **cada vez que el haz fue
|
||
la protagonista, no fue lo que sostuvo la garantía.** La corrección vino del
|
||
politopo/escrow (T9–T11, prior-art bien hecho); el haz fue, en el mejor caso, una
|
||
lente o una comodidad de ruteo que colapsa al caso escalar. El reach multi-
|
||
invariante **no** cambia eso.
|
||
|
||
## Recomendación (para no ser contraproducente)
|
||
|
||
- **Si Tawasuyu necesita multi-invariante:** dale **escrow-por-restricción** (el
|
||
certificado del politopo) y rutea con `d_r` routers escalares de T9b. **No** lo
|
||
vendas ni lo cablees como "multi-invariante potenciado por haces": no lo es.
|
||
- **No promuevas `reach.rs` a la API estable** hasta que aparezca un caso real con
|
||
coupling-en-bases-incompatibles que justifique el Laplaciano de haces sobre `d_r`
|
||
difusiones escalares. Hasta entonces es más máquina de la que el problema pide.
|
||
- **Lo que sí es sólido y adoptable:** el `CoupledInvariants` + certificado del
|
||
politopo. Eso extiende M4 a varios contadores de forma correcta y probada.
|
||
|
||
## Frontera abierta (donde NO llegamos, dicho)
|
||
|
||
- **Restricciones no monótonas (`C` con signos mixtos):** el certificado de escrow
|
||
**no aplica** (consumir un recurso puede *liberar* slack de otra restricción). Es
|
||
otro problema, probablemente necesita reservas de otro tipo; no está resuelto aquí.
|
||
- **Reparto óptimo del presupuesto vectorial:** el certificado aguanta cualquier
|
||
reparto válido; cuál minimiza rebalanceos futuros es optimización sobre el
|
||
politopo — ahí la difusión ayuda, pero es rendimiento, no corrección (R-T9a
|
||
elevado a vectores).
|
||
|
||
**Conclusión de una línea:** el reach multi-invariante es real y lo resolvimos
|
||
—con escrow sobre el politopo, no con haces—; el Laplaciano de haces vectorial es
|
||
correcto pero, con restricciones identidad, no es más que el router escalar `d_r`
|
||
veces. Registrado como tal.
|