Metodología numérica

1. El contrato de determinismo

El motor (vms7-wasm) computa en bits takum32 — la salida HTTP es el decimal round-trip exacto de esos bits, vía la conversión takum32→f64 del propio wasm. La conversión es sin pérdida: la precisión de takum32 cabe en los 53 bits de la mantisa de f64. Dos consecuencias que declaramos con precisión:

• No hay IEEE float en el cálculo — el único float que toca la cadena de respuesta es la conversión final de formato, y es exacta.
• El determinismo se amarra a la versión del motor: el mismo request contra la misma versión produce el mismo resultado y el mismo receipt, en cualquier máquina. Cada certificado declara su versión.

2. La TIR por bisección

El instrumento npv calcula la TIR por bisección dentro de un intervalo de enclavamiento que TÚ configuras (lo y hi). La bisección corre un cómputo fijo dentro del contrato: el receipt (campo steps) demuestra que cada corrida ejecuta exactamente el mismo trabajo — eso es el determinismo, medido.

3. El cero exacto de la amortización

El instrumento amort genera el schedule completo y exige que el saldo final sea exactamente cero: el contrato compara el saldo contra los bits del cero takum y rechaza su propia salida si no coincide ("bin corrupto"). El cero no es un promedio que sale bien — es un guard que falla fuerte. Por eso el demo puede prometerlo: cuando ves saldo final 0, el contrato verificó el cierre bit a bit antes de responder.

El redondeo comercial es cosa tuya: los valores que entrega la API son takum exactos; cuando tu sistema paga una cuota en céntimos, redondea tú — el certificado amarra los bits, no tu política comercial.

4. gas vs steps

gas es el presupuesto de cómputo del contrato (2.000.000 por ejecución — el mismo para todos los instrumentos). steps es el cómputo medido de tu corrida (el bond del demo: 24.195). Un receipt con status 0 significa que la ejecución terminó Halted dentro del presupuesto; cualquier desviación termina en status ≠ 0 y reembolso automático del crédito.

5. El portafolio de bonos: la suma vive en el motor

El contrato price_bond_portfolio precioa 4 bonos parametrizables y computa el valor V del conjunto en UNA ejecución. La diferencia con un lote: aquí la suma ponderada de los valores presentes ocurre dentro de la VM (acumulación de alta precisión sin pérdida intermedia) — jamás en JavaScript. Por eso V no es exactamente P1+P2+P3+P4: los P son valores takum individuales ya redondeados a su bits de salida; V acumula los valores internos completos antes de redondear UNA sola vez.

• La forma del contrato: exactamente 4 bonos (c, y, f cada uno) con n∈[1,63] — el límite de la tabla W del contrato. La forma es fija; los parámetros, libres.
• El receipt mide el conjunto: el portafolio canónico ejecuta 190 471 steps (vs 24 195 de un bono solo) — verifícalo en /verify.
• Determinismo dato-dependiente, pineado: en bonos de vencimiento largo (n=60) la ejecución del artifact difiere de la referencia algebraica pura en algunos datos — ese comportamiento está pineado en VMS7 con goldens: el mismo request da siempre los mismos bits, y los bits están firmados por la cadena de verificación completa.

6. Rango y precisión de takum32

Sobre el estándar (no nuestro — takum.org, paper arXiv:2404.18603, Hunhold 2024): takum32 garantiza 20 bits de fracción (n−12 para n=32) y un rango dinámico de aproximadamente (4.2×10⁻⁵⁶, 2.4×10⁵⁵) para n≥12 — acotado y independiente del valor, a diferencia del float IEEE cuyo rango útil y densidad dependen del expoente. La matemática financiera de estos instrumentos (intereses, descuentos, schedules) cabe de sobra en esa precisión.

7. Qué NO es esta API

• No es asesoría financiera — son cómputos deterministas de los inputs que envías (Terms §2).
• No es un runtime general (todavía) — hoy ejecuta el catálogo de contratos de PricingAPI. La apertura a contratos de terceros está en el roadmap y se anunciará aquí.
• No almacena tus portafolios — el lote vive en tu request; no guardamos nada de él.