NumPy 2.5.4 ยอมหยุดคำนวณ ดีกว่าปล่อยตัวเลขผิดเข้ารายงาน

NumPy 2.5.4 เปลี่ยนการคำนวณบางงานที่เจอค่าอนันต์ ให้แจ้งข้อผิดพลาดแทนคืนผลลัพธ์ผิด ตาม บันทึกรุ่นของ NumPy ครับ รุ่นนี้ออกเมื่อ 10 ต.ค. 2026 แปลว่าเป็นอัปเดตที่ประกาศแล้ว ไม่ใช่แผนแก้ในอนาคต ตาม ประกาศบน GitHub

สำหรับคนทำรายงานยอดขาย วิเคราะห์ข้อมูลเรียน หรือส่งตัวเลขให้เจ้าของร้าน ความเปลี่ยนแปลงนี้ควรอยู่ในรายการตรวจงานก่อนอัปเดต ถ้าสมุดงาน Python เคยทำต่อจนจบ ทั้งที่ข้อมูลบางช่องใช้คำนวณไม่ได้ รอบใหม่อาจหยุดให้เห็นปัญหาแทน นี่เป็นผลที่ควรเตรียมรับมือจากการเปลี่ยนพฤติกรรม ไม่ใช่หลักฐานว่ารายงานเก่าของทุกคนผิดครับ

สรุป 30 วินาที: เกิดอะไรขึ้น

NumPy คือชุดเครื่องมือช่วยคำนวณข้อมูลตัวเลขในภาษา Python ส่วนคำว่า patch release หมายถึงรุ่นแก้บั๊กหรือข้อผิดพลาดของโปรแกรม Charles R Harris ประกาศผ่าน Python-announce ว่ารุ่นนี้แก้ปัญหาที่พบหลังรุ่นก่อนหน้า พร้อมปรับข้อมูลชนิดตัวแปรและเพิ่มวิธีหลบปัญหาของเครื่องมือสร้างโปรแกรมบน Windows

จุดสำคัญต่อความถูกต้องของตัวเลขอยู่ที่ numpy.linalg.svd และ numpy.linalg.lstsq คำแรกเป็นการแยกข้อมูลตัวเลขเป็นส่วนประกอบทางคณิตศาสตร์ ส่วนคำหลังเป็นการหาคำตอบแบบกำลังสองน้อยที่สุด ซึ่งเกี่ยวข้องกับงานหาความสัมพันธ์จากข้อมูล ทั้งสองคำสั่งจะส่งข้อผิดพลาดเมื่อข้อมูลมีค่าอนันต์ แทนผลลัพธ์ที่บันทึกรุ่นเรียกว่าใช้ไม่ได้ ตาม NumPy

รุ่นนี้ยังแก้การค้างของคำสั่งดังกล่าว เมื่อเจอข้อมูลอนันต์บางแบบร่วมกับชุดคำนวณเบื้องหลังบางรุ่น และทำให้ numpy.linalg.cond รับมือข้อมูลที่ไม่ใช่ค่าจำกัดได้สม่ำเสมอขึ้น ตาม GitHub ขอบเขตที่ประกาศคือ Python 3.12–3.15 แปลว่าต้องตรวจภาษา Python ในเครื่องควบคู่กับตัว NumPy ไม่ใช่ดูชื่อแพ็กเกจอย่างเดียว ตาม Python-announce

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

พนักงานที่รับเฉพาะกราฟหรือรายงานปลายทางอาจไม่เห็นว่าข้อมูลก่อนคำนวณมีอะไรอยู่บ้าง ถ้างานของทีมใช้คำสั่งที่ประกาศแก้ ผลลัพธ์เก่าที่ออกมาได้จึงควรมีการตรวจเพิ่มเติมเมื่อพบข้อมูลอนันต์ เพราะ บันทึกรุ่น ระบุชัดว่าพฤติกรรมเดิมอาจคืนผลลัพธ์ที่ใช้ไม่ได้ ไม่ได้ระบุว่าการรันจบยืนยันความถูกต้อง

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

ส่วนผู้ปกครองหรือเจ้าของธุรกิจที่ไม่ได้เขียนโค้ดเอง ไม่ต้องเริ่มจากการติดตั้งอะไรครับ คำถามที่ใช้คุยกับคนทำรายงานคือ งานนี้ตรวจค่าที่คำนวณไม่ได้ก่อนสร้างข้อสรุปหรือยัง? นี่เป็นคำถามเรื่องคุณภาพข้อมูลที่นำไปตัดสินใจ มากกว่าการจำชื่อฟังก์ชันให้ได้ทั้งหมด

ทำงานยังไง

ค่าอนันต์ต่างจากตัวเลขที่สูงมากแต่ยังมีค่าจำกัด ส่วน NaN เป็นสัญลักษณ์ของค่าที่ไม่ใช่ตัวเลข และคำว่า non-finite ในข่าวนี้รวมข้อมูลที่ไม่ใช่ค่าจำกัด ก่อนอ่านต่อควรแยกสองอย่างนี้ไว้ เพราะ NumPy ระบุการส่งข้อผิดพลาดของ svd กับ lstsq โดยเจาะจงอินพุตที่มีค่าอนันต์ ขณะที่ข้อความเรื่อง cond ใช้คำว่า non-finite

linalg คือกลุ่มคำสั่งด้านพีชคณิตเชิงเส้น หรือการคำนวณกับข้อมูลตัวเลขที่จัดเป็นชุดและตาราง สำหรับคนทั่วไป สิ่งที่ต้องรู้คือข้อมูลไม่เหมาะสมอาจทำให้ผลที่ได้ใช้สรุปงานไม่ได้ รุ่นนี้จึงเปลี่ยนให้คำสั่งที่ระบุหยุดด้วยข้อผิดพลาด ตาม GitHub ไม่ได้เปลี่ยนข้อมูลเสียให้กลายเป็นข้อมูลดีโดยอัตโนมัติ

ลองเทียบกับเครื่องชั่งในตลาดที่เคยโชว์ตัวเลขมั่วเมื่อของหนักเกินพิกัด ตอนนี้เครื่องร้องเตือนแทน คนขายอาจเสียเวลายกของลงแล้วชั่งใหม่ แต่ไม่ควรใช้เลขที่เครื่องแสดงมั่วไปคิดเงิน การคำนวณที่หยุดให้ตรวจข้อมูลก็มีประโยชน์ลักษณะเดียวกันครับ เครื่องไม่ได้ขายของช้าลงเพราะอยากพักเที่ยง

ปัญหาการค้างเกี่ยวข้องกับ LAPACK ซึ่งเป็นชุดคำสั่งคำนวณเบื้องหลัง บันทึกรุ่นระบุว่าเกิดกับอินพุตอนันต์บางแบบ และรุ่นใหม่บางรุ่นของ LAPACK บางชุด ตาม NumPy จึงควรอ่านว่าเป็นการแก้เงื่อนไขเฉพาะ ไม่ใช่รับรองว่าคำสั่งเหล่านี้จะไม่มีทางค้างจากสาเหตุอื่น

สำหรับ cond ซึ่งใช้ประเมินความไวของปัญหาคำนวณต่อความเปลี่ยนแปลงของข้อมูล ประกาศบอกเพียงว่าจัดการอินพุต non-finite ได้สม่ำเสมอขึ้น ตาม GitHub ไม่มีรายละเอียดผลลัพธ์ครบทุกกรณีในข้อความที่อ่าน จึงไม่ควรสรุปต่อว่าคำสั่งนี้จะส่งข้อผิดพลาดแบบเดียวกับอีกสองคำสั่งเสมอ

จุดหักมุม: สมุดงานที่หยุด อาจกำลังช่วยคุณ

แต่การอัปเดตที่ทำให้สมุดงานเดิมหยุด ไม่จำเป็นต้องหมายถึงการคำนวณถอยหลัง สำหรับกรณีอนันต์ที่ประกาศแก้ สิ่งที่เปลี่ยนคือจากคืนผลลัพธ์ผิด มาเป็นแจ้งข้อผิดพลาด ตาม NumPy งานที่ดูเหมือนพังจึงอาจกำลังเปิดเผยปัญหาที่เคยถูกปล่อยผ่าน

ข้อแลกเปลี่ยนคือคนดูแลงานต้องจัดการข้อมูลและการแจ้งเตือนให้เรียบร้อย จะให้โปรแกรมกลับมารันจบอย่างเดียว หรือให้ตัวเลขที่ส่งต่อมีเหตุผลรองรับด้วย? อย่ารีบปิดข้อความผิดพลาดเพียงเพื่อให้กราฟกลับมา เพราะภาพที่ครบทุกช่องยังไม่ใช่หลักฐานว่าข้อมูลผ่านการตรวจแล้ว

เรื่องเงิน / ผลกระทบ

ไม่มีตัวเลขความเสียหาย ค่าใช้จ่ายที่ลดลง หรือเวลาที่ประหยัดได้ใน ประกาศ GitHub และ ประกาศ Python-announce จึงไม่ควรแปลงข่าวนี้เป็นคำรับรองว่าจะช่วยธุรกิจประหยัดเงินเท่าไร ผลต่อเงินในบทความนี้เป็นเรื่องที่ผู้อ่านควรประเมินตามงานของตัวเอง

ตัวอย่างที่ควรทบทวนคือรายงานซึ่งนำผลวิเคราะห์ไปวางแผนซื้อของ หรือใช้ตัดสินใจว่าจะเน้นขายอะไร ถ้าคำสั่งที่ใช้ได้รับอินพุตอนันต์ ความเสี่ยงของผลลัพธ์เดิมมีฐานจาก บันทึกรุ่น NumPy แต่ยังไม่มีข้อมูลว่าร้านใดเสียเงินจริงจากบั๊กนี้ ไม่ควรนำสถานการณ์สมมติไปเล่าราวกับเป็นเหตุการณ์ที่เกิดแล้ว

อีกจุดที่ทีมข้อมูลควรตรวจคือ MaskedArray หรือชุดข้อมูลที่ทำเครื่องหมายซ่อนบางค่าไว้ ส่วน fill_value คือค่าที่ใช้เติมตำแหน่งดังกล่าว หากค่าที่รับต่อมาจากชุดเดิมไม่สามารถอยู่ในชนิดข้อมูลใหม่ได้ รุ่นนี้จะคืนไปใช้ค่าเริ่มต้น ตาม NumPy แปลว่าการแปลงชนิดข้อมูลอาจเปลี่ยนค่าที่ใช้เติม และควรอยู่ในรายการทดสอบรายงาน

บันทึกเดียวกันอธิบายว่าเดิมบางกรณีเก็บค่าที่มีชนิดเก่าไว้ แล้วค่อยเกิด TypeError หรือข้อผิดพลาดเรื่องชนิดข้อมูลเมื่อถูกตรวจภายหลัง อีกกรณีเก็บค่าที่เกินช่วงของจำนวนเต็มพร้อม RuntimeWarning ซึ่งเป็นข้อความเตือนระหว่างทำงาน ตอนนี้กรณีที่ระบุจะกลับไปใช้ค่าเริ่มต้น ตาม NumPy จึงต้องดูค่าผลลัพธ์ด้วย ไม่ใช่ดูแค่ว่ามีข้อความแดงหรือไม่

สำหรับ StringDType หรือชนิดข้อมูลที่ใช้เก็บข้อความ รุ่นนี้แก้ hash ซึ่งเป็นค่าช่วยระบุและค้นหาข้อมูล กรณีใช้ NaN เป็นสัญลักษณ์พิเศษแทนข้อมูลที่ขาดหาย เดิมวัตถุชนิดข้อมูลที่เท่ากันอาจมี hash ต่างกัน จนค้นหาในพจนานุกรมข้อมูลหรือตัดรายการซ้ำในเซตผิดพลาด ตาม GitHub คนดูแลระบบที่มีข้อมูลข้อความจึงมีประเด็นให้ตรวจเพิ่ม แม้ไม่ได้ใช้คำสั่งวิเคราะห์ตัวเลขข้างต้น

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เรื่องวันออก รุ่น และช่วง Python ที่รองรับไม่มีความขัดแย้งในเนื้อหาประกาศที่ได้รับ GitHub กับ numpy.org ระบุวันออกตรงกัน ส่วน Charles R Harris ใน Python-announce ยืนยันว่ารุ่นนี้พร้อมใช้ และให้ขอบเขต Python ตรงกับบันทึกรุ่น

อย่างไรก็ตาม ไฟล์ข้อความจาก numpy.org มีช่องวันที่กำกับข้อมูลหน้าเว็บเป็น 2015-03-12 ซึ่งไม่ตรงกับข้อความวันออกในตัวประกาศที่ระบุ 2026-10-10 ผมใช้วันที่จากเนื้อหาประกาศซึ่งตรงกับ GitHub เป็นวันออก โดยไม่ตีความช่องกำกับหน้าเว็บเป็นวันปล่อยรุ่น เหตุผลที่วันที่กำกับต่างกันไม่ปรากฏในชุดข้อมูลนี้ครับ

เสียงที่สนับสนุนการเปลี่ยนแปลงมาจากโครงการ NumPy ซึ่งระบุว่าผลลัพธ์เดิมเมื่อเจออนันต์ใช้ไม่ได้ ตาม release notes ส่วนเสียงคัดค้านจากผู้ใช้หรือองค์กรอื่นไม่มีในแหล่งที่ได้รับ จึงไม่มีชื่อใครให้อ้างว่าต่อต้านการอัปเดต และไม่ควรแต่งฝ่ายค้านขึ้นมาเพื่อให้ข่าวดูมีสองฝั่ง

ข้อจำกัดที่ต้องอ่านควบคู่กันก็อยู่ในประกาศ NumPy เองครับ ค่า fill_value ที่ผู้ใช้กำหนดโดยตรงยังถูกตรวจและส่งข้อผิดพลาดตามเดิม อีกทั้งการย้ายจากค่าจำนวนเชิงซ้อน ซึ่งมีส่วนจริงและส่วนจินตภาพ ไปเป็นชนิดจำนวนจริง อาจเกิด ComplexWarning ตาม NumPy การแก้บั๊กจึงไม่ได้หมายความว่าคำเตือนทุกชนิดหายไป

ยังไม่ทราบรายชื่อและเวอร์ชัน LAPACK ที่เกี่ยวข้องครบถ้วนจากข้อความชุดนี้ และไม่มีผลวัดว่าคำนวณเร็วขึ้นเท่าไร ประกาศ Python-announce เน้น typing หรือข้อมูลกำกับชนิดตัวแปร กับวิธีหลบบั๊ก MSVC 19.51 แปลว่าเป็นประเด็นของเครื่องมือสร้างโปรแกรมรุ่นที่ระบุ แต่ไม่ได้อธิบายอาการและเงื่อนไขอย่างครบถ้วนในข้อความที่ได้รับ

ทั้งสาม URL เป็นแหล่งประกาศของโครงการหรือผู้ประกาศรุ่น ไม่ใช่การทดสอบอิสระจากผู้ใช้หลายกลุ่ม ผมยังไม่ได้ทดลองกับสมุดงานจริง และไม่มีหลักฐานในชุดนี้ว่ารายงานของผู้อ่านคนใดได้รับผลกระทบ ขอบเขตข่าวจึงอยู่ที่พฤติกรรมซึ่งผู้พัฒนาประกาศ พร้อมข้อเสนอให้ตรวจงานก่อนนำไปใช้ครับ

แล้วเราควรทำอะไร

คนทั่วไปและเจ้าของรายงาน

1. ถามคนทำรายงานว่ามีการใช้ NumPy และคำสั่งที่ประกาศแก้หรือไม่ ส่ง บันทึกรุ่น ให้ดูแทนการสรุปเองว่าทุกตารางมีปัญหา ถ้าไม่มีงานที่เกี่ยวข้อง ก็ไม่จำเป็นต้องหยุดงานทั้งหมดจากข่าวนี้
2. ถ้ารายงานหยุดหลังอัปเดต ให้เก็บข้อความผิดพลาด ชื่อชุดข้อมูล และขั้นตอนที่หยุดไว้ ส่งให้คนดูแลตรวจ ก่อนใช้ตัวเลขจากรอบก่อนแทนโดยอัตโนมัติ ขอให้ยืนยันสาเหตุก่อนตัดสินใจว่าผลเก่ายังใช้ได้
3. ตกลงวิธีจัดการข้อมูลที่ใช้คำนวณไม่ได้ให้ชัด โดยเฉพาะงานที่เกี่ยวกับเงิน ไม่ควรสั่งให้แทนทุกค่าด้วยศูนย์เพียงเพื่อให้งานผ่าน เพราะการเปลี่ยนข้อมูลควรมีเหตุผลจากความหมายของช่องนั้น

นักศึกษาและคนเขียนสมุดงาน Python

1. ตรวจข้อมูลก่อนเข้าคำสั่งวิเคราะห์ โดยใช้ np.isfinite เป็นจุดตรวจค่าอนันต์และ NaN ตามแนวทางเตรียมงานในบทความนี้ แล้วดูว่าแถวใดและคอลัมน์ใดต้องย้อนกลับไปตรวจ อย่าลบแถวทันทีโดยไม่ดูว่าค่านั้นหมายถึงอะไร
2. แยกการแก้ข้อมูลออกจากการอัปเดตเครื่องมือ เก็บข้อมูลเดิมไว้เพื่อเทียบ และจดเหตุผลหากต้องตัดหรือแทนค่า ขั้นตอนนี้ช่วยให้ผู้ตรวจงานเข้าใจว่าผลเปลี่ยนเพราะข้อมูลหรือเพราะพฤติกรรมของคำสั่ง
3. ทดสอบสมุดงานตั้งแต่ต้นจนจบในสภาพแวดล้อมทดลอง ไม่ดูเพียงช่องสุดท้าย ตรวจทั้งผลคำนวณ ข้อผิดพลาด และค่าที่เติมในข้อมูลที่ถูกซ่อน เพราะ NumPy เปลี่ยนทั้งงานคำนวณและพฤติกรรม MaskedArray

ทีม IT และนักพัฒนา

1. ตรวจ Python ก่อนอัปเดต บันทึกรุ่นระบุช่วงรองรับไว้ชัด และ Python 3.11 อยู่นอกช่วงนั้น ตาม GitHub อย่าอนุมานจากคำว่า patch ว่าสภาพแวดล้อมทุกชุดรองรับโดยไม่ต้องตรวจ
2. ระบุรุ่น NumPy ให้แน่นอนในไฟล์ requirements ซึ่งเป็นรายการแพ็กเกจที่งานต้องใช้ แล้วเตรียมชุดทดลองอัปเดตแยกไว้ เป้าหมายคือให้ทีมตรวจผลจากรุ่นเดียวกัน ไม่ใช่ใช้การตรึงรุ่นเพื่อหลีกเลี่ยงแก้ข้อมูลเสียถาวร
3. เตรียมตัวอย่างข้อมูลปกติและข้อมูลอนันต์สำหรับงานที่ใช้ svd หรือ lstsq ตรวจว่าระบบแจ้งผู้รับผิดชอบได้เมื่อคำนวณต่อไม่ได้ และไม่ส่งรายงานเก่าปะปนกับผลรอบใหม่โดยไม่มีคำอธิบาย
4. ถ้าใช้ StringDType หรือ MaskedArray ให้ตรวจงานค้นหา ตัดรายการซ้ำ และแปลงชนิดข้อมูลด้วย อ้างขอบเขตจาก release notes ส่วนทีมที่สร้าง NumPy เองควรอ่านรายการแก้ MSVC และ typing ใน ประกาศรุ่น ก่อนสรุปว่าเกี่ยวกับระบบของตนมากน้อยแค่ไหน

ผมมองว่า…

ผมมองว่าเรื่องนี้ไม่ใช่การอัปเดตที่ทำให้โปรแกรมดื้อ แต่คือการทำให้ข้อมูลผิดเงื่อนไขถูกมองเห็นเร็วขึ้น สำหรับงานที่ต้องส่งตัวเลขให้คนอื่นตัดสินใจ การหยุดพร้อมเหตุผลมีคุณค่ามากกว่าการทำต่อจนได้รายงานที่ยังไม่มีใครตรวจต้นทาง ความเห็นนี้อิงการเปลี่ยนพฤติกรรมที่ประกาศ ไม่ใช่ผลทดสอบสมุดงานของผมเอง

ผมมองว่าทีมควรวางแผนรับข้อความผิดพลาดพร้อมกับแผนอัปเดต คนเขียนโค้ดต้องรู้ว่าจะตรวจข้อมูลตรงไหน ส่วนคนรับรายงานต้องรู้ว่ารอบใดหยุดและเพราะอะไร การทำให้ทั้งสองฝ่ายเข้าใจสถานะตรงกัน ช่วยให้คำว่าอัปเดตสำเร็จมีความหมายถึงงานที่ตรวจได้ด้วย

ปิดท้าย: สิ่งที่ต้องจับตา

ความน่าเชื่อถือของรายงานเริ่มตั้งแต่ข้อมูลที่ยอมให้คำนวณต่อ ไม่ได้เริ่มตอนจัดกราฟให้สวยครับ หลังรุ่นที่ออกเมื่อ 10 ต.ค. ตาม NumPy สิ่งที่ควรจับตาคือสมุดงานของเราหยุดตรงไหนเมื่อทดลองอัปเดต และค่าที่ใช้เติมข้อมูลเปลี่ยนหรือไม่ ไม่มีวันออกแพตช์ถัดไปในแหล่งที่ได้รับ จึงยังระบุวันรอแก้เพิ่มเติมไม่ได้

สมุดงานที่คุณใช้ส่งรายงานประจำ มีขั้นตอนแจ้งเจ้าของข้อมูลแล้วหรือยัง เมื่อพบค่าอนันต์ก่อนคำนวณ?

Recap

• เกิดอะไรขึ้น: คำสั่ง svd และ lstsq เปลี่ยนจากผลลัพธ์ผิดเป็นข้อผิดพลาดเมื่ออินพุตมีอนันต์ ตาม แหล่ง 1: GitHub
• รุ่นที่ต้องจำคือ NumPy 2.5.4 แปลว่าเป็นแพตช์ที่ควรนำไปทดลองกับงานเดิมก่อนใช้งานจริง ตาม แหล่ง 2: NumPy
• ใครเห็นต่าง: ไม่มีเสียงคัดค้านในชุดแหล่งประกาศนี้ และยังไม่มีผลทดสอบอิสระให้เทียบ
• สิ่งที่ยังไม่รู้: รายชื่อ LAPACK ที่เกี่ยวข้องครบถ้วน ผลต่อสมุดงานของเรา และเหตุผลที่วันที่กำกับหน้าเว็บต่างจากวันออกในเนื้อหา
• ผลต่อคนไทย: คนทำรายงานและนักศึกษาควรตรวจข้อมูลก่อนใช้ผลวิเคราะห์ โดยยังไม่สรุปว่ารายงานเก่าทุกฉบับผิด
• สิ่งที่ต้องทำ: ตรวจค่าอนันต์และ NaN ตรึงรุ่นที่ทีมใช้ร่วมกัน และทดลองสมุดงานตั้งแต่ต้นจนจบ
• สิ่งที่ต้องจับตา: การหยุดของงานคำนวณและการเปลี่ยนค่าเติมหลังอัปเดต อ่านขอบเขต Python จาก แหล่ง 3: Python-announce ควบคู่กัน