Validación cruzada de solvers
La validación cruzada de solvers consiste en contrastar un simulador numérico con implementaciones construidas de forma independiente, que difieren tanto en el método como en la base de código — porque los errores de implementación son autoconsistentes e invisibles desde dentro de una sola base de código.
Qué significa
Un simulador siempre coincide consigo mismo.Un signo invertido, un factor de 2, un desliz de normalización o un error en el orden de la base producen una evolución matemáticamente válida — solo que de la física equivocada —, así que ningún test escrito dentro de la misma base de código tiene garantizado atraparlo: la cabeza que se equivoca y la cabeza que comprueba son la misma cabeza.La solución estructural es la reimplementación independiente a lo largo de dos ejes a la vez: un método numérico diferente Y una base de código diferente.El estudio de caso de GradPulse usa tres solvers: un propagador PyTorch diferenciable con división de Trotter (el objeto bajo prueba), un solver de NumPy puro que toma la exponencial de matriz exacta del liouvilliano completo (el único que nunca rebana el tiempo) y el integrador ODE adaptativo de QuTiP, validado por la comunidad.La coincidencia observada de ~10⁻¹⁴ descarta errores de transcripción; los tres residuos se encuentran en el error de Trotter de primer orden ~2×10⁻⁷ y extrapolan con dt → 0 hasta ~10⁻¹³ — el error de aproximación se comporta exactamente como se predijo (a fecha de 2026).Una puerta de CI completa el diseño: si dos solvers cualesquiera discrepan en el punto de operación, la compilación falla automáticamente — la verificación se convierte en un invariante en cada commit, no en un evento puntual.Analogía cotidiana
Errores comunes
- La coincidencia entre dos implementaciones no prueba NADA si comparten código o la misma familia de aproximación — una suposición compartida hace eco, no verifica. La independencia debe ser DISEÑADA: un eje de método diferente Y un eje de base de código diferente.
- Los tests unitarios solo atrapan los errores que su autor imaginó — si la física mental del autor está equivocada, los valores esperados del test están equivocados de la misma manera. Atrapar errores no imaginados requiere reimplementación independiente.
- La validación puntual deja cada commit posterior sin verificar — una puerta de CI convierte la verificación de un evento en un invariante aplicado a cada commit.
Puntos clave
- Los errores de implementación (signos invertidos, factores de 2, normalización, orden de la base) son autoconsistentes e indetectables desde dentro de una sola base de código.
- La división en tres: propagación de Trotter vs exponencial de matriz exacta vs ODE adaptativa — cada uno atrapa errores que los otros no pueden ver.
- Coincidencias observadas de ~10⁻¹⁴ (sin errores de transcripción) y residuos que se encuentran en el error de Trotter de primer orden ~2×10⁻⁷ con extrapolación dt → 0 hasta ~10⁻¹³ muestran el error comportándose como se predijo (estudio de caso GradPulse, a fecha de 2026); una puerta de CI convierte cualquier deriva de solver en un fallo de compilación.
Comprueba tu comprensión
¿Por qué un test unitario dentro de una sola base de código puede no detectar un signo invertido en un generador de Lindblad?
- A.Porque los signos invertidos no tienen ningún efecto en la dinámica calculada
- B.Porque el generador equivocado sigue produciendo una evolución autoconsistente y matemáticamente válida, y los valores esperados del test provienen del mismo modelo mental posiblemente equivocado
- C.Porque la aritmética de coma flotante oculta todos los errores de signo por debajo de la precisión de máquina
- D.Porque los generadores de Lindblad no se pueden probar numéricamente en absoluto
Ver la respuesta
Respuesta: B. Porque el generador equivocado sigue produciendo una evolución autoconsistente y matemáticamente válida, y los valores esperados del test provienen del mismo modelo mental posiblemente equivocado
Por qué: Un generador mal transcrito evoluciona la física equivocada con perfecta consistencia interna, y los valores esperados del autor del test salen de la misma cabeza que cometió el error — la cabeza que se equivoca y la cabeza que comprueba son la misma cabeza.
En una validación cruzada de tres solvers, ¿por qué al menos un solver debe usar la exponencial de matriz exacta en lugar de rebanar el tiempo?
- A.Porque la exponencial de matriz exacta siempre es más rápida que los pasos de Trotter
- B.Porque los integradores ODE adaptativos no pueden manejar ecuaciones de Lindblad
- C.Porque los solvers que comparten la misma familia de discretización temporal no pueden detectar su error de clase Trotter de modo común — solo un método que nunca rebana el tiempo puede exponerlo
- D.Porque los sistemas de CI exigen al menos un cálculo de forma cerrada
Ver la respuesta
Respuesta: C. Porque los solvers que comparten la misma familia de discretización temporal no pueden detectar su error de clase Trotter de modo común — solo un método que nunca rebana el tiempo puede exponerlo
Por qué: Dos solvers de la familia Trotter comparten el mismo error de discretización y son ciegos a él el uno en el otro (error de modo común). La exponencial de matriz exacta nunca rebana el tiempo, así que el error de aproximación compartido aparece como un residuo frente a ella — que de hecho se encuentra en la escala de Trotter de primer orden predicha.
Se apoya en
Independent-reimplementation methodology is sound practice, but the concrete figures (1e-14 agreement, 2e-7 Trotter residual) are from the 2026 GradPulse case study (repo verified 2026-07-03).
Apréndelo con la práctica
Este concepto forma parte de un plan de 46 niveles, con un simulador interactivo y Lumen, un tutor cuyas respuestas se verifican antes de mostrarse. Los niveles 1–5 son gratuitos.