Uncertain<T>

• Introducción al concepto del tipo Uncertain<T>, una nueva abstracción para manejar la incertidumbre a nivel de código
• Este tipo aplica metodologías de programación probabilística para modelar la confianza o posibilidad de un valor en lugar de la lógica booleana tradicional
• Ofrece funciones para tratar datos reales con mucho ruido, como GPS o datos de sensores, como distribuciones de probabilidad matemáticas
• Soporta un equilibrio entre eficiencia computacional y confiabilidad de resultados mediante técnicas de muestreo como SPRT y métodos de Monte Carlo
• Permite una integración gradual con código existente, por lo que resulta muy aplicable en entornos reales

---

Codificar la incertidumbre: la brecha entre la confianza y los datos reales

• Se menciona el fenómeno de que muchas personas dependen demasiado de la certeza
• Se señala que, conforme aumenta la experiencia en desarrollo de software, se vuelve más frecuente decir “depende del contexto”
• En el código, sin embargo, se sigue repitiendo el patrón de depender solo de juicios verdadero/falso
• Se critica especialmente la realidad de usar solo valores booleanos incluso al tratar datos inciertos como los del GPS
• El modelo de programación binariza demasiado rápido la ‘incertidumbre’ del mundo real y oculta su complejidad

Elegir la abstracción correcta

• En 2014, la University of Washington y Microsoft Research propusieron un concepto que refleja directamente la incertidumbre en el sistema de tipos
• El artículo "Uncertain<T>: A First-Order Type for Uncertain Data" demostró que el enfoque de programación probabilística es práctico
• Se publicó en un repositorio de GitHub código que adapta el concepto a Swift
• Con Uncertain<T>, los resultados de comparación también se expresan como probabilidades relativas, y en vez de devolver verdadero/falso, regresan Uncertain<Bool>
• El error de posición del GPS se modela según características de datos reales, como con una distribución de Rayleigh

Cómo funcionan en la práctica distintas operaciones con incertidumbre

• Soporta varios operadores y modelos de distribución de probabilidad, y construye un grafo de operaciones para muestrear solo cuando hace falta
• Usa SPRT (Sequential Probability Ratio Testing) para ajustar eficientemente la cantidad de muestras
• En el código de ejemplo se explica la diferencia en el número de muestras necesarias entre comparaciones simples y comparaciones compuestas
• Con esta abstracción, en vez de ignorar la incertidumbre, se la aprovecha de forma natural durante el cálculo para implementar código más ‘inteligente’

Aplicación de la metodología Monte Carlo

• Se introduce el muestreo Monte Carlo para analizar distribuciones de probabilidad y estimar valores esperados
• En la práctica, se puede obtener fácilmente el valor esperado simulando repetidamente el resultado de una tragamonedas
• Incluso sin cálculos analíticos complejos, es posible producir resultados realistas solo con muestreo repetido por computadora

Modelado rico de distribuciones de probabilidad

• Uncertain<T> incluye varios constructores de distribuciones de probabilidad, lo que permite modelar con precisión datos del mundo real como ruido de sensores, comportamiento de usuarios o latencia de red
• Soporta parametrización para distintos casos, como mixture, Bernoulli, exponential y normal
• También se ofrece por separado un proyecto de visualización interactiva para ayudar a comprender intuitivamente cada distribución

Operaciones estadísticas y de análisis disponibles

• Ofrece diversas funciones estadísticas como valor esperado, desviación estándar, intervalo de confianza, asimetría (skewness), curtosis (kurtosis) y entropía
• Los resultados de las operaciones también permiten ajustar la cantidad de muestras, haciendo posible un trade-off entre precisión y eficiencia
• Con la función de distribución acumulada (CDF), también se puede calcular fácilmente la probabilidad de que un valor sea menor o igual a cierto umbral

Guía para su aplicación en el mundo real

• Se explican problemas que pueden surgir en apps reales cuando se ignora la incertidumbre (por ejemplo, mostrar velocidades de GPS absurdas)
• Se enfatiza una transición gradual: se recomienda integrar Uncertain<T> de forma parcial, empezando por rutas críticas como la medición de distancia
• Es posible ajustar el equilibrio entre exactitud y rendimiento mediante configuraciones del costo computacional, como la cantidad de muestras
• En entornos profesionales se recomienda usar activamente herramientas de perfilado como Instruments.app
• El objetivo no es eliminar la incertidumbre, sino reconocer su existencia y establecer patrones de desarrollo para manejarla adecuadamente

Conclusión y perspectiva

• Se espera que los desarrolladores introduzcan el manejo de la incertidumbre desde áreas pequeñas para mejorar la usabilidad y reducir errores
• Al aceptar que la certeza total no existe, se puede elevar la calidad del software con herramientas y abstracciones adecuadas
• En términos prácticos, manejar correctamente la incertidumbre que realmente existe es la verdadera mejora para el trabajo real

[GN⁺]

Comentarios de Hacker News

• La incertidumbre del GPS por lo general solo puede aproximarse como circular bajo ciertas condiciones, como el posicionamiento prolongado con cielo abierto; en realidad, el modelo de error completo es mucho más complejo y existen varias formas de medir el error. Esto se vuelve importante en muchas situaciones donde es difícil tratar la ubicación como un solo punto; por ejemplo, en el caso de los autos autónomos, es común encontrarse con casos donde la incertidumbre de la estimación de posición está dominada por efectos de multitrayectoria no circulares. Si uno reflexiona a fondo sobre estas dificultades, al final termina llegando a reinventar técnicas como los filtros de partículas.
  • El GPS para vehículos normalmente se complementa con varios sensores y supuestos adicionales; en particular, el velocímetro, la brújula y el conocimiento de que el vehículo probablemente estará en alguna carretera del mapa juegan un papel importante. Además, se puede lograr un posicionamiento rápido bajo el supuesto de que no hubo cambio de ubicación entre el último apagado y el reinicio.
  • Los puntos de Lidar en realidad no son simples puntos, sino que existen como elipsoides centrados en la ubicación más probable.
• En la University of Cambridge se diseñó una microarquitectura de procesador inspirada en Uncertain<T> (James Bornholt) y en investigaciones relacionadas. Se diseñó para cargar no solo distribuciones paramétricas (Gaussian, Rayleigh, etc.), sino también conjuntos arbitrarios de muestras en registros/memoria, de modo que los valores del programa se propaguen a través de operaciones aritméticas como distribuciones no paramétricas. Con base en esta tecnología, una empresa derivada llamada Signaloid está entrando al mercado, y yo también estoy investigando su aplicación a la estimación de estado (por ejemplo, filtros de partículas) enlace al paper
• Si uno entiende la idea de que una variable en programación puede contener la “especificación” de una variable matemática, se abre un conjunto de posibilidades sorprendente que sustenta a la IA moderna. Si pensamos en la fórmula familiar y = m * x + b, cuando todos estos son literales no es más que una simple función de renderizado; pero si las variables contienen toda la estructura del camino de operaciones del que se derivaron, entonces, según la dirección del cálculo, se puede predecir un valor para renderizarlo (forward pass) o calcular automáticamente gradientes/derivadas para llegar hasta el entrenamiento de redes neuronales. Si estos resultados se muestrean matemáticamente, es posible obtener los pesos que forman el modelo. Así está diseñada cada capa del deep learning, y sistemas como PyTorch pueden compilar código óptimo incluso si solo se especifica la combinación de operaciones. Es decir, Uncertain<T> es apenas el punto de partida, y si imaginamos que cualquier variable numérica puede definirse en cualquier momento como metadatos de valores candidatos, y que esos metadatos pueden manipularse con la misma facilidad que sumar valores de variables, se vuelve un experimento muy interesante.
  • Esto suena realmente interesante; me pregunto si alguien podría explicarlo de forma que incluso una persona como yo, que no sabe mucho de machine learning ni de matemáticas, pueda entenderlo fácilmente.
  • Me pregunto si existe algún lenguaje PL (programming language) que realmente soporte este tipo de concepto a nivel de lenguaje.
  • Siento que este comentario está mezclando variables, funciones y sistemas lineales; no parece necesario juntar todo eso así.
• Me pregunto si este enfoque también puede manejar la covarianza entre varias variables. Por ejemplo, la posición del objeto medido también puede tener error, y ese error podría estar correlacionado con el error de mi propia posición (más aún si ambos se midieron con GPS al mismo tiempo). Si el sistema de tipos solo tiene un modelo univariado, seguiría siendo útil, pero creo que sería mucho más potente y preciso si también pudiera tratar la covarianza.
  • Si se usa un enfoque basado en muestreo, el modelado de covarianza queda incluido automáticamente. Basta con muestrear una sola vez los valores hoja que se usan varias veces durante una evaluación determinada; de hecho, se puede confirmar que la implementación real hace eso en el siguiente código código de Uncertain.swift
  • Desde hace mucho me pregunto si un programa podría “aprender” la covarianza durante el uso real. Si uno modela las variables como independientes, parece que inevitablemente se irá desviando de la realidad. Y en programas grandes, considerar manualmente la correlación entre todos los pares de variables es prácticamente imposible. Tal vez habría que idear una forma de aprenderlo automáticamente.
  • Si necesitas seguimiento de covarianza, también recomiendo probar la biblioteca gvar de python
  • Si se quisiera modelar correctamente la mecánica cuántica, habría que asociar una función de onda compleja a cada conjunto de variables entrelazadas.
• En los planos de ingeniería mecánica y similares, al comunicarse con quien realiza el mecanizado se usa el concepto de “tolerancia”; por ejemplo, 10cm +8mm/-3mm, donde el rango permitido queda claramente indicado por arriba y por abajo. También en preguntas como “¿ya casi llegamos?” basadas en GPS, cabría esperar que sea importante entender la direccionalidad del error y distinguir los casos mejores o peores según la “dirección” de la incertidumbre.
  • Lo malo de esta notación es que en algunos casos puede significar “nunca excede el rango máximo/mínimo”, mientras que en otros podría interpretarse como “solo hay un 10% de probabilidad de exceder el rango”.
  • La estimación de tres puntos (optimista, realista, pesimista), usada con frecuencia en planificación y otros contextos, es parecida. Incluso una distribución de probabilidad muy simple aporta mucha más claridad en cualquier campo donde intervenga la incertidumbre.
• Esta idea ya se ha implementado varias veces en el pasado bajo el nombre de “interval arithmetic”, y también la soportan Boost y flint Boost Interval flint(arb). A pesar de que se ha redescubierto repetidamente, me pregunto por qué nunca se volvió realmente mainstream. Si alguien la ha usado en campo real y la abandonó porque no le convenció, me gustaría escuchar su experiencia.
  • El artículo explica que Uncertain<T> usa una distribución Rayleigh para la incertidumbre del GPS. La distribución Rayleigh no es uniforme, sino que modela mejor la distribución de errores del mundo real. Por ejemplo, si en la biblioteca Boost se calcula (-2,2)*(-2,2), el resultado es (-4,4), pero en términos probabilísticos la ocurrencia simultánea de valores extremos es mucho menos probable, así que algo como (-2.35,2.35) sería más realista.
  • En física se aprende desde temprano la propagación de errores (error propagation). Si se asume que los errores siguen una distribución gaussiana, el cálculo resulta muy elegante, pero en la práctica la mayoría de las mediciones no siguen una distribución gaussiana, los errores no probabilísticos (sistemáticos) son problemáticos y es difícil tratarlos correctamente, por lo que la propagación automática de errores muchas veces casi no sirve. En la mayoría de los casos hace falta análisis manual.
  • No entiendo por qué este artículo está recibiendo tanta atención; este proyecto no solo soporta interval arithmetic, sino también varias distribuciones de incertidumbre.
  • Tipos simples como Boolean se pueden inferir fácilmente y tienen restricciones claras. En cambio, la incertidumbre física es compleja y el modelo debe variar según el dominio; una vez que decides tratar incertidumbre compleja, probablemente sea más apropiado usar un modelo especializado para ese propósito que una biblioteca simplemente bien empaquetada.
  • El interval arithmetic solo es más lento que la aritmética numérica simple por un factor constante, no por una diferencia enorme, y para cada operación existe un resultado de intervalo propio y más preciso. Sin embargo, la precisión no siempre está garantizada. En cambio, el grafo de operaciones con muestreo como el del artículo es más lento, pero puede acercarse con mayor fidelidad al modelo de error real. Tiene la ventaja de no necesitar un dominio abstracto que sacrifique precisión.
• El tipo de dato que yo quería crear era uno que representara cuánto se conoce cierto valor dentro de una distribución de probabilidad dada (o función de densidad de probabilidad), y en el que cada proceso de transformación añadiera también ese mismo grado de incertidumbre. Imaginaba un flujo donde, a medida que aumentan las observaciones (o cambia la clasificación condicional), el conjunto de esas distribuciones de probabilidad se va refinando continuamente. En última instancia, el objetivo era simular estos casos de resultados aleatorios basados en distribuciones.
• Esta idea también está muy relacionada con la vieja Functional Pearl “Probability Functional Programming” enlace al PDF, es realmente genial. Yo empiezo la primera clase de introducción a Haskell demostrando el problema de Monty Hall con un monad de probabilidad, mostrando de forma muy vistosa las probabilidades de victoria de las dos estrategias como fracciones enteras.
  • También vale la pena revisar la biblioteca monad-bayes de Haskell post de blog relacionado
• Tal vez estaría bien que Uncertain fuera el tipo base, y que solo en los casos realmente seguros hubiera que indicar aparte certain T.
  • Si se limita a mediciones físicas, sí; pero objetos como el dinero deben ser exactos hasta las unidades decimales. Por cierto, este enfoque también está implementado en algunas bibliotecas modernas de Fortran.
  • Podría funcionar como complemento del tipo Optional.
• Me pregunto si esto es, asintóticamente, una versión de programación de la lógica difusa (fuzzy logic) Wikipedia de Fuzzy Logic
  • Más bien se parece a la programación probabilística (probabilistic programming), que ya es un campo existente; un ejemplo representativo es Pyro