Uncertain<T>

• Einführung des Konzepts des Typs Uncertain<T> als neue Abstraktion, um Unsicherheit auf Code-Ebene zu behandeln
• Dieser Typ wendet Methoden des probabilistischen Programmierens an und modelliert statt traditioneller Boolescher Logik die Zuverlässigkeit oder Wahrscheinlichkeit von Werten
• Bietet Funktionen, um rauschbehaftete reale Daten wie GPS- oder Sensordaten als mathematische Wahrscheinlichkeitsverteilungen zu behandeln
• Unterstützt mit Sampling-Techniken wie SPRT und Monte Carlo die Balance zwischen Recheneffizienz und Zuverlässigkeit der Ergebnisse
• Lässt sich schrittweise in bestehenden Code integrieren und ist dadurch sehr praxistauglich

---

Unsicherheit in Code fassen: die Lücke zwischen Zuversicht und realen Daten

• Es wird das Phänomen erwähnt, dass viele Menschen zu stark auf Bestätigung angewiesen sind
• Es wird darauf hingewiesen, dass man mit wachsender Erfahrung in der Softwareentwicklung immer häufiger sagt: „Es kommt darauf an“
• Im Code wiederholt sich jedoch weiterhin das Muster, sich nur auf Wahr/Falsch-Entscheidungen zu stützen
• Kritisiert wird insbesondere die Realität, dass selbst beim Umgang mit unsicheren Daten wie GPS nur Boolesche Werte verwendet werden
• Programmiermodelle teilen die reale „Unsicherheit“ zu früh binär auf und verdecken dadurch die Komplexität

Die Wahl der richtigen Abstraktion

• 2014 schlugen die University of Washington und Microsoft Research ein Konzept vor, das Unsicherheit direkt im Typsystem abbildet
• Das Paper "Uncertain<T>: A First-Order Type for Uncertain Data" zeigte, dass ein probabilistischer Programmieransatz praktikabel ist
• Ein nach Swift portierter Code des Konzepts wurde in einem GitHub-Repository veröffentlicht
• Mit Uncertain<T> lassen sich auch Vergleichsergebnisse als relative Wahrscheinlichkeiten ausdrücken; statt Wahr/Falsch wird ein Uncertain<Bool> zurückgegeben
• GPS-Ortungsfehler werden passend zu den Eigenschaften realer Daten modelliert, etwa mit der Rayleigh-Verteilung

Die Praxis vielfältiger Unsicherheitsoperationen

• Unterstützt verschiedene Operatoren und Wahrscheinlichkeitsverteilungsmodelle, erstellt Rechengraphen und führt Sampling nur bei Bedarf aus
• SPRT (Sequential Probability Ratio Testing) dient zur effizienten Steuerung der Anzahl an Samples
• Im Beispielcode wird der Unterschied in der benötigten Sample-Anzahl zwischen einfachen und zusammengesetzten Vergleichen erläutert
• Mit dieser Abstraktion wird Unsicherheit nicht ignoriert, sondern natürlich in den Rechenprozess eingebunden, wodurch sich „intelligenterer“ Code schreiben lässt

Einsatz der Monte-Carlo-Methodik

• Zur Analyse von Wahrscheinlichkeitsverteilungen und zur Berechnung von Erwartungswerten wird Monte-Carlo-Sampling eingesetzt
• Durch wiederholte Simulation von Slotmaschinen-Ergebnissen lassen sich Erwartungswerte leicht ableiten
• Auch ohne komplexe analytische Berechnungen können durch wiederholtes computerbasiertes Sampling realistische Ergebnisse erzielt werden

Reichhaltige Modellierung von Wahrscheinlichkeitsverteilungen

• Uncertain<T> enthält integrierte Konstruktoren für verschiedene Wahrscheinlichkeitsverteilungen, um reale Daten wie Sensorrauschen, Nutzerverhalten oder Netzwerk-Latenz präzise zu modellieren
• Unterstützt die Parametrisierung für unterschiedliche Situationen, darunter Mischverteilungen (mixture), Bernoulli, exponential und normal
• Um das intuitive Verständnis der einzelnen Verteilungen zu fördern, wird zusätzlich ein interaktives Visualisierungsprojekt bereitgestellt

Statistische und analytische Operationen

• Bietet verschiedene statistische Funktionen wie Erwartungswert, Standardabweichung, Konfidenzintervall, Schiefe (skewness), Kurtosis und Entropie
• Bei den Ergebnissen lässt sich auch die Anzahl der Samples steuern, wodurch ein Trade-off zwischen Präzision und Effizienz möglich ist
• Mithilfe der kumulativen Verteilungsfunktion (CDF) lässt sich auch die Wahrscheinlichkeit, dass ein Wert unterhalb eines bestimmten Grenzwerts liegt, leicht berechnen

Leitfaden für den Praxiseinsatz

• Es wird erklärt, welche Probleme in Apps entstehen können, wenn Unsicherheit ignoriert wird (z. B. völlig unrealistische GPS-Geschwindigkeitsanzeigen)
• Betont wird ein schrittweiser Übergang: empfohlen wird, Uncertain<T> zunächst teilweise in zentrale Pfade wie bestehende Distanzmessungen zu integrieren
• Über Einstellungen zu den Rechenkosten wie der Sample-Anzahl lässt sich die Balance zwischen Genauigkeit und Performance steuern
• Für die Praxis wird der aktive Einsatz von Profiling-Tools wie Instruments.app empfohlen
• Ziel ist nicht, Unsicherheit zu beseitigen, sondern ihre Existenz anzuerkennen und angemessene Entwicklungsmuster für den Umgang damit zu etablieren

Fazit und Ausblick

• Entwickler können die Behandlung von Unsicherheit zunächst in kleinen Bereichen einführen und so Verbesserungen bei Nutzbarkeit und Fehlerdämpfung erwarten
• Wer akzeptiert, dass vollständige Sicherheit nicht existiert, kann mit geeigneten Werkzeugen und Abstraktionen die Qualität von Software auf ein neues Niveau heben
• Praktisch gesehen ist der richtige Umgang mit tatsächlich vorhandener Unsicherheit selbst die eigentliche Verbesserung in der realen Entwicklung

[GN⁺]

Hacker-News-Kommentare

• Die Unsicherheit von GPS lässt sich im Allgemeinen nur unter bestimmten Bedingungen, etwa bei langer Positionsbestimmung unter freiem Himmel, näherungsweise als kreisförmig annehmen; tatsächlich ist das gesamte Fehlermodell deutlich komplexer, und es gibt verschiedene Arten der Fehlermessung. Das ist in vielen Situationen wichtig, in denen man eine Position nur schwer als einzelnen Punkt behandeln kann. Bei autonomen Fahrzeugen etwa trifft man häufig auf Fälle, in denen die Unsicherheit der Positionsschätzung von nicht kreisförmigen Mehrwegeeffekten dominiert wird. Wenn man sich tief genug mit diesen Schwierigkeiten beschäftigt, landet man am Ende wieder bei Verfahren wie Partikelfiltern.
  • Fahrzeug-GPS wird normalerweise durch mehrere Sensoren und zusätzliche Annahmen ergänzt; insbesondere spielen Tacho, Kompass und das Wissen, dass sich das Fahrzeug auf einer der Straßen der Karte befinden wird, eine wichtige Rolle. Außerdem ermöglicht die Annahme, dass sich die Position zwischen dem letzten Ausschalten und dem Neustart nicht verändert hat, eine schnelle Positionsbestimmung.
  • Lidar-Punkte sind in Wirklichkeit keine einfachen Punkte, sondern eher Ellipsoide rund um die wahrscheinlichste Position.
• An der University of Cambridge wurde, inspiriert von Uncertain<T>(James Bornholt) und verwandter Forschung, eine Prozessor-Mikroarchitektur entworfen. Sie lädt nicht nur parametrische Verteilungen (Gaussian, Rayleigh usw.), sondern auch beliebige Stichprobenmengen in Register/Speicher, sodass sich nichtparametrische Verteilungen von Programmwerten durch arithmetische Operationen fortpflanzen. Auf Basis dieser Technik ist das Spin-off Signaloid am Markt aktiv, und ich forsche ebenfalls daran, dies auf Zustandsschätzung anzuwenden, etwa auf Partikelfilter. Link zum Paper
• Wenn man in der Programmierung das Konzept versteht, dass eine Variable die mathematische „Spezifikation“ einer Variable enthalten kann, eröffnen sich erstaunliche Möglichkeiten, die dem modernen AI zugrunde liegen. Wenn man an die vertraute Formel y = m * x + b denkt, ist sie, solange all diese Werte Literale sind, nur eine einfache Renderfunktion. Wenn die Variablen jedoch die gesamte Struktur des abgeleiteten Rechenwegs enthalten, kann man je nach Rechenrichtung Werte vorhersagen und rendern (Forward Pass) oder automatisch Gradienten/Ableitungen berechnen und damit sogar das Training neuronaler Netze verbinden. Wenn man diese Ergebnisse mathematisch sampelt, kann man die Gewichte gewinnen, die das Modell bilden. Jede Schicht im Deep Learning ist so konstruiert, und Systeme wie PyTorch können optimalen Code kompilieren, wenn man nur die Kombination der Operationen angibt. Mit anderen Worten: Uncertain<T> ist nur ein Ausgangspunkt, und es wäre ein sehr spannendes Experiment, sich vorzustellen, dass jede numerische Variable jederzeit als Metadaten möglicher Werte definiert werden kann und sich diese Metadaten so einfach manipulieren lassen wie ein Variablenwert.
  • Das klingt wirklich interessant. Ich frage mich, ob das jemand so erklären könnte, dass es auch für Leute wie mich leicht verständlich ist, die nicht viel Wissen über Machine Learning oder Mathematik haben.
  • Ich frage mich, ob es bei PL (Programmiersprachen) tatsächlich Beispiele gibt, die so ein Konzept auf Sprachebene unterstützen.
  • Dieser Kommentar scheint Variablen, Funktionen und lineare Systeme miteinander zu vermischen; ich glaube nicht, dass man das unbedingt alles zusammenwerfen muss.
• Ich frage mich, ob sich auf diese Weise auch die Kovarianz zwischen mehreren Variablen behandeln lässt. Zum Beispiel könnte schon die Position des gemessenen Objekts selbst fehlerbehaftet sein, und dieser Fehler könnte mit meinem Positionsfehler korreliert sein (umso mehr, wenn beide vom GPS zum gleichen Zeitpunkt gemessen wurden). Wenn das Typsystem nur univariate Modelle hat, wäre es zwar nützlich, aber wenn es auch Kovarianzen behandeln könnte, wäre eine deutlich mächtigere und genauere Nutzung möglich.
  • Mit einem samplingbasierten Ansatz ist Kovarianzmodellierung automatisch enthalten. Man muss Blattwerte, die in einem bestimmten Auswertungsvorgang mehrfach verwendet werden, nur einmal sampeln; im unten stehenden Code kann man sehen, dass die Implementierung tatsächlich so funktioniert. Uncertain.swift-Code
  • Ich frage mich schon lange, ob ein Programm Kovarianzen im praktischen Einsatz tatsächlich „lernen“ könnte. Wenn man Variablen unabhängig modelliert, scheint das fortlaufend von der Realität abzuweichen. Und in großen Programmen ist es praktisch unmöglich, die Korrelationen zwischen allen Variablenpaaren manuell zu berücksichtigen. Vielleicht muss man einen Ansatz entwerfen, der sie automatisch lernt.
  • Wenn man Kovarianz-Tracking braucht, kann ich auch empfehlen, sich die gvar-Bibliothek für Python anzusehen.
  • Wenn man Quantenmechanik wirklich korrekt modellieren wollte, müsste man jeder Menge miteinander verschränkter Variablen eine komplexwertige Wellenfunktion zuordnen.
• In Maschinenbauzeichnungen und ähnlichen Kontexten verwendet man zur Kommunikation mit Fertigungsfachkräften das Konzept der „Toleranz“, z. B. 10 cm +8 mm/-3 mm, um den zulässigen Bereich nach oben und unten klar anzugeben. Auch bei GPS-basierten Fragen wie „Sind wir fast da?“ dürfte es wichtig sein, die Richtungsabhängigkeit des Fehlers zu verstehen und je nach „Richtung“ der Unsicherheit zwischen besseren und schlechteren Fällen zu unterscheiden.
  • Ein Nachteil dieser Notation ist, dass sie in manchen Fällen bedeutet: „Der Maximal-/Minimalwert wird auf keinen Fall überschritten“, während sie in anderen Fällen als „Der Bereich wird nur mit 10 % Wahrscheinlichkeit überschritten“ interpretiert werden kann.
  • Ähnlich ist es mit der oft für Arbeitsplanung verwendeten Dreipunktschätzung (optimistisch, realistisch, pessimistisch). Selbst eine sehr einfache Wahrscheinlichkeitsverteilung schafft in allen Bereichen mit Unsicherheit deutlich mehr Klarheit.
• Dieses Konzept wurde in der Vergangenheit mehrfach unter dem Namen „Intervallarithmetik“ implementiert. Auch Boost und flint unterstützen das. Boost Interval flint(arb). Es wurde also immer wieder neu entdeckt, und ich frage mich, warum es trotzdem nie wirklich Mainstream geworden ist. Falls jemand es in der Praxis verwendet und wieder aufgegeben hat, würde ich gern davon hören.
  • Im Artikel wird erklärt, dass Uncertain<T> für GPS-Unsicherheit eine Rayleigh-Verteilung verwendet. Die Rayleigh-Verteilung ist keine Gleichverteilung, sondern modelliert reale Fehlerverteilungen besser. Wenn man zum Beispiel in der Boost-Bibliothek (-2,2)*(-2,2) berechnet, erhält man (-4,4), aber probabilistisch ist die gleichzeitige Realisierung der Extremwerte viel unwahrscheinlicher, sodass ungefähr (-2.35,2.35) realistischer wäre.
  • In der Physik lernt man Fehlerfortpflanzung früh. Wenn man annimmt, dass Fehler gaußverteilt sind, lässt sich das sehr elegant berechnen. In der Realität folgen die meisten Messwerte jedoch keiner Gauß-Verteilung, und nichtzufällige (systematische) Fehler sind problematisch. Das sauber zu behandeln ist schwierig, weshalb automatische Fehlerfortpflanzung oft kaum nützlich ist. In den meisten Fällen braucht man manuelle Analyse.
  • Ich verstehe nicht ganz, warum dieser Beitrag so viel Aufmerksamkeit bekommt; dieses Projekt unterstützt nicht nur Intervallarithmetik, sondern eine Vielzahl unterschiedlicher Unsicherheitsverteilungen.
  • Einfache Typen wie Boolean lassen sich leicht inferieren und haben klare Beschränkungen. Physikalische Unsicherheit ist dagegen komplex und muss je nach Domäne unterschiedlich modelliert werden. Wenn man sich ohnehin entscheidet, komplexe Unsicherheit zu behandeln, ist es sinnvoller, statt einer nur hübsch verpackten Bibliothek ein für den jeweiligen Zweck spezialisiertes Modell zu verwenden.
  • Intervallarithmetik ist bei der Rechengeschwindigkeit nur um einen konstanten Faktor langsamer als einfache numerische Operationen, also kein riesiger Unterschied, und für jede Operation gibt es ein eigenes präzisestes Intervallergebnis. Präzision ist jedoch nicht immer garantiert. Ein wie im Artikel samplingbasierter Rechengraph ist langsamer, kann sich dafür aber dem realen Fehlermodell genauer annähern. Das hat den Vorteil, dass kein abstrakter Bereich nötig ist, der Präzision wegnehmen würde.
• Der Datentyp, den ich gern bauen wollte, sollte ausdrücken, wie stark ein bestimmter Wert innerhalb einer gegebenen Wahrscheinlichkeitsverteilung (oder Wahrscheinlichkeitsdichtefunktion) bekannt ist. Gleichzeitig würde bei jedem Transformationsschritt entsprechend weitere Unsicherheit hinzukommen. Ich stelle mir einen Ablauf vor, in dem sich diese Menge von Wahrscheinlichkeitsverteilungen mit zunehmender Beobachtung (oder veränderter bedingter Klassifikation) immer weiter verfeinert. Das letztliche Ziel war, solche verteilungsbasierten Zufallsfall-Szenarien zu simulieren.
• Dieses Konzept steht auch in engem Zusammenhang mit dem alten Functional Pearl „Probability Functional Programming“. PDF-Link Wirklich großartig. Ich beginne die erste Stunde meines Haskell-Einführungskurses immer damit, das Monty-Hall-Problem mit einem Wahrscheinlichkeits-Monad vorzuführen und die Gewinnwahrscheinlichkeiten der beiden Strategien als ganzzahlige Brüche offen auszurechnen.
  • Siehe dazu auch die Haskell-Bibliothek monad-bayes zugehöriger Blogbeitrag
• Vielleicht wäre es gut, wenn Uncertain der Standardtyp wäre und man nur in wirklich sicheren Fällen explizit certain T angeben müsste.
  • Für physikalische Messwerte stimmt das vielleicht, aber Dinge wie Geldbeträge müssen bis auf die Nachkommastellen exakt sein. Übrigens wurde ein solcher Ansatz auch in einigen modernen Fortran-Bibliotheken implementiert.
  • Es könnte als Ergänzung zum Optional-Typ dienen.
• Ich frage mich, ob das asymptotisch eine Art Programmier-Version von Fuzzy Logic ist. Fuzzy Logic auf Wikipedia
  • Eher liegt es näher an probabilistic programming, einem bereits etablierten Gebiet; ein bekanntes Beispiel ist Pyro.