Uncertain<T>

 (nshipster.com)
3 ポイント 投稿者 GN⁺ 2025-08-29 | 1件のコメント | WhatsAppで共有
  • 不確実性をコードレベルで扱うための新しい抽象化である Uncertain<T> 型の概念を紹介
  • この型は 確率的プログラミング の方法論を適用し、従来のブール論理の代わりに値の信頼度や可能性をモデル化する
  • GPS、センサーデータなど ノイズの多い実世界データ を数学的な確率分布として扱う機能を提供
  • SPRT や Monte Carlo 手法など サンプリング技術によって計算効率 と結果の信頼度のバランスを支援
  • 既存コードとの 段階的な統合が可能 で、実務への適用性が高い

不確実性のコード化: 自信と実データのギャップ

  • 多くの人が 確信に過度に依存 する現象に言及
  • ソフトウェア開発の経験を積むほど、「場合による」と言う頻度が増えることを指摘
  • コードでは依然として真偽判定にのみ依存するパターンが繰り返されている
  • 特に GPS など 不確実なデータを扱いながらもブール値しか使わない 現実を批判
  • プログラミングモデルが現実の「不確実性」をあまりに早く二分化し、複雑さを覆い隠している

正しい抽象化の選択

  • 2014 年、University of Washington と Microsoft Research が 不確実性を型システムに直接反映 する概念を提案
  • 論文 "Uncertain<T>: A First-Order Type for Uncertain Data" を通じて 確率的プログラミング の方式が実用的であることを示した
  • Swift に概念を移植したコードを GitHub リポジトリ に公開
  • Uncertain<T> を使うと、比較結果も相対確率で表現 し、真/偽ではなく Uncertain<Bool> として結果を返す
  • GPS 位置誤差は Rayleigh 分布など実データの特性に合わせてモデル化する

さまざまな不確実性演算の実際

  • 複数の演算子と確率分布モデルをサポートし、演算グラフを構築して必要なときだけサンプリングを実行 する
  • SPRT(Sequential Probability Ratio Testing) により効率的なサンプル数調整を実現
  • 例示コードで、単純比較と複合比較それぞれに必要なサンプル数の違いを説明
  • このような抽象化により、不確実性を無視せず計算過程で自然に活用 することで、より「賢い」コードを実装できる

Monte Carlo 手法の適用

  • 確率分布の分析や期待値算出のために Monte Carlo サンプリング を導入
  • 実際にスロットマシンの結果値を繰り返しシミュレーションして 期待値を容易に導出 できる
  • 複雑な解析計算なしでも、コンピュータによる反復サンプリングだけで現実的な結果を得られる

豊富な確率分布モデリング

  • Uncertain<T> はさまざまな 確率分布コンストラクタ を内蔵し、各種センサーノイズ、ユーザー行動、ネットワークレイテンシなど現実世界のデータを精密にモデル化できる
  • 混合分布 (mixture)、Bernoulli、exponential、normal など、状況ごとのパラメータ化をサポート
  • 各分布の直感的理解を助けるため、インタラクティブな可視化プロジェクト も別途提供

統計および分析演算の提供

  • 期待値、標準偏差、信頼区間、歪度 (skewness)、尖度 (kurtosis)、エントロピー など多様な統計関数を提供
  • 演算結果ではサンプリング数も調整でき、精度と効率のトレードオフ が可能
  • 累積分布関数 (CDF) を活用し、特定の値以下である確率なども容易に計算できる

現実適用ガイド

  • 実際にアプリなどで 不確実性を無視したまま起こりうる問題 (例: ありえない GPS 速度表示など) を説明
  • 段階的な移行 を強調し、既存の距離測定など重要経路から部分的に Uncertain<T> を統合することを推奨
  • サンプル数など 計算コストの設定によって精度と性能のバランス調整 が可能
  • 実務では Instruments.app などのプロファイリングツールを積極的に活用 することを推奨
  • 目標は不確実性を取り除くことではなく、その存在自体を認めて適切に扱う開発パターンを確立すること

結論と展望

  • 開発者は 小さな領域から 不確実性の処理を導入し、使い勝手の改善やエラー緩和を期待できる
  • 完全な確実性は存在しないことを受け入れ、適切なツールと抽象化によってソフトウェアの品質を一段高める
  • 実質的には、存在する不確実性そのものを正しく扱うこと が真の実務的改善である

関連記事

1件のコメント

 
GN⁺ 2025-08-29
Hacker News の意見
  • GPS の不確実性は、一般には開けた空の下で長時間測位するなど特定の条件でのみ円形として近似でき、実際の誤差モデル全体ははるかに複雑で、さまざまな誤差の測り方が存在する。この点は、位置を 1 点として扱いにくくなる多くの状況で重要になる。たとえば自動運転車では、位置推定の不確実性が非円形のマルチパス現象に支配されるケースによく遭遇する。こうした難しさを深く考えていくと、結局はパーティクルフィルタのような手法を再発明するところに行き着く
    • 車載 GPS は通常、複数のセンサーや追加の仮定で補完される。特に速度計、コンパス、そして車両は地図上のどれかの道路上にいるはずだという知識が重要に働く。また、最後に電源を切ってから再起動するまでの間に位置変化がないという仮定によって、高速な測位が可能になる
    • LiDAR の点は、実際には単なる点ではなく、最も可能性の高い位置を中心とした楕円体として存在する
  • University of Cambridge で、Uncertain<T>（James Bornholt）と関連研究に触発されてプロセッサのマイクロアーキテクチャを設計した。パラメトリック分布（Gaussian、Rayleigh など）だけでなく、任意のサンプル集合をレジスタ／メモリにロードし、プログラムの値が非パラメトリック分布として算術演算に沿って伝播するように設計した。この技術をもとに Signaloid というスピンオフ企業が市場に参入しており、私もこれを状態推定（例: パーティクルフィルタ）に適用する研究を進めている。論文リンク
  • プログラミングにおいて、変数が数学的な変数の「仕様」を内包できるという概念を理解すると、現代 AI の基盤となる驚くべき可能性が開ける。よく知られた式 y = m * x + b を考えると、これらがすべてリテラルなら単なるレンダー関数にすぎない。しかし、変数が導出された演算経路の全体構造を保持しているなら、演算の向きに応じて値を予測してレンダリングしたり（フォワードパス）、自動的に勾配や微分を求めてニューラルネットワークの学習につなげたりできる。こうした出力結果を数学的にサンプリングすれば、モデルを構成する重みを獲得できる。ディープラーニングの各レイヤーはこのように設計されており、PyTorch のようなシステムは演算の組み合わせを記述するだけで最適なコードにコンパイルできる。つまり Uncertain<T> は出発点にすぎず、すべての数値変数がいつでも候補値のメタデータとして定義され、そのメタデータを変数値を足し合わせるのと同じくらい簡単に操作できると想像すると、とても興味深い実験になる
    • これは本当に面白そうだ。機械学習や数学の知識があまりない自分のような人にもわかるように説明してもらえるだろうか
    • PL（プログラミング言語）で、このような概念を言語レベルでサポートしている実例があるのか気になる
    • このコメントは変数、関数、線形システムをまとめて語っているように見えるが、あえてそこまで一緒くたにする必要はない気がする
  • 複数の変数間の共分散もこの方法で扱えるのか気になる。たとえば測定対象の物体の位置自体にも誤差があり得るし、自分の位置誤差とそれが相関している可能性もある（同じ時点の GPS 測定ならなおさら）。型システムに単変量モデルしかないなら有用ではあるだろうが、共分散まで扱えるなら、はるかに強力で正確に使えると思う
    • サンプリングベースのアプローチを使えば、共分散のモデリングは自動的に含まれる。特定の評価過程で複数回使われるリーフ値を 1 回だけサンプリングすればよく、実際にその実装がそうなっていることは以下のコードで確認できる。Uncertain.swift コード
    • プログラムが実運用の中で共分散を「学習」できるのか、ずっと前から気になっていた。変数を独立にモデリングしていると、現実からどんどんずれていきそうだし、大規模なプログラムであらゆる変数ペアの相関関係を手動で考慮するのは事実上不可能だ。もしかすると自動学習の仕組みを考える必要があるのかもしれない
    • 共分散追跡が必要なら、Python の gvar ライブラリ を試してみるのもおすすめだ
    • 量子力学をきちんとモデル化するなら、互いに絡み合った変数の集合ごとに複素数の波動関数を対応付ける必要がある
  • 機械工学の図面などで加工担当者とやり取りする際には、「公差」という概念を使う。例: 10cm +8mm/-3mm のように、許容範囲を上下にはっきり示す。GPS ベースの「もうほぼ着きましたか？」のような問いでも、誤差の方向性を理解し、不確実性の「向き」によって良し悪しを区別することが重要だと思う
    • この表記の惜しい点は、場合によっては「絶対に最大／最小範囲を超えない」という意味にも、「10% の確率でのみ範囲を超える」という意味にも解釈できることだ
    • 仕事の計画立案などでよく使われる三点見積もり（楽観的・現実的・悲観的）も似ている。非常に単純な確率分布であっても、不確実性が関わるあらゆる分野では、確率分布ベースの見方のほうがはるかに明確さを与えてくれる
  • この概念は過去にも何度も「区間演算（interval arithmetic）」という名前で実装されてきた。Boost や flint などでもサポートされている。Boost Interval flint(arb) これほど繰り返し再発見されているのに、なぜ本格的に主流にならないのか不思議だ。実際に現場で使ってみて微妙でやめた人がいたら、話を聞いてみたい
    • 本文では、Uncertain<T> が GPS の不確実性に Rayleigh 分布を使うと説明している。Rayleigh 分布は一様分布ではなく、現実世界の誤差分布をよりよくモデル化する。たとえば Boost ライブラリで (-2,2)*(-2,2) を計算すると (-4,4) になるが、実際の確率としては極端値が同時に起こる可能性はずっと低いので、おおよそ (-2.35,2.35) のほうが現実的だ
    • 物理では誤差伝播（error propagation）を早い段階で学ぶ。誤差がガウス分布だと仮定すれば非常に美しく計算できるが、実際には測定値の大半はガウス分布に従わず、非確率的な（系統的な）誤差が問題になり、それを適切に扱うのは難しいため、自動誤差伝播がほとんど役に立たないことも多い。たいていの場合は手動分析が必要になる
    • この投稿がなぜ注目されているのかよくわからない。このプロジェクトは区間演算だけでなく、さまざまな不確実性分布をサポートしている
    • 単純な Boolean などの型は簡単に推論でき、制約も明確だ。一方で物理的な不確実性は複雑で、ドメインごとにモデルを変える必要がある。いったん複雑な不確実性を扱うと決めた以上、単に見栄えよくパッケージ化されたライブラリよりも、その目的に特化した専門モデルを使うほうが望ましい
    • 区間演算は、演算速度が単純な数値演算より定数倍遅いだけで大差はなく、すべての演算に対して固有の最も精密な区間結果が存在する。しかし、精度が常に保証されるわけではない。本文のようにサンプリングする演算グラフは遅いものの、その代わり実際の誤差モデルにより正確に近づける。精度を奪う抽象ドメインが不要という利点もある
  • 自分が作りたかったデータ型は、ある値が与えられた確率分布（あるいは確率密度関数）の中でどの程度わかっているかを表現するものだ。そして各変換過程でも同じだけの不確実性が追加される。観測が増えるにつれて（あるいは条件付き分類が変わるにつれて）、この確率分布の集合が継続的に洗練されていく流れを想像している。最終的な目標は、こうした分布ベースのランダムな結果ケースをシミュレーションしてみることだった
  • この概念は、古い Functional Pearl「Probability Functional Programming」とも密接に関係している。PDF リンク 本当に素晴らしい。私は Haskell 入門の最初の授業で、Monty Hall 問題を確率モナドで実演するところから始め、2 つの戦略の勝率を整数の分数としてその場で計算して見せている
  • もしかすると Uncertain が基本型になって、本当に確実な場合にだけ certain T と明示するほうがよいのかもしれない
    • 物理測定値に限るならそうかもしれないが、通貨のような対象は小数点以下の単位まで正確でなければならない。ちなみに、このようなアプローチは一部の最新 Fortran ライブラリにも実装されている
    • Optional 型の補完として機能し得る
  • これは漸近的にプログラミング版のファジーロジック（fuzzy logic）なのだろうか Fuzzy Logic ウィキペディア