Mathics 7.0 – ทางเลือกโอเพนซอร์สแทน Mathematica

 (github.com/Mathics3)
4 คะแนน โดย GN⁺ 2024-12-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mathics Core 7.0.0 ปรับโครงสร้างเอนจินหลักของระบบคำนวณโอเพนซอร์สที่เข้ากันได้กับ Mathematica และวางรากฐานสำหรับ การโหลด built-in function แบบ lazy loading ในอนาคต
  • เพิ่ม built-in function ใหม่ เช่น ComplexExpand, ConjugateTranspose, LeviCivitaTensor และฟังก์ชันที่เกี่ยวข้องกับนิพจน์ พีชคณิตเชิงเส้น และการตรวจ判จำนวนจริง
  • อุดช่องว่างด้านความเข้ากันได้เดิม เช่น Range[], DirectedInfinity, Indeterminate, การแสดงข้อผิดพลาดของ Graphics, การเปลี่ยนแปลง $CharacterEncoding
  • การโหลด built-in function เปลี่ยนจากการพึ่งพา implicit import มาเป็นการเรียก import_and_load_builtins() อย่างชัดเจน
  • รองรับ Python 3.11 และ SymPy 1.12 พร้อมการแก้ไขที่เกี่ยวข้องกับ Quantity, SparseArray, Derivative, Exit[], BaseForm

ทิศทางของรีลีสและการจัดระเบียบภายใน

  • Mathics Core 7.0.0 รวมการปรับโครงสร้างภายในเพื่อรองรับ การโหลด built-in function แบบ lazy loading ในอนาคต
  • ปรับ Python code และ style ให้ทันสมัยขึ้น เพิ่ม type annotation และแก้คำสะกดผิดหลายจุด
  • อัปเดต dependency ของ SymPy และ Python ให้เป็นเวอร์ชันใหม่ขึ้น
  • มีการทำงานเพื่อเพิ่มความเร็วในการโหลดช่วงเริ่มต้นและลดการใช้หน่วยความจำช่วงเริ่มต้นด้วย

Built-in function ใหม่

  • built-in function ที่เพิ่มในรีลีสนี้มีดังนี้
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

การปรับปรุงเอกสารและการสร้างชุดทดสอบ

  • แก้ ปัญหาการจัดรูปแบบ หลายจุดในเอกสาร PDF
    • เพิ่มระยะห่างของเลข section ในสารบัญบทและหัวข้อย่อย
    • เพิ่มระยะขอบรอบคำจำกัดความของ built-in function
    • แก้คำสะกดผิดทั่วทั้งเอกสาร
  • โค้ดสำหรับรัน doctest และสร้างเอกสาร LaTeX ได้รับการปรับปรุงและ refactor
    • อนุญาตให้มีการอัปเดต built-in function แบบ incremental
    • จัดระเบียบเพื่อลดโค้ดซ้ำ
  • ใน “Expression Structure” เพิ่มหัวข้อ Section Head-Related Operations ใหม่
  • ชื่อ PDF เปลี่ยนจาก Mathics เป็น Mathics3 และอัปเดตข้อความแนะนำด้วย
  • doctest แบบเก่าที่ไม่เปิดเผยและไม่ใช่เพื่อการสอนถูกย้ายไปเป็น pytest

ความเข้ากันได้และการเปลี่ยนแปลงพฤติกรรมที่ผู้ใช้เห็นได้

  • *Plot ไม่แสดงข้อความระหว่างการประเมินผล
  • Range[] รองรับ di ที่เป็นค่าลบ
    • PR ที่เกี่ยวข้อง: #951
  • ปรับปรุงการรองรับ DirectedInfinity และ Indeterminate
  • Graphics และ Graphics3D จะแสดงด้วย พื้นหลังสีชมพู เมื่อมี primitive หรือ directive ที่ไม่ถูกต้อง
    • ในอินเทอร์เฟซ Mathics-Django จะแสดงข้อความข้อผิดพลาดแบบ tooltip ด้วย
  • $CharacterEncoding สามารถเปลี่ยนค่าได้ภายใน session

การใช้งานภายในและการเปลี่ยนแปลง API

  • แยก eval_abs, eval_sign ออกจาก Abs และ Sign แล้วเพิ่มไว้ใน mathics.eval.arithmetic
  • จำนวนหลักสูงสุดของตัวเลขที่อนุญาตในสตริงถูกตั้งไว้ที่ 7000
    • ในสภาพแวดล้อมอย่าง pyston ที่ Python ไม่ปรับให้อัตโนมัติ สามารถปรับได้ด้วย environment variable MATHICS_MAX_STR_DIGITS
  • การทำงานของการเปรียบเทียบจำนวนจริงถูกนำเข้าไปไว้ภายใน implementation ของ RealSign
  • ใน Python 3.11 $MaxLengthIntStringConversion ควบคุมขนาดสูงสุดของการแปลง literal ระหว่างจำนวนเต็มขนาดใหญ่กับสตริง
  • การโหลด built-in code เปลี่ยนจากแบบ implicit เป็นแบบ สั่งอย่างชัดเจน
    • เป็นการเปลี่ยนแปลงเพื่อให้ในอนาคตสามารถทำ lazy loading ของ built-in function หรือ “autoload” แบบ GNU Emacs autoload ได้
  • API ใหม่ต้องเรียก import_and_load_builtins() อย่างชัดเจน
    • ก่อนหน้านี้ เวลาที่ built-in function ถูกโหลดขึ้นอยู่กับลำดับ import แบบ implicit และไม่แน่นอน
  • เพิ่ม LRU cache ให้ mpmath

การแก้บั๊กของ Quantity·SparseArray และอื่น ๆ

  • Definitions เข้ากันได้กับ pickle
  • ปรับปรุงการรองรับนิพจน์ Quantity
    • รวมถึงการแปลง การจัดรูปแบบ และการคำนวณเชิงเลขคณิต
  • ตัวเลือก Background ของ Graphics และ Graphics3D กลับมาทำงานอีกครั้ง
  • แก้ปัญหาการเปรียบเทียบเชิงตัวเลขสำหรับนิพจน์ที่มี String
    • issue ที่เกี่ยวข้อง: #797
  • แก้ปัญหา Switch[] ที่มี Infinity
    • issue ที่เกี่ยวข้อง: #956
  • แก้ปัญหา Outer[] สำหรับ SparseArray
    • issue ที่เกี่ยวข้อง: #939
  • ArrayQ[] ตรวจจับ SparseArray ได้
    • PR ที่เกี่ยวข้อง: #947
  • จัดการ exception BoxExpressionError
  • แก้พฤติกรรมที่ Derivative ประเมินค่า True, False, List[]
  • รวมการแก้ไขแพ็กเกจ Combinatorica
  • แก้ Exit[] ที่ไม่ทำงาน
  • BaseForm ถูกเพิ่มใน $OutputForms

เวอร์ชันแพ็กเกจที่รองรับ

  • รองรับ Python 3.11
  • รองรับ SymPy 1.12

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-09
ความคิดเห็นจาก Hacker News

  • ผมติดตามโปรเจกต์นี้มาหลายปีแล้ว และมันก็พัฒนาไปได้ดีอย่างต่อเนื่อง หากสนใจ ระบบพีชคณิตคอมพิวเตอร์ แบบโอเพนซอร์ส ก็มีทางเลือกที่สุกงอมกว่านี้อยู่มาก ตั้งแต่ตัวเลือกคลาสสิกอย่าง GNU Octave หรือ Maxima ไปจนถึงตัวเลือกสมัยใหม่อย่าง SAGEmath, Symbolics.jl, sympy
    ขอบเขตกว้างตั้งแต่ไลบรารีคำนวณเชิงสัญลักษณ์อย่าง GiNaC ไปจนถึง IDE แบบมีทุกอย่างพร้อมใช้ในตัวอย่าง SAGEmath และชุมชนก็ยังคึกคักด้วย ตัวอย่างเช่น SAGEmath แทบจะเป็นผู้บุกเบิกอินเทอร์เฟซเว็บโน้ตบุ๊ก และผมมองว่ามันนำไปสู่ Jupyter ในรูปแบบต่าง ๆ ทุกวันนี้
    โดยส่วนตัวผมชอบสไตล์แบบ Lisp ของ Mathematica (MMA) แต่สิ่งที่ทำให้ MMA ทรงพลังไม่ใช่แค่แกนหลัก แต่คือไลบรารีขนาดมหึมา ในหัวข้อพื้นฐานอย่างการอินทิเกรตเชิงสัญลักษณ์ กราฟิก 2D/3D และวิธีไฟไนต์เอลิเมนต์ก็มีโซลูชันระดับแนวหน้าของวงการ และยังมีสาขาเฉพาะทางมากมายอย่างชีวสารสนเทศด้วย
    Mathics ดูเหมือนจะทำซ้ำส่วนแกนหลักได้ดี แต่แน่นอนว่ายังขาดไลบรารีทั้งหมดเหล่านั้น ตรรกะเดียวกันนี้ใช้ได้เมื่อเปรียบเทียบ Matlab กับ “toolkit” หลายตัวกับโคลนของ numpy แต่กระแส Python ตอนนี้ได้นำโค้ดใหม่ ๆ จำนวนมากที่ไม่ได้ทำงานใน Matlab เข้าสู่โลกของ numpy แล้ว

    • เห็นด้วยกับเรื่องความคืบหน้า โปรเจกต์นี้ดูเป็นตัวอย่างที่ยอดเยี่ยมของการ ขุดลึกในสิ่งที่ชอบอย่างเงียบ ๆ และต่อเนื่อง
      ตอนที่มันออกมาครั้งแรกเมื่อราว 5 ปีก่อน ผมคิดว่า “เอนจินประเมินผลเชิงสัญลักษณ์ทำมาได้ดีจริง ๆ ต่อไปมาดูกันว่าจะเป็นอย่างไร” ต่อไปทุกครั้งที่อยากเริ่มโปรเจกต์ใหม่ ผมคงต้องนึกถึงตัวอย่างการค่อย ๆ ขัดเกลาโปรเจกต์เก่านี้ไว้
    • ฝั่ง Lisp สามารถเข้าสู่ Common Lisp ได้ง่าย ๆ จาก Maxima ถ้าใช้ SBCL ด้วยเหตุผลด้านประสิทธิภาพก็จะยิ่งดี
    • ผมอาจเข้าใจผิดก็ได้ แต่ผมไม่มองว่า Octave, Matlab, numpy อยู่ในหมวดเดียวกับระบบพีชคณิตคอมพิวเตอร์ ทั้งหมดนี้เป็นภาษา หรือไลบรารีที่เน้น การคำนวณเชิงตัวเลข จึงใช้เพื่อหาคำตอบเชิงตัวเลขของปัญหามากกว่านิพจน์เชิงสัญลักษณ์ที่แม่นตรง
      พวกมันเป็นสิ่งที่เติมเต็มกัน และมักถูกใช้ร่วมกันด้วย Mathematica กับ Mathics ดูเหมือนจะรองรับทั้งสองพาราไดม์ แต่ก็ไม่ใช่สิ่งเดียวกัน

  • ดูเหมือนจะอิงจาก sympy: https://www.sympy.org/en/index.html

  • ถ้าต้องการใช้ส่วนตัวเท่านั้น Wolfram Cloud ใช้ได้ฟรี ไฟล์ดูเหมือนจะถูกลบหลังผ่านไปราว 30 วัน Wolfram Engine ก็เป็นวิธีใช้ฟรีเพื่อใช้ Mathematica จากบรรทัดคำสั่งเหมือนกัน เอาเถอะ ดีกว่าไม่มีอะไร

    • จะซื้อ Raspberry Pi ที่มีไลเซนส์ Mathematica รวมมาด้วยก็ได้
    • ถ้าเอา WLJS วางบน Wolfram Engine ก็ใช้ได้สนุกทีเดียว

  • มีคำแนะนำ Mathics ที่เรียบง่ายกว่านี้อยู่ที่นี่:
    https://mathics.org/

  • ไม่รู้ทำไมรู้สึกว่านี่น่าจะถูกรวมเข้าไปใน SageMath :D

    • ผมไม่แน่ใจว่ามีความเคลื่อนไหวจริง ๆ ที่จะใส่ Mathics เข้าไปใน SageMath หรือไม่ ถ้าให้เดา คงเป็นเพราะ SageMath ส่วนใหญ่พัฒนาโดยนักคณิตศาสตร์วิจัยและนักวิทยาการรหัสลับ ดังนั้นเวลาใส่องค์ประกอบใด ๆ เข้าไป ประสิทธิภาพ มักเป็นประเด็นสำคัญ
      หนึ่งในเหตุผลที่ SageMath เป็นโปรเจกต์ Cython ที่ใหญ่ที่สุด ก็เพราะ Cython ช่วยให้ Sage ใช้ประโยชน์จากไลบรารี C/C++ ที่รวดเร็วได้
      ตอนนี้ Mathics ดูเหมือนจะยังไม่ได้ใส่ใจเรื่องประสิทธิภาพอย่างจริงจังนัก เช่น ลองรันไมโครเบนช์มาร์กเล็ก ๆ อย่าง "AbsoluteTiming[Sum[i, {i, 1, 100000}]]" ใน Mathics หรืออ่านโรดแมปดูก็ได้
      แน่นอนว่านี่ไม่เป็นไร ภาษาโปรแกรมของ Mathematica มีการประยุกต์ใช้น่าสนใจจำนวนมากที่ประสิทธิภาพไม่ใช่เรื่องสำคัญ เช่น ใช้ค่อย ๆ ไล่ตามการคำนวณเชิงสัญลักษณ์บางอย่างทีละขั้นอย่างระมัดระวังไปพร้อมกับนิพจน์
      แต่แรงจูงใจหลักของนักพัฒนา Sage คือคณิตศาสตร์วิจัยระดับแนวหน้า และในบริบทนั้นประสิทธิภาพแทบจะสำคัญมากเสมอ เหตุผลที่ Sage ไม่ได้ใช้แค่ sympy แต่กลับ implement ฟังก์ชันคล้าย ๆ กันเองจำนวนมากก็เพราะประสิทธิภาพ sympy ให้ความสำคัญกับความง่ายในการติดตั้ง จึงอาจค่อนข้างช้า ส่วนใน SageMath ความง่ายในการติดตั้งไม่ใช่ลำดับความสำคัญเลย
      พันธกิจของ SageMath คือการเป็นทางเลือกที่ใช้งานได้จริงแทน Mathematica, Matlab, Magma, Maple แต่ไม่ได้หมายความว่าจะต้องเป็นโคลน เช่น ไม่ได้หมายถึงการรันโค้ด Mathematica ได้โดยตรง แต่หมายถึงเป็นทางเลือกที่สามารถรองรับงานวิจัยซึ่งเดิมทีต้องทำด้วยโปรแกรมปิดเหล่านั้น บนซอฟต์แวร์คณิตศาสตร์โอเพนซอร์ส

  • วิศวกรซอฟต์แวร์ทำทุกอย่างเพื่อจะไม่ต้องจ่าย ค่าซอฟต์แวร์

    • ผมมีไลเซนส์ Mathematica แต่ก็คิดว่าโปรเจกต์นี้เจ๋งดี ผมก็เป็นวิศวกรซอฟต์แวร์เหมือนกัน ถ้านักพัฒนา Mathics ไม่ใช่ผู้ใช้ Mathematica ผมคงแปลกใจมากกว่า
    • ไม่ใช่เรื่องราคา แต่เป็นเรื่อง เสรีภาพ
    • บางคนสร้างซอฟต์แวร์เพื่อตัวเอง และถึงขั้นเผยแพร่เป็นโอเพนซอร์สด้วย
    • เมื่อก่อนผมเคยจ่าย 20 ดอลลาร์สำหรับกล่อง DVD Debian Sarge 3 แผ่นกับคู่มือขนาดนิตยสาร

  • Mathematica มีให้ใช้ฟรีบน Raspberry Pi[1] และมหาวิทยาลัยส่วนใหญ่ก็มีไลเซนส์แบบครอบคลุมทั้งไซต์อยู่แล้ว ไลเซนส์ “Home & Hobby” ก็ไม่ได้แพงขนาดนั้น โดยแบบสมัครสมาชิกปีละ 195 ดอลลาร์ ไลเซนส์ถาวร 390 ดอลลาร์ และค่าต่ออายุแค่ 175 ดอลลาร์[2]
    พูดตรง ๆ ถ้าเป็นคนที่สนใจ tinkering แต่จ่ายราคานั้นไม่ไหว เวอร์ชันแคร็กก็ไม่ได้หายากหรือติดตั้งยากอะไร
    โดยส่วนตัวแล้วผมค่อนข้างชอบ Mathematica หรือพูดให้ถูกคือ “Wolfram Language” และก็ยินดีจ่ายค่าไลเซนส์สำหรับงานอดิเรกด้วย ไม่ใช่แค่คิดว่าคุ้มเงิน แต่ยังมองว่าการสนับสนุนซอฟต์แวร์คณิตศาสตร์เป็น “เหตุผลที่ดี” ที่ควรจ่ายเงิน
    แถมช่างภาพสมัครเล่นมักจ่ายเงินให้เครื่องมืออย่าง Adobe CC มากกว่าที่โปรแกรมเมอร์จำนวนมากจ่ายให้เครื่องมือทั้งหมดของตัวเองเสียอีก ซึ่งผมไม่เข้าใจว่าทำไม เช่นเดียวกับการยอมจ่ายบริการสมัครสมาชิกหลายอย่างเดือนละ 20~40 ดอลลาร์ขึ้นไป แต่กลับลังเลกับค่าไลเซนส์ 200~400 ดอลลาร์
    แต่ในกรณีของผม เวลาที่ใช้กับ Mathematica น่าจะมากกว่าโปรแกรมแทบทุกตัวที่ติดตั้งอยู่ในคอมพิวเตอร์
    ถึงอย่างนั้น ซอฟต์แวร์คณิตศาสตร์โอเพนซอร์ส ก็ยังมีที่ทางสำคัญอยู่ดี โดยรวมแล้ว Mathematica ครอบคลุมกว้างมาก แต่ในคณิตศาสตร์ระดับสูงก็ยังมีช่องโหว่ใหญ่ ๆ อยู่
    โดยเฉพาะมีเหตุผลสองข้อที่ทำให้ยากจะเชื่อว่าจะตอบโจทย์สาขาคณิตศาสตร์ที่ “เฉพาะทาง” กว่านั้นได้ด้วย ข้อแรก ยิ่งเป็นสาขาที่สูงขึ้นหรือเข้าใจยากขึ้น ผลตอบแทนต่อการลงทุนก็ยิ่งลดลงอย่างรวดเร็ว ข้อสอง Wolfram Language มีฟังก์ชันในตัวมากกว่า 6,000 ตัวอยู่แล้ว ดังนั้นการเพิ่มอีกหลายร้อยตัวเพื่อรองรับสาขาอย่างทฤษฎีกลุ่มอย่างครอบคลุมจึงดูไม่ค่อยสมเหตุสมผล
    อาจรองรับผ่านแพ็กเกจได้ก็จริง แต่เพราะไม่ได้รับการรองรับแบบชั้นหนึ่งในเคอร์เนล จึงมีต้นทุนด้านประสิทธิภาพ และผู้ใช้ก็ต้องตั้งใจไปหาใช้เอง ทำให้มีต้นทุนด้านการใช้งานด้วย
    ดังนั้นซอฟต์แวร์โอเพนซอร์สอย่าง GAP, M2, PARI/GP จึงมีบทบาทสำคัญในการอุดช่องว่างของ Wolfram Language สำหรับผม ผมบริจาคให้โปรเจกต์ FOSS พอ ๆ กับที่จ่ายค่าไลเซนส์ Mathematica ส่วนโปรเจกต์ที่การสนับสนุนเป็นเงินทำได้ไม่ง่าย ผมก็พยายามใช้เวลาและทักษะไปช่วยปรับปรุง
    พูดตรง ๆ ผมไม่ได้สนใจโปรเจกต์ที่พยายามทำซ้ำฟังก์ชันของ Mathematica มากนัก แน่นอนว่าโปรเจกต์เหล่านั้นก็คงจะพัฒนาและดีขึ้นต่อไป และอย่างน้อยก็ช่วยกดดันให้ Wolfram Research ปรับปรุงฟังก์ชันพื้นฐานต่อเนื่อง แต่ถ้าโปรเจกต์เหล่านั้นจะไล่ตาม Mathematica/WL ในปัจจุบันให้ทัน ก็น่าจะต้องใช้เวลา 10~20 ปี
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram ดูเหมือนจะถูกเกลียดพอสมควรใน HN แต่สำหรับคณิตศาสตร์เชิงทดลอง การแก้ปริศนา และการทำ visualization ข้อมูลอย่างรวดเร็ว Wolfram เป็นภาษาที่ลึกและงดงาม
      โน้ตบุ๊กแบบบูรณาการ เอกสารที่แสดงเมื่อเอาเมาส์ชี้ และที่น่าทึ่งคือ namespace ขนาดยักษ์เดียวที่มีฟังก์ชันหลายพันตัว somehow ผสานกันจนให้ประสบการณ์ที่เรียบง่ายและมีประสิทธิภาพแบบที่ผมไม่เคยเจอมาก่อน ทั้งที่ปกติผมก็ไม่ใช่คนชอบ IDE แบบ “หนัก ๆ” ด้วยซ้ำ

  • สิ่งหนึ่งที่น่าหงุดหงิดใน Mathematica คือฟังก์ชันทั้งหมดถูกยัดไว้ใน namespace เดียวกัน และไม่มีการโอเวอร์โหลดตามตัวเลือกการกำหนดพารามิเตอร์ที่ต่างกัน

    • ไม่แน่ใจว่าโอเวอร์โหลดหมายถึงอะไร ฟังก์ชันสามารถทำงานต่างกันตามจำนวนอาร์กิวเมนต์ได้ง่าย ๆ เช่น Fold แบบ 2 อาร์กิวเมนต์กับ Fold แบบ 3 อาร์กิวเมนต์ และยังมีออปชันได้เต็มที่เหมือน Graphics, Graphics3D, Solve, Import/Export
      ตัวอย่างความซ้ำซ้อนใหญ่ ๆ ที่นึกออกก็คงมีแค่ฟังก์ชัน Plot หลาย ๆ ตัวเท่านั้น