Mathics 7.0 – Giải pháp thay thế mã nguồn mở cho Mathematica

 (github.com/Mathics3)
4 điểm bởi GN⁺ 2024-12-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Mathics Core 7.0.0 sắp xếp lại engine cốt lõi của hệ thống tính toán mã nguồn mở tương thích với Mathematica, đồng thời đặt nền móng cho tải lười các hàm tích hợp trong tương lai
  • Các hàm tích hợp mới như ComplexExpand, ConjugateTranspose, LeviCivitaTensor được bổ sung, liên quan đến biểu thức, đại số tuyến tính và xác định số thực
  • Các khoảng trống trong khả năng tương thích hiện có được lấp đầy, gồm Range[], DirectedInfinity, Indeterminate, hiển thị lỗi Graphics, thay đổi $CharacterEncoding, v.v.
  • Việc tải hàm tích hợp chuyển từ phụ thuộc import ngầm định sang cách gọi rõ ràng import_and_load_builtins()
  • Bao gồm hỗ trợ Python 3.11 và SymPy 1.12, cùng các bản sửa liên quan đến Quantity, SparseArray, Derivative, Exit[], BaseForm

Định hướng phát hành và dọn dẹp nội bộ

  • Mathics Core 7.0.0 bao gồm việc dọn dẹp cấu trúc nội bộ nhằm hỗ trợ tải lười các hàm tích hợp trong tương lai
  • Hiện đại hóa mã Python và style, tăng chú thích kiểu, đồng thời sửa nhiều lỗi chính tả
  • Cập nhật các phụ thuộc SymPy và Python lên phiên bản mới hơn
  • Cũng đã tiến hành các công việc nhằm tăng tốc độ tải ban đầu và giảm mức sử dụng bộ nhớ ban đầu

Hàm tích hợp mới

  • Các hàm tích hợp được thêm trong bản phát hành này như sau
    • $MaxLengthIntStringConversion
    • Elements
    • ComplexExpand
    • ConjugateTranspose
    • LeviCivitaTensor
    • RealAbs, RealSign
    • RealValuedNumberQ

Cải thiện tài liệu và tạo kiểm thử

  • Nhiều vấn đề định dạng trong tài liệu PDF đã được sửa
    • Tăng khoảng cách số mục trong mục lục chương và phần
    • Tăng lề quanh định nghĩa hàm tích hợp
    • Sửa lỗi chính tả trên toàn bộ tài liệu
  • Mã chạy doctest và tạo tài liệu LaTeX đã được sửa đổi, refactor
    • Cho phép cập nhật tăng dần các hàm tích hợp
    • Được sắp xếp lại theo hướng giảm mã trùng lặp
  • Trong “Expression Structure”, phần Section Head-Related Operations mới được bổ sung
  • Tiêu đề PDF đổi từ Mathics sang Mathics3, và phần giới thiệu cũng được cập nhật
  • Các doctest kiểu cũ không hiển thị và không dùng cho mục đích giáo dục được chuyển sang pytest

Thay đổi về tương thích và hành vi người dùng nhìn thấy

  • *Plot không hiển thị thông báo trong khi đánh giá
  • Range[] xử lý di âm
    • PR liên quan: #951
  • Hỗ trợ DirectedInfinity và Indeterminate được cải thiện
  • Graphics và Graphics3D được hiển thị với nền màu hồng khi chứa primitive hoặc directive không hợp lệ
    • Trong giao diện Mathics-Django, thông báo lỗi dạng tooltip cũng được hiển thị kèm theo
  • $CharacterEncoding có thể thay đổi giá trị bên trong phiên làm việc

Thay đổi triển khai nội bộ và API

  • Trong Abs và Sign, eval_abs, eval_sign được tách ra và thêm vào mathics.eval.arithmetic
  • Số chữ số tối đa được cho phép trong chuỗi được đặt là 7000
    • Trong các môi trường như pyston, nơi Python không tự động điều chỉnh, có thể tinh chỉnh bằng biến môi trường MATHICS_MAX_STR_DIGITS
  • Triển khai so sánh số thực được đưa vào nội bộ trong triển khai RealSign
  • Trong Python 3.11, $MaxLengthIntStringConversion kiểm soát kích thước tối đa của chuyển đổi literal giữa số nguyên lớn và chuỗi
  • Việc tải mã tích hợp chuyển từ cách ngầm định sang cách chỉ thị rõ ràng
    • Đây là thay đổi nhằm cho phép tải lười hàm tích hợp trong tương lai, hoặc “autoload” theo kiểu autoload của GNU Emacs
  • Với API mới, cần gọi rõ ràng import_and_load_builtins()
    • Trước đây, thời điểm tải hàm tích hợp là ngầm định và không xác định, phụ thuộc vào thứ tự import
  • mpmath được bổ sung LRU cache

Sửa lỗi Quantity, SparseArray, v.v.

  • Definitions tương thích với pickle
  • Hỗ trợ biểu thức Quantity được cải thiện
    • Bao gồm chuyển đổi, định dạng và phép toán số học
  • Tùy chọn Background của Graphics và Graphics3D hoạt động trở lại
  • Sửa vấn đề so sánh số đối với các biểu thức chứa String
    • Issue liên quan: #797
  • Sửa vấn đề Switch[] chứa Infinity
    • Issue liên quan: #956
  • Sửa vấn đề Outer[] với SparseArray
    • Issue liên quan: #939
  • ArrayQ[] phát hiện được SparseArray
    • PR liên quan: #947
  • Ngoại lệ BoxExpressionError được xử lý
  • Sửa hành vi Derivative đánh giá True, False, List[]
  • Bao gồm các bản sửa cho gói Combinatorica
  • Sửa Exit[] vốn không hoạt động
  • BaseForm được đưa vào $OutputForms

Phiên bản gói được hỗ trợ

  • Hỗ trợ Python 3.11
  • Hỗ trợ SymPy 1.12

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-09
Ý kiến trên Hacker News

  • Tôi đã theo dõi dự án này vài năm nay và nó vẫn phát triển đều đặn rất tốt. Nếu bạn quan tâm đến hệ thống đại số máy tính mã nguồn mở, có rất nhiều giải pháp chín muồi hơn, từ các lựa chọn kinh điển như GNU Octave hay Maxima đến các lựa chọn hiện đại như SAGEmath, Symbolics.jl, sympy.
    Phạm vi rất rộng, từ các thư viện tính toán ký hiệu như GiNaC cho đến IDE “đầy đủ pin” như SAGEmath, và cộng đồng cũng rất sôi động. Chẳng hạn, có thể xem SAGEmath gần như là bên đã tiên phong giao diện notebook trên web, rồi dẫn đến nhiều hình thái Jupyter khác nhau ngày nay.
    Cá nhân tôi thích phong cách kiểu Lisp của Mathematica (MMA), nhưng thứ làm MMA mạnh không chỉ là phần lõi mà còn là thư viện khổng lồ. Nó có các giải pháp hàng đầu trong ngành cho những chủ đề nền tảng như tích phân ký hiệu, đồ họa 2D/3D, phương pháp phần tử hữu hạn, và cả nhiều lĩnh vực chuyên biệt như tin sinh học.
    Mathics có vẻ đã sao chép phần lõi khá tốt, nhưng tất nhiên là thiếu toàn bộ các thư viện đó. Lập luận này cũng tương tự khi so sánh Matlab cùng nhiều “toolkit” với một bản clone của numpy; dù vậy, xu hướng Python hiện nay đã đưa rất nhiều mã mới không chạy trên Matlab vào thế giới numpy.

    • Tôi đồng ý với nhận xét về tiến độ. Dự án này trông như một ví dụ tuyệt vời về việc âm thầm và bền bỉ đào sâu vào thứ mình yêu thích.
      Khoảng 5 năm trước, khi nó mới xuất hiện, tôi đã nghĩ “engine đánh giá ký hiệu này làm thực sự tốt đấy, giờ xem tiếp sẽ ra sao”. Mỗi khi sau này muốn bắt đầu một dự án mới, có lẽ tôi nên nhớ đến ví dụ tiếp tục mài giũa một dự án cũ này.
    • Về phía Lisp, từ Maxima có thể dễ dàng đi vào Common Lisp. Dùng SBCL sẽ tốt hơn vì hiệu năng.
    • Có thể tôi nhầm, nhưng tôi không xem Octave, Matlab, numpy là cùng lĩnh vực với hệ thống đại số máy tính. Tất cả đều là ngôn ngữ hoặc thư viện thiên về tính toán số, dùng để tìm nghiệm số của bài toán hơn là các biểu thức ký hiệu chính xác.
      Chúng bổ sung cho nhau và cũng thường được dùng cùng nhau. Mathematica và Mathics dường như hỗ trợ cả hai mô hình, nhưng không phải là cùng một thứ.

  • Trông có vẻ dựa trên sympy: https://www.sympy.org/en/index.html

  • Nếu chỉ dùng cá nhân thì Wolfram Cloud có thể dùng miễn phí. Có vẻ tệp sẽ bị xóa sau khoảng 30 ngày. Wolfram Engine cũng là một cách dùng Mathematica miễn phí từ dòng lệnh. Dù sao thì có còn hơn không.

    • Cũng có thể mua một chiếc Raspberry Pi có kèm giấy phép Mathematica.
    • Đặt WLJS lên trên Wolfram Engine thì dùng khá thú vị.

  • Có phần giới thiệu đơn giản hơn về Mathics ở đây:
    https://mathics.org/

  • Không hiểu sao tôi có cảm giác cái này sẽ được tích hợp vào SageMath :D

    • Tôi không rõ có động thái thực tế nào nhằm đưa Mathics vào SageMath hay không. Nếu đoán thì có lẽ vì SageMath chủ yếu do các nhà toán học nghiên cứu và các nhà mật mã học phát triển, nên khi đưa một thành phần vào, hiệu năng thường là mối quan tâm cốt lõi.
      Một trong những lý do SageMath là dự án Cython lớn nhất cũng là vì Cython cho phép Sage tận dụng các thư viện C/C++ nhanh.
      Mathics hiện có vẻ không quá nghiêm túc về hiệu năng. Chẳng hạn, cứ thử chạy một microbenchmark nhỏ như "AbsoluteTiming[Sum[i, {i, 1, 100000}]]" trong Mathics, hoặc đọc roadmap là thấy.
      Tất nhiên điều đó không sao cả. Ngôn ngữ lập trình Mathematica có nhiều ứng dụng thú vị mà hiệu năng không quan trọng, ví dụ dùng để cẩn thận theo dõi từng bước một phép toán ký hiệu nào đó cùng với biểu thức.
      Nhưng động lực chính của các nhà phát triển Sage là toán học nghiên cứu tuyến đầu, nơi hiệu năng hầu như luôn rất quan trọng. Lý do Sage không chỉ dùng sympy mà tự triển khai nhiều chức năng tương tự cũng là vì hiệu năng. sympy ưu tiên dễ cài đặt nên có thể tương đối chậm, còn trong SageMath thì dễ cài đặt hoàn toàn không phải ưu tiên.
      Sứ mệnh của SageMath là trở thành một lựa chọn thay thế khả thi cho Mathematica, Matlab, Magma, Maple, nhưng điều đó không có nghĩa là trở thành bản clone. Ví dụ, nó không có nghĩa là chạy trực tiếp mã Mathematica, mà là một lựa chọn thay thế để hỗ trợ trên phần mềm toán học mã nguồn mở những nghiên cứu vốn trước đây phải làm bằng các chương trình mã nguồn đóng đó.

  • Các kỹ sư phần mềm sẽ làm đủ mọi cách để không phải trả chi phí phần mềm.

    • Tôi có giấy phép Mathematica, nhưng vẫn thấy dự án này khá hay. Tôi cũng là kỹ sư phần mềm. Tôi sẽ còn ngạc nhiên nếu các nhà phát triển Mathics không phải là người dùng Mathematica.
    • Không phải vấn đề giá cả, mà là vấn đề tự do.
    • Có những người viết phần mềm cho chính mình, thậm chí còn công bố nó dưới dạng mã nguồn mở.
    • Ngày trước tôi từng trả 20 đô la cho bộ hộp DVD 3 đĩa Debian Sarge kèm sổ tay cỡ tạp chí.

  • Mathematica được cung cấp miễn phí trên Raspberry Pi[1], và hầu hết các trường đại học đều có giấy phép toàn site. Giấy phép “Home & Hobby” cũng không quá đắt: thuê bao là 195 USD/năm, giấy phép vĩnh viễn là 390 USD, và gia hạn chỉ 175 USD[2]
    Nói thật, nếu bạn quan tâm đến việc tinkering nhưng không kham nổi mức giá đó, thì bản crack cũng không khó tìm hay khó cài
    Cá nhân tôi khá thích Mathematica, chính xác hơn là “Wolfram Language”, và cũng hài lòng khi trả tiền giấy phép dùng cho sở thích. Tôi không chỉ nghĩ nó đáng tiền, mà còn xem việc hỗ trợ phần mềm toán học là một “lý do chính đáng” để chi tiền
    Hơn nữa, các nhiếp ảnh gia nghiệp dư thường chi cho những công cụ như Adobe CC nhiều hơn số tiền mà nhiều lập trình viên chi cho toàn bộ công cụ của họ, và tôi không hiểu vì sao lại vậy. Việc sẵn sàng chi hơn 20–40 USD mỗi tháng cho nhiều dịch vụ thuê bao nhưng lại do dự trước phí giấy phép 200–400 USD cũng tương tự
    Tuy vậy, trong trường hợp của tôi, tôi dành thời gian trong Mathematica nhiều hơn gần như bất kỳ chương trình nào được cài trên máy tính
    Dù vậy, phần mềm toán học nguồn mở vẫn có một vị trí quan trọng. Mathematica nhìn chung khá bao quát, nhưng trong toán học nâng cao vẫn còn những thiếu sót lớn
    Đặc biệt có hai lý do khiến khó tin rằng nó sẽ đáp ứng được cả những lĩnh vực toán học “ngách” hơn. Thứ nhất, càng đi vào các lĩnh vực nâng cao hoặc khó hiểu hơn thì lợi tức đầu tư giảm mạnh. Thứ hai, Wolfram Language đã có hơn 6000 hàm tích hợp, nên việc thêm hàng trăm hàm nữa để hỗ trợ toàn diện các lĩnh vực như lý thuyết nhóm là điều không mấy hợp lý
    Có thể hỗ trợ bằng package, nhưng vì không được kernel hỗ trợ như công dân hạng nhất nên sẽ có chi phí hiệu năng, và người dùng cũng phải chủ động tìm để dùng nên phát sinh chi phí về tính tiện dụng
    Vì vậy, các phần mềm nguồn mở như GAP, M2, PARI/GP đóng vai trò quan trọng trong việc lấp các khoảng trống của Wolfram Language. Về phần mình, tôi cũng đóng góp cho các dự án FOSS tương đương với số tiền tôi chi cho giấy phép Mathematica. Với những dự án mà việc đóng góp tiền không đơn giản, tôi cố gắng bỏ thời gian và kỹ năng để cải thiện chúng
    Nói thật, tôi không quan tâm nhiều đến các dự án cố gắng sao chép chức năng của Mathematica. Tất nhiên, các dự án đó vẫn sẽ tiếp tục được phát triển và cải thiện, và ít nhất có thể tạo áp lực để Wolfram Research tiếp tục cải thiện các chức năng cơ bản. Nhưng để những dự án đó bắt kịp Mathematica/WL ngày nay thì có lẽ sẽ mất 10–20 năm
    [1]: https://www.wolfram.com/raspberry-pi/
    [2]: https://www.wolfram.com/mathematica/pricing/home-hobby/

    • Stephen Wolfram có vẻ bị khá nhiều người trên HN ghét, nhưng với toán học thực nghiệm, giải đố, trực quan hóa dữ liệu nhanh, v.v. thì Wolfram là một ngôn ngữ sâu sắc và đẹp
      Notebook tích hợp, tài liệu hiện khi rê chuột, và đáng ngạc nhiên là một namespace khổng lồ duy nhất chứa hàng nghìn hàm somehow kết hợp với nhau, mang lại một trải nghiệm đơn giản và hiệu quả khác với mọi thứ tôi từng dùng. Điều đó đúng dù bình thường tôi cũng không phải kiểu người thích IDE “nặng”

  • Một trong những điểm khó chịu ở Mathematica là tất cả các hàm bị nhồi vào cùng một namespace, và không có overload theo các tùy chọn tham số hóa khác nhau

    • Tôi không rõ overload ở đây nghĩa là gì. Hàm có thể dễ dàng có hành vi khác nhau tùy theo số lượng đối số. Ví dụ như Fold 2 đối số và Fold 3 đối số, và cũng có thể có bao nhiêu option cũng được như Graphics, Graphics3D, Solve, Import/Export
      Trùng lặp lớn mà tôi nghĩ ra chỉ là các hàm Plot khác nhau mà thôi