Uncertain<T>

• Uncertain<T> type की अवधारणा का परिचय, जो अनिश्चितता को code level पर संभालने के लिए एक नई abstraction है
• यह type probabilistic programming methodology लागू करके पारंपरिक boolean logic की जगह values के confidence या possibility को model करता है
• GPS, sensor data जैसी noise से भरी real-world data को mathematical probability distributions के रूप में संभालने की क्षमता देता है
• SPRT और Monte Carlo methods जैसी sampling techniques से computation efficiency और result confidence के बीच संतुलन का समर्थन करता है
• मौजूदा code के साथ gradual integration संभव है, इसलिए इसका practical applicability अच्छा है

---

अनिश्चितता को code में ढालना: confidence और real-world data के बीच की दूरी

• यह बताया गया है कि बहुत से लोग अत्यधिक certainty पर निर्भर रहते हैं
• यह इंगित किया गया है कि software development का अनुभव बढ़ने पर “it depends” कहने की आवृत्ति बढ़ जाती है
• फिर भी code में अब भी केवल true/false निर्णयों पर निर्भर पैटर्न दोहराए जाते हैं
• खासकर GPS जैसी अनिश्चित data को संभालते हुए भी केवल boolean values का उपयोग करने की वास्तविकता की आलोचना की गई है
• programming models वास्तविक दुनिया की ‘अनिश्चितता’ को बहुत जल्दी द्विआधारी बना देते हैं और उसकी complexity छिपा देते हैं

सही abstraction का चुनाव

• 2014 में University of Washington और Microsoft Research ने अनिश्चितता को सीधे type system में प्रतिबिंबित करने वाली अवधारणा प्रस्तावित की
• शोधपत्र "Uncertain<T>: A First-Order Type for Uncertain Data" के माध्यम से probabilistic programming approach के practical होने को सिद्ध किया गया
• इस concept को Swift में port किए गए code को GitHub repository में प्रकाशित किया गया
• Uncertain<T> का उपयोग करने पर comparison results भी relative probability के रूप में व्यक्त किए जाते हैं, और true/false की जगह result Uncertain<Bool> के रूप में लौटता है
• GPS position error को Rayleigh distribution जैसी वास्तविक data characteristics के अनुरूप model किया जाता है

विभिन्न uncertainty operations का व्यवहारिक रूप

• कई operators और probability distribution models का समर्थन किया जाता है, और operation graph बनाया जाता है, फिर ज़रूरत पड़ने पर ही sampling चलाई जाती है
• SPRT(Sequential Probability Ratio Testing) के जरिए sample count को कुशलता से नियंत्रित किया जाता है
• example code में simple comparison और composite comparison के लिए आवश्यक sample counts के अंतर को समझाया गया है
• इस abstraction के जरिए अनिश्चितता को नज़रअंदाज़ किए बिना, उसे computation process में स्वाभाविक रूप से उपयोग करके अधिक ‘smart’ code लिखा जा सकता है

Monte Carlo methodology का उपयोग

• probability distribution analysis और expected value estimation के लिए Monte Carlo sampling अपनाई गई है
• वास्तव में slot machine के result values को बार-बार simulate करके expected value आसानी से निकाली जा सकती है
• complex analytical calculation के बिना भी केवल computer-based repeated sampling से realistic results प्राप्त किए जा सकते हैं

समृद्ध probability distribution modeling

• Uncertain<T> में कई probability distribution constructors built-in हैं, जिनसे sensor noise, user behavior, network latency जैसी real-world data को बारीकी से model किया जा सकता है
• mixture distribution, Bernoulli, exponential, normal आदि कई परिस्थितियों के लिए parameterization का समर्थन है
• हर distribution की intuitive understanding में मदद के लिए interactive visualization project भी अलग से उपलब्ध कराया गया है

statistical और analytical operations की सुविधा

• expected value, standard deviation, confidence interval, skewness, kurtosis, entropy जैसी कई statistical functions उपलब्ध हैं
• operation results में sample count को समायोजित किया जा सकता है, जिससे precision और efficiency के बीच trade-off संभव होता है
• cumulative distribution function (CDF) का उपयोग करके किसी निश्चित value से कम या बराबर होने की probability भी आसानी से निकाली जा सकती है

real-world adoption guide

• वास्तव में apps आदि में अनिश्चितता को नज़रअंदाज़ करने पर पैदा हो सकने वाली समस्याओं (जैसे, बेतुकी GPS speed display) को समझाया गया है
• gradual transition पर ज़ोर दिया गया है: existing distance measurement जैसी critical paths से आंशिक रूप से Uncertain<T> को integrate करने की सिफारिश की गई है
• sample count जैसे computation cost settings के जरिए accuracy और performance के संतुलन को नियंत्रित किया जा सकता है
• practical work में Instruments.app जैसे profiling tools का सक्रिय उपयोग करने की सिफारिश की गई है
• लक्ष्य अनिश्चितता को खत्म करना नहीं, बल्कि उसके अस्तित्व को स्वीकार कर उसे सही ढंग से संभालने वाली development pattern स्थापित करना है

निष्कर्ष और आगे की दिशा

• developers से अपेक्षा की गई है कि वे छोटे क्षेत्रों से uncertainty handling शुरू करें, ताकि usability में सुधार और errors में कमी लाई जा सके
• यह स्वीकार करते हुए कि पूर्ण certainty जैसी कोई चीज़ नहीं होती, उपयुक्त tools और abstraction के जरिए software quality को एक स्तर ऊपर उठाया जा सकता है
• व्यावहारिक रूप से, मौजूद अनिश्चितता को सही तरीके से संभालना ही असली real-world improvement है

[GN⁺]

Hacker News टिप्पणियाँ

• GPS की अनिश्चितता को आम तौर पर केवल कुछ खास स्थितियों में ही वृत्ताकार रूप में अनुमानित किया जा सकता है, जैसे खुले आसमान के नीचे लंबे समय तक position fix करना। वास्तव में कुल error model इससे कहीं अधिक जटिल होता है और error को मापने के कई तरीके मौजूद हैं। यह बात उन कई स्थितियों में महत्वपूर्ण हो जाती है जहाँ location को एक अकेले point की तरह मानना मुश्किल होता है। उदाहरण के लिए, autonomous vehicles में अक्सर ऐसे मामले मिलते हैं जहाँ position estimation की uncertainty गैर-वृत्ताकार multipath प्रभावों से नियंत्रित होती है। इन कठिनाइयों पर गहराई से सोचते-सोचते अंततः आप particle filter जैसी तकनीकों को फिर से खोज निकालने की स्थिति तक पहुँच जाते हैं
  • वाहन GPS को आम तौर पर कई sensors और अतिरिक्त assumptions से पूरक बनाया जाता है। खास तौर पर speedometer, compass, और यह जानकारी कि वाहन नक्शे पर मौजूद सड़कों में से किसी एक पर ही होगा, महत्वपूर्ण भूमिका निभाते हैं। साथ ही, पिछली power-off से reboot तक location में कोई बदलाव नहीं हुआ होगा, इस मान्यता से fast fix संभव हो जाता है
  • Lidar points वास्तव में साधारण points नहीं होते, बल्कि सबसे अधिक संभावित location के केंद्र पर स्थित ellipsoid के रूप में मौजूद होते हैं
• University of Cambridge में Uncertain<T>(James Bornholt) और संबंधित research से प्रेरित होकर processor microarchitecture डिज़ाइन की गई। इसमें parametric distributions (Gaussian, Rayleigh आदि) के साथ-साथ मनचाहे sample sets को register/memory में load करके program values को arithmetic operations के साथ non-parametric distributions के रूप में propagate होने दिया गया। इसी तकनीक के आधार पर Signaloid नाम की एक spin-off कंपनी बाज़ार में उतर रही है, और मैं भी इसे state estimation (जैसे particle filter) में लागू करने पर research कर रहा हूँ पेपर लिंक
• अगर आप programming में इस विचार को समझ लें कि किसी variable में गणितीय variable की ‘specification’ भी समाहित हो सकती है, तो आधुनिक AI की नींव में मौजूद आश्चर्यजनक संभावनाएँ खुलती हैं। परिचित समीकरण y = m * x + b को सोचिए: जब ये सभी literal हों, तो यह सिर्फ एक साधारण render function है। लेकिन अगर variables अपने derivation path की पूरी संरचना को समेटे हुए हों, तो computation की दिशा के अनुसार values की भविष्यवाणी करके rendering (forward pass) की जा सकती है, या अपने-आप gradients/differentials निकालकर neural network training तक पहुँचा जा सकता है। इन outputs को गणितीय रूप से sample करने पर मॉडल बनाने वाले weights प्राप्त किए जा सकते हैं। Deep learning की हर layer इसी तरह डिज़ाइन की जाती है, और PyTorch जैसे systems केवल operations के composition को बताने पर भी optimal code में compile कर सकते हैं। यानी Uncertain<T> तो सिर्फ शुरुआत है; अगर आप कल्पना करें कि हर numeric variable को किसी भी समय candidate values के metadata के रूप में परिभाषित किया जा सके, और इस metadata को variable value जोड़ने जितनी आसानी से manipulate किया जा सके, तो यह बेहद दिलचस्प प्रयोग बन जाता है
  • यह सच में बहुत दिलचस्प लग रहा है। क्या कोई इसे मेरे जैसे व्यक्ति के लिए, जिसे machine learning या mathematics की ज़्यादा जानकारी नहीं है, आसानी से समझा सकता है?
  • जानना चाहता हूँ कि क्या PL (programming language) में ऐसे concepts को language level पर support करने के वास्तविक उदाहरण मौजूद हैं
  • लगता है यह टिप्पणी variables, functions, और linear systems को एक साथ मिला रही है; ज़रूरी नहीं कि इन्हें इस तरह मिलाया ही जाए
• जानना चाहता हूँ कि क्या इस तरीके से कई variables के बीच covariance भी संभाला जा सकता है। उदाहरण के लिए, मापे जा रहे object की location में भी error हो सकती है, और मेरी location error से उसका correlation भी हो सकता है (खासकर अगर GPS ने दोनों को एक ही समय पर मापा हो)। अगर type system में केवल univariate model हो तो उपयोगी तो होगा, लेकिन covariance तक संभाल सके तो यह कहीं ज़्यादा शक्तिशाली और सटीक होगा
  • sampling-based approach इस्तेमाल करें तो covariance modeling अपने-आप शामिल हो जाती है। किसी खास evaluation प्रक्रिया में कई बार इस्तेमाल होने वाले leaf values को केवल एक बार sample करना होता है, और वास्तव में implementation ऐसा ही करती है, यह नीचे के code में देखा जा सकता है Uncertain.swift कोड
  • मैं लंबे समय से सोचता रहा हूँ कि क्या कोई program वास्तविक उपयोग के दौरान covariance को ‘सीख’ सकता है। अगर variables को independent मानकर model किया जाए, तो वे लगातार वास्तविकता से भटकते रहेंगे। और बड़े programs में हर variable pair के correlation को हाथ से ध्यान में रखना लगभग असंभव है। शायद इसे अपने-आप सीखने का कोई तरीका निकालना होगा
  • अगर covariance tracking की ज़रूरत है, तो python की gvar लाइब्रेरी को देखना भी उपयोगी होगा
  • अगर quantum mechanics को सही ढंग से model करना हो, तो परस्पर entangled variables के हर set के साथ complex-valued wavefunction जोड़नी होगी
• mechanical engineering drawings आदि में machining workers से संवाद करने के लिए ‘tolerance’ की अवधारणा इस्तेमाल की जाती है, जैसे: 10cm +8mm/-3mm के रूप में अनुमेय सीमा को ऊपर-नीचे स्पष्ट दिखाया जाता है। GPS आधारित “क्या हम लगभग पहुँच गए हैं?” जैसे सवालों में भी error की directionality को समझना और uncertainty की ‘दिशा’ के अनुसार बेहतर/खराब स्थितियों में फर्क करना महत्वपूर्ण होगा
  • इस notation की कमी यह है कि कुछ मामलों में इसका अर्थ होता है “कभी भी maximum/minimum सीमा पार नहीं होगी”, जबकि दूसरे मामलों में इसे “केवल 10% संभावना से सीमा पार होगी” के रूप में समझा जा सकता है
  • काम की planning आदि में अक्सर इस्तेमाल होने वाला three-point estimation (optimistic, realistic, pessimistic) भी कुछ ऐसा ही है। बहुत simple probability distribution भी uncertainty वाले हर क्षेत्र में distribution-आधारित दृष्टिकोण को कहीं अधिक स्पष्ट बनाता है
• इस विचार को पहले भी कई बार ‘interval arithmetic’ नाम से implement किया गया है। Boost और flint आदि में भी इसका समर्थन है Boost Interval flint(arb). बार-बार फिर से खोजे जाने के बावजूद यह सचमुच mainstream क्यों नहीं बन पाया, यह जानना दिलचस्प है। अगर किसी ने इसे वास्तविक काम में इस्तेमाल करके छोड़ दिया हो, तो उसका अनुभव सुनना चाहूँगा
  • मूल लेख में बताया गया है कि Uncertain<T> GPS uncertainty के लिए Rayleigh distribution का उपयोग करता है। Rayleigh distribution uniform distribution नहीं है, बल्कि real-world error distribution को बेहतर मॉडल करती है। उदाहरण के लिए, Boost library में (-2,2)*(-2,2) की गणना (-4,4) देती है, लेकिन वास्तविक probability के हिसाब से extreme values का एक साथ आना बहुत कम संभव है, इसलिए लगभग (-2.35,2.35) अधिक यथार्थवादी होगा
  • physics में error propagation शुरुआती दौर में सिखाई जाती है। अगर error Gaussian distribution का पालन करे तो गणना बहुत सुंदर बनती है, लेकिन वास्तविकता में ज़्यादातर measurements Gaussian नहीं होते, non-probabilistic (systematic) errors समस्या बनते हैं, और इन्हें सही ढंग से संभालना कठिन होता है। इसलिए automatic error propagation कई बार लगभग बेकार साबित होती है; अधिकतर मामलों में manual analysis की ज़रूरत पड़ती है
  • समझ नहीं आता कि यह लेख इतना ध्यान क्यों खींच रहा है। यह project केवल interval arithmetic नहीं, बल्कि कई तरह की uncertainty distributions को support करता है
  • Boolean जैसे सरल types के लिए inference आसान होता है, इसलिए constraints भी स्पष्ट होते हैं। लेकिन physical uncertainty जटिल होती है, इसलिए domain के अनुसार model बदलना पड़ता है। और एक बार जब जटिल uncertainty को संभालने का फैसला कर ही लिया जाए, तो केवल सुंदर पैकेजिंग वाली library की बजाय उस उद्देश्य के लिए विशेष professional model का उपयोग अधिक उचित है
  • interval arithmetic केवल constant factor से साधारण numeric computation की तुलना में धीमी होती है, बहुत ज़्यादा नहीं, और हर operation के लिए उसका अपना uniquely most precise interval result मौजूद होता है। लेकिन precision हमेशा सुनिश्चित नहीं होती। इसके विपरीत, इस लेख की तरह sampling करने वाले operation graphs धीमे होते हैं, पर वास्तविक error model के कहीं अधिक करीब पहुँच सकते हैं। इनमें precision छीन लेने वाला abstract domain नहीं चाहिए, यह एक फायदा है
• मैं जिस data type को बनाना चाहता था, वह यह व्यक्त करे कि कोई मान किसी दिए गए probability distribution (या probability density function) के भीतर कितना जाना हुआ है। और हर transformation चरण में उतनी ही uncertainty भी जुड़ती जाए। जैसे-जैसे observations बढ़ें (या conditional classification बदलती जाए), इन probability distributions का समूह लगातार refine होता जाए—मैं कुछ ऐसा प्रवाह कल्पना कर रहा था। अंततः लक्ष्य था इन distribution-आधारित random outcome cases का simulation करना
• यह विचार पुराने Functional Pearl “Probability Functional Programming” से भी गहराई से जुड़ा है PDF लिंक, वाकई शानदार। मैं Haskell की शुरुआती कक्षा के पहले दिन Monty Hall problem को probability monad के साथ दिखाकर शुरू करता हूँ, और दोनों strategies की जीत की probability को integer fractions के रूप में साफ-साफ गणना करके दिखाता हूँ
  • Haskell की monad-bayes लाइब्रेरी भी साथ में देखने लायक है संबंधित ब्लॉग पोस्ट
• शायद अच्छा होगा अगर Uncertain default type बन जाए, और केवल सचमुच निश्चित होने पर ही अलग से certain T लिखना पड़े
  • physical measurements तक सीमित रखें तो यह सही लग सकता है, लेकिन money जैसी चीज़ों में decimal places तक सटीकता चाहिए होती है। जानकारी के लिए, ऐसा approach कुछ आधुनिक Fortran libraries में भी implement किया गया है
  • यह Optional type के पूरक के रूप में काम कर सकता है
• क्या यह asymptotically programming का एक version of fuzzy logic है, यह सोच रहा हूँ Fuzzy Logic विकिपीडिया
  • बल्कि इसे probabilistic programming के अधिक करीब माना जा सकता है। यह पहले से मौजूद क्षेत्र है, और इसका एक प्रमुख उदाहरण Pyro है