Uncertain<T>

• แนะนำแนวคิดของชนิดข้อมูล Uncertain<T> ซึ่งเป็น abstraction แบบใหม่สำหรับจัดการ ความไม่แน่นอน ในระดับโค้ด
• ชนิดข้อมูลนี้นำแนวทาง probabilistic programming มาใช้ เพื่อจำลองความเชื่อมั่นหรือความเป็นไปได้ของค่า แทนตรรกะบูลีนแบบดั้งเดิม
• รองรับการจัดการ ข้อมูลจริงที่มีสัญญาณรบกวนสูง เช่น GPS และข้อมูลจากเซ็นเซอร์ ด้วยการแทนเป็นการแจกแจงความน่าจะเป็นทางคณิตศาสตร์
• รองรับการสร้างสมดุลระหว่าง ประสิทธิภาพการคำนวณกับความน่าเชื่อถือของผลลัพธ์ ด้วยเทคนิคการสุ่มตัวอย่าง เช่น SPRT และ Monte Carlo
• สามารถ ผสานเข้ากับโค้ดเดิมได้แบบค่อยเป็นค่อยไป จึงเหมาะกับการนำไปใช้จริง

---

การทำให้ความไม่แน่นอนกลายเป็นโค้ด: ช่องว่างระหว่างความมั่นใจกับข้อมูลจริง

• กล่าวถึงปรากฏการณ์ที่หลายคน พึ่งพาความมั่นใจยืนยันมากเกินไป
• ชี้ให้เห็นว่าเมื่อมีประสบการณ์พัฒนาซอฟต์แวร์มากขึ้น ก็มักจะพูดว่า “ขึ้นอยู่กับสถานการณ์” บ่อยขึ้น
• แต่ในโค้ดก็ยังคงทำซ้ำรูปแบบที่พึ่งพาเพียงการตัดสินแบบจริง/เท็จ
• วิจารณ์แนวทางที่แม้จะต้องรับมือกับ ข้อมูลที่ไม่แน่นอน เช่น GPS แต่ก็ยังใช้เพียงค่าบูลีน
• โมเดลการเขียนโปรแกรมมักลดทอน ‘ความไม่แน่นอน’ ของโลกจริงให้กลายเป็นสองค่ารวดเร็วเกินไป จนซ่อนความซับซ้อนไว้

การเลือก abstraction ที่ถูกต้อง

• ในปี 2014 University of Washington และ Microsoft Research ได้เสนอแนวคิดที่ สะท้อนความไม่แน่นอนเข้าไปใน type system โดยตรง
• งานวิจัย "Uncertain<T>: A First-Order Type for Uncertain Data" แสดงให้เห็นว่าแนวทาง probabilistic programming ใช้งานได้จริง
• มีการพอร์ตแนวคิดนี้เป็น Swift และเผยแพร่โค้ดไว้ใน GitHub repository
• เมื่อใช้ Uncertain<T> ผลของการเปรียบเทียบก็จะแสดงเป็นความน่าจะเป็นสัมพัทธ์ และคืนค่าเป็น Uncertain<Bool> แทนที่จะเป็นจริง/เท็จ
• ความคลาดเคลื่อนของตำแหน่ง GPS ถูกจำลองให้สอดคล้องกับคุณลักษณะของข้อมูลจริง เช่น การแจกแจงแบบ Rayleigh

การทำงานจริงของการดำเนินการกับความไม่แน่นอนที่หลากหลาย

• รองรับโอเปอเรเตอร์และโมเดลการแจกแจงความน่าจะเป็นหลายแบบ พร้อม สร้างกราฟการคำนวณและสุ่มตัวอย่างเมื่อจำเป็นเท่านั้น
• ใช้ SPRT(Sequential Probability Ratio Testing) เพื่อปรับจำนวนตัวอย่างอย่างมีประสิทธิภาพ
• ในโค้ดตัวอย่างมีการอธิบายความแตกต่างของจำนวนตัวอย่างที่ต้องใช้ ระหว่างการเปรียบเทียบแบบง่ายกับแบบซับซ้อน
• abstraction นี้ช่วยให้ ไม่มองข้ามความไม่แน่นอน แต่ใช้มันอย่างเป็นธรรมชาติในกระบวนการคำนวณ จนทำให้สร้างโค้ดที่ ‘ฉลาดกว่า’ ได้

การประยุกต์ใช้แนวทาง Monte Carlo

• นำ Monte Carlo sampling มาใช้เพื่อวิเคราะห์การแจกแจงความน่าจะเป็นและคำนวณค่าคาดหมาย
• สามารถจำลองผลลัพธ์ของสล็อตแมชชีนซ้ำ ๆ เพื่อ หาค่าคาดหมายได้อย่างง่ายดาย
• สร้างผลลัพธ์ที่สมจริงได้แม้ไม่ต้องคำนวณเชิงวิเคราะห์ที่ซับซ้อน เพียงอาศัยการสุ่มซ้ำด้วยคอมพิวเตอร์

การสร้างแบบจำลองการแจกแจงความน่าจะเป็นที่หลากหลาย

• Uncertain<T> มี ตัวสร้างการแจกแจงความน่าจะเป็น หลายแบบในตัว ทำให้สามารถจำลองข้อมูลโลกจริงอย่างละเอียด เช่น สัญญาณรบกวนจากเซ็นเซอร์ พฤติกรรมผู้ใช้ และ network latency
• รองรับการกำหนดพารามิเตอร์สำหรับหลายสถานการณ์ เช่น mixture distribution, Bernoulli, exponential, normal
• ยังมี โครงการภาพแบบโต้ตอบ แยกต่างหาก เพื่อช่วยให้เข้าใจการแจกแจงแต่ละแบบได้อย่างเป็นสัญชาตญาณมากขึ้น

มีการดำเนินการด้านสถิติและการวิเคราะห์ให้ใช้งาน

• มีฟังก์ชันสถิติหลากหลาย เช่น ค่าคาดหมาย, ส่วนเบี่ยงเบนมาตรฐาน, ช่วงความเชื่อมั่น, ความเบ้ (skewness), ความโด่ง (kurtosis), เอนโทรปี
• ผลลัพธ์ของการคำนวณสามารถปรับจำนวนตัวอย่างได้ จึง แลกเปลี่ยนระหว่างความแม่นยำกับประสิทธิภาพได้
• ยังใช้ cumulative distribution function (CDF) เพื่อคำนวณความน่าจะเป็นของการมีค่าน้อยกว่าหรือเท่ากับค่าหนึ่งได้อย่างสะดวก

แนวทางการนำไปใช้ในโลกจริง

• อธิบายปัญหาที่อาจเกิดขึ้นจริงในแอปเมื่อ มองข้ามความไม่แน่นอน เช่น การแสดงความเร็ว GPS ที่ผิดเพี้ยนอย่างมาก
• เน้นการ เปลี่ยนผ่านแบบค่อยเป็นค่อยไป โดยแนะนำให้เริ่มผสาน Uncertain<T> จากเส้นทางหลักอย่างการวัดระยะทางก่อน
• สามารถ ปรับสมดุลความแม่นยำและประสิทธิภาพ ได้ด้วยการตั้งค่าต้นทุนการคำนวณ เช่น จำนวนตัวอย่าง
• ในงานจริงแนะนำให้ใช้เครื่องมือ profiling อย่าง Instruments.app อย่างจริงจัง
• เป้าหมายไม่ใช่การกำจัดความไม่แน่นอน แต่คือ ยอมรับการมีอยู่ของมันและสร้างรูปแบบการพัฒนาที่รับมือได้อย่างเหมาะสม

บทสรุปและมุมมองต่อไป

• นักพัฒนาสามารถเริ่มนำการจัดการความไม่แน่นอนมาใช้จาก ขอบเขตเล็ก ๆ ก่อน เพื่อปรับปรุงการใช้งานและลดข้อผิดพลาด
• ยอมรับว่าความแน่นอนอย่างสมบูรณ์ไม่มีอยู่จริง และใช้เครื่องมือกับ abstraction ที่เหมาะสมเพื่อยกระดับคุณภาพของซอฟต์แวร์ขึ้นอีกขั้น
• ในทางปฏิบัติ การจัดการกับความไม่แน่นอนที่มีอยู่จริงให้ถูกต้อง คือการปรับปรุงงานพัฒนาอย่างแท้จริง

[GN⁺]

ความเห็นบน Hacker News

• ความไม่แน่นอนของ GPS โดยทั่วไปจะประมาณเป็นวงกลมได้ก็เฉพาะในเงื่อนไขบางอย่าง เช่น การหาตำแหน่งเป็นเวลานานใต้ท้องฟ้าเปิดโล่ง แต่ในความเป็นจริงโมเดลความคลาดเคลื่อนโดยรวมซับซ้อนกว่านั้นมาก และมีวิธีวัดความคลาดเคลื่อนหลายแบบ ประเด็นนี้สำคัญในหลายสถานการณ์ที่ทำให้ยากจะมองตำแหน่งเป็นเพียงจุดเดียว เช่น ในรถขับเคลื่อนอัตโนมัติมักเจอกรณีที่ความไม่แน่นอนของการประมาณตำแหน่งถูกครอบงำโดยปรากฏการณ์ multipath ที่ไม่เป็นวงกลม เมื่อลงลึกกับปัญหาแบบนี้มากพอ สุดท้ายก็มักจะไปจบที่การคิดค้นเทคนิคอย่าง particle filter ขึ้นมาใหม่
  • GPS สำหรับยานยนต์มักเสริมด้วยหลายเซ็นเซอร์และสมมติฐานเพิ่มเติม โดยเฉพาะมาตรวัดความเร็ว เข็มทิศ และความรู้ว่ารถน่าจะอยู่บนถนนเส้นใดเส้นหนึ่งในแผนที่ นอกจากนี้ยังสามารถหาตำแหน่งได้เร็วขึ้นโดยอาศัยสมมติฐานว่าตำแหน่งจะไม่เปลี่ยนระหว่างช่วงปิดเครื่องครั้งล่าสุดถึงการเปิดเครื่องอีกครั้ง
  • จุดจาก LiDAR แท้จริงแล้วไม่ใช่แค่จุดธรรมดา แต่มีอยู่ในรูปทรงรีที่มีศูนย์กลางเป็นตำแหน่งที่เป็นไปได้มากที่สุด
• ที่ University of Cambridge มีการออกแบบไมโครสถาปัตยกรรมของโปรเซสเซอร์โดยได้รับแรงบันดาลใจจาก Uncertain<T> (James Bornholt) และงานวิจัยที่เกี่ยวข้อง โดยไม่ได้รองรับแค่การกระจายแบบพาราเมตริก (เช่น Gaussian, Rayleigh) แต่ยังออกแบบให้โหลดชุดตัวอย่างแบบใดก็ได้เข้าไปในรีจิสเตอร์/หน่วยความจำ เพื่อให้ค่าของโปรแกรมแพร่กระจายไปตามการคำนวณเชิงเลขในรูปของการกระจายแบบไม่อิงพารามิเตอร์ บนพื้นฐานของเทคโนโลยีนี้มีบริษัทสปินออฟชื่อ Signaloid กำลังเข้าสู่ตลาด และฉันเองก็กำลังทำวิจัยเพื่อนำมันไปใช้กับการประมาณสถานะ (เช่น particle filter) ลิงก์งานวิจัย
• ถ้าเข้าใจแนวคิดที่ว่าตัวแปรในโปรแกรมสามารถบรรจุ "คำอธิบายจำเพาะ" ของตัวแปรทางคณิตศาสตร์ไว้ได้ ก็จะเปิดความเป็นไปได้อันน่าทึ่งซึ่งเป็นรากฐานของ AI สมัยใหม่ ลองนึกถึงสมการคุ้นเคยอย่าง y = m * x + b ถ้าทั้งหมดเป็นลิเทอรัล มันก็เป็นเพียงฟังก์ชันเรนเดอร์ธรรมดา แต่ถ้าตัวแปรเหล่านี้เก็บโครงสร้างทั้งหมดของเส้นทางการคำนวณที่สร้างมันขึ้นมาไว้ด้วย เราก็สามารถพยากรณ์ค่าเพื่อเรนเดอร์ได้ตามทิศทางของการคำนวณ (forward pass) หรือคำนวณ gradient/อนุพันธ์โดยอัตโนมัติเพื่อไปต่อถึงการฝึกโครงข่ายประสาทได้ การสุ่มตัวอย่างผลลัพธ์เหล่านี้ในเชิงคณิตศาสตร์ทำให้ได้ค่าน้ำหนักที่ก่อรูปเป็นโมเดล เลเยอร์แต่ละชั้นใน deep learning ถูกออกแบบในลักษณะนี้ และระบบอย่าง PyTorch ก็สามารถคอมไพล์ให้เป็นโค้ดที่เหมาะที่สุดได้เพียงแค่ระบุการประกอบของการคำนวณ ดังนั้น Uncertain<T> จึงเป็นเพียงจุดเริ่มต้นเท่านั้น ถ้าลองจินตนาการว่าตัวแปรเชิงตัวเลขทุกตัวสามารถนิยามด้วยเมทาดาทาของค่าผู้สมัครได้ตลอดเวลา และเราสามารถจัดการเมทาดาทานี้ได้ง่ายพอ ๆ กับการบวกค่าตัวแปร ก็ถือเป็นการทดลองที่น่าสนใจมาก
  • ฟังดูน่าสนใจจริง ๆ อยากรู้ว่าจะมีคำอธิบายที่คนอย่างฉันซึ่งไม่ได้มีความรู้ด้านแมชชีนเลิร์นนิงหรือคณิตศาสตร์มากนักเข้าใจได้ง่ายหรือไม่
  • อยากรู้ว่ามีภาษา PL (programming language) ไหนบ้างที่รองรับแนวคิดแบบนี้ในระดับภาษาอย่างแท้จริง
  • ความเห็นนี้ดูเหมือนจะเอาเรื่องตัวแปร ฟังก์ชัน และระบบเชิงเส้นมาปนกันไปหมด ซึ่งจริง ๆ แล้วไม่น่าจำเป็นต้องรวมกันแบบนี้
• อยากรู้ว่าวิธีนี้จัดการ covariance ระหว่างหลายตัวแปรได้ด้วยหรือไม่ เช่น ตำแหน่งของวัตถุที่วัดเองก็อาจมีความคลาดเคลื่อน และอาจมีความสัมพันธ์กับความคลาดเคลื่อนของตำแหน่งของฉันเองด้วย (ยิ่งถ้าวัดด้วย GPS ในช่วงเวลาเดียวกันก็ยิ่งเป็นไปได้) ถ้าระบบชนิดข้อมูลมีแค่โมเดลตัวแปรเดี่ยวก็ยังพอมีประโยชน์ แต่ถ้าจัดการ covariance ได้ด้วยก็น่าจะทรงพลังและใช้งานได้แม่นยำกว่ามาก
  • ถ้าใช้แนวทางแบบอิงการสุ่มตัวอย่าง การสร้างแบบจำลอง covariance จะถูกรวมมาให้อัตโนมัติ แค่สุ่มตัวอย่างค่า leaf ที่ถูกใช้หลายครั้งในกระบวนการประเมินหนึ่งครั้งเพียงครั้งเดียว ซึ่งจากโค้ดด้านล่างก็เห็นได้ว่าการติดตั้งนี้ทำแบบนั้นจริง โค้ด Uncertain.swift
  • ฉันสงสัยมานานแล้วว่าโปรแกรมจะสามารถ "เรียนรู้" covariance ระหว่างการใช้งานจริงได้หรือไม่ ถ้าจำลองตัวแปรแบบเป็นอิสระต่อกันไปเรื่อย ๆ ก็น่าจะยิ่งเบี่ยงจากความเป็นจริง และในโปรแกรมขนาดใหญ่ก็แทบเป็นไปไม่ได้เลยที่จะพิจารณาความสัมพันธ์ของตัวแปรทุกคู่ด้วยมือ บางทีคงต้องคิดวิธีให้มันเรียนรู้อัตโนมัติ
  • ถ้าต้องการติดตาม covariance ก็แนะนำให้ลองใช้ ไลบรารี gvar ของ python
  • ถ้าจะจำลองกลศาสตร์ควอนตัมอย่างถูกต้อง ก็ต้องผูก wavefunction แบบจำนวนเชิงซ้อนเข้ากับแต่ละชุดของตัวแปรที่พัวพันกัน
• เวลาสื่อสารกับช่างผู้ปฏิบัติงานในงานอย่างแบบเขียนวิศวกรรมเครื่องกล มักใช้แนวคิดเรื่อง "ค่าความคลาดเคลื่อนที่ยอมรับได้" เช่น 10cm +8mm/-3mm โดยระบุช่วงที่ยอมรับได้ด้านบนและล่างอย่างชัดเจน คำถามอย่าง "เกือบถึงแล้วหรือยัง?" ที่อิง GPS ก็ควรจะสำคัญไม่แพ้กันที่จะเข้าใจทิศทางของความคลาดเคลื่อน และแยกกรณีที่ดีกว่าหรือแย่กว่าออกตาม "ทิศทาง" ของความไม่แน่นอน
  • จุดอ่อนของสัญกรณ์นี้คือ บางกรณีอาจหมายถึง "จะไม่มีวันเกินค่ามากสุด/น้อยสุดเด็ดขาด" ขณะที่บางกรณีอาจตีความว่า "มีโอกาสเพียง 10% ที่จะเกินช่วงดังกล่าว"
  • วิธีประเมินแบบสามจุด (มองโลกในแง่ดี สมจริง มองโลกในแง่ร้าย) ที่มักใช้ในการวางแผนงานก็คล้ายกัน แม้จะเป็นการกระจายความน่าจะเป็นที่เรียบง่ายมาก แต่ในทุกสาขาที่มีความไม่แน่นอนเข้ามาเกี่ยวข้อง มุมมองแบบอิงการกระจายความน่าจะเป็นก็ให้ความชัดเจนกว่ามาก
• แนวคิดนี้เคยถูกทำมาแล้วหลายครั้งในชื่อ "interval arithmetic" โดยมีทั้งใน Boost และ flint Boost Interval flint(arb) ทั้งที่ถูกค้นพบซ้ำอยู่เรื่อย ๆ ก็ยังสงสัยว่าทำไมมันถึงไม่กลายเป็นกระแสหลักจริงจัง ถ้าใครเคยลองใช้ในงานจริงแล้วรู้สึกว่าไม่เวิร์กจนเลิกใช้ ก็อยากฟังประสบการณ์
  • ในบทความอธิบายว่า Uncertain<T> ใช้การกระจายแบบ Rayleigh กับความไม่แน่นอนของ GPS ซึ่ง Rayleigh ไม่ใช่การกระจายแบบสม่ำเสมอ แต่จำลองการกระจายของความคลาดเคลื่อนในโลกจริงได้ดีกว่า เช่น ถ้าคำนวณ (-2,2)*(-2,2) ในไลบรารี Boost จะได้ (-4,4) แต่ในเชิงความน่าจะเป็นแล้วโอกาสที่ค่าปลายสุดทั้งสองจะเกิดพร้อมกันต่ำกว่ามาก ดังนั้นค่าประมาณราว ๆ (-2.35,2.35) จึงสมจริงกว่า
  • ในวิชาฟิสิกส์เราจะเรียนเรื่องการแพร่กระจายของความคลาดเคลื่อน (error propagation) ตั้งแต่ช่วงต้น ถ้าสมมติว่าความคลาดเคลื่อนเป็นการกระจายแบบ Gaussian จะคำนวณได้สวยงามมาก แต่ในความเป็นจริงค่าที่วัดได้ส่วนใหญ่ไม่ได้เป็น Gaussian และความคลาดเคลื่อนแบบไม่ใช่ความน่าจะเป็น (systematic error) ก็เป็นปัญหา ซึ่งจัดการให้ดีได้ยาก จึงทำให้การแพร่กระจายความคลาดเคลื่อนแบบอัตโนมัติมักใช้งานจริงได้น้อย ในกรณีส่วนใหญ่ต้องวิเคราะห์ด้วยมือ
  • ฉันไม่ค่อยเข้าใจว่าทำไมบทความนี้ถึงได้รับความสนใจ เพราะโปรเจ็กต์นี้ไม่ได้รองรับแค่ interval arithmetic แต่รองรับการกระจายของความไม่แน่นอนหลายแบบด้วย
  • ชนิดข้อมูลง่าย ๆ อย่าง Boolean สามารถอนุมานได้ง่ายจึงมีข้อจำกัดชัดเจน ตรงกันข้าม ความไม่แน่นอนทางกายภาพนั้นซับซ้อนและแต่ละโดเมนก็ต้องใช้โมเดลต่างกัน พอตัดสินใจจะจัดการกับความไม่แน่นอนที่ซับซ้อนแล้ว การใช้โมเดลผู้เชี่ยวชาญที่ออกแบบมาเฉพาะจุดประสงค์นั้นย่อมเหมาะสมกว่าการใช้เพียงไลบรารีที่แพ็กเกจมาสวยงาม
  • interval arithmetic ช้ากว่าการคำนวณเชิงตัวเลขธรรมดาเพียงในระดับค่าคงที่เท่านั้น ไม่ได้ต่างมหาศาล และสำหรับทุกการดำเนินการก็มีผลลัพธ์แบบช่วงที่แม่นที่สุดเฉพาะตัวอยู่เสมอ อย่างไรก็ตาม ความแม่นยำไม่ได้รับประกันเสมอไป ในทางกลับกัน กราฟการคำนวณแบบสุ่มตัวอย่างอย่างในบทความนี้ช้ากว่า แต่เข้าใกล้โมเดลความคลาดเคลื่อนจริงได้แม่นยำกว่า และมีข้อดีตรงที่ไม่ต้องยอมเสียความแม่นยำให้กับ abstract domain
• ชนิดข้อมูลที่ฉันอยากสร้างคือสิ่งที่แสดงให้เห็นว่าค่าหนึ่ง ๆ เป็นที่รู้จักมากน้อยเพียงใดภายในกรอบของการกระจายความน่าจะเป็นที่กำหนดไว้ (หรือฟังก์ชันความหนาแน่นความน่าจะเป็น) และในแต่ละขั้นของการแปลงก็จะมีความไม่แน่นอนเพิ่มเข้ามาเท่ากัน เมื่อมีการสังเกตเพิ่มขึ้น (หรือการจัดหมวดหมู่แบบมีเงื่อนไขเปลี่ยนไป) ก็จินตนาการได้ว่าชุดของการกระจายความน่าจะเป็นนี้จะถูกปรับให้ละเอียดขึ้นเรื่อย ๆ เป้าหมายสุดท้ายคือการจำลองกรณีผลลัพธ์แบบสุ่มที่อิงการกระจายเหล่านี้
• แนวคิดนี้เกี่ยวข้องอย่างใกล้ชิดกับ Functional Pearl เก่าเรื่อง “Probability Functional Programming” เช่นกัน ลิงก์ PDF เจ๋งมาก ฉันเริ่มคาบแรกของวิชาแนะนำ Haskell ด้วยการสาธิตปัญหา Monty Hall ผ่าน probability monad และคำนวณความน่าจะเป็นชนะของสองกลยุทธ์ออกมาเป็นเศษส่วนจำนวนเต็มแบบให้เห็นชัด ๆ
  • ถ้าสนใจก็ควรดูไลบรารี monad-bayes ของ Haskell เพิ่มด้วย บทความบล็อกที่เกี่ยวข้อง
• บางที Uncertain อาจควรเป็นชนิดข้อมูลพื้นฐานไปเลย และมีแค่กรณีที่แน่นอนจริง ๆ เท่านั้นที่ค่อยระบุเป็น certain T แยกต่างหาก
  • ถ้าจำกัดเฉพาะค่าที่ได้จากการวัดทางกายภาพก็อาจใช่ แต่สิ่งอย่างเงินตราต้องแม่นยำถึงหน่วยทศนิยมย่อย ๆ และจริง ๆ แล้วแนวทางแบบนี้ก็ถูกนำไปใช้ในไลบรารี Fortran สมัยใหม่บางตัวอยู่แล้ว
  • มันอาจทำหน้าที่เป็นตัวเสริมของชนิดข้อมูล Optional ได้
• สงสัยว่าสุดท้ายแล้วนี่จะเป็น fuzzy logic ฉบับการเขียนโปรแกรมแบบค่อย ๆ เข้าใกล้หรือไม่ Fuzzy Logic วิกิพีเดีย
  • ที่จริงน่าจะใกล้กับ probabilistic programming มากกว่า ซึ่งเป็นสาขาที่มีอยู่แล้ว และตัวอย่างที่เด่นก็คือ Pyro