99
edits
Summer of Code - Getting Started: Difference between revisions
m
→Symbolic package: fix link
(→Symbolic package: update for 2017) |
m (→Symbolic package: fix link) |
||
| Line 167: | Line 167: | ||
=== Symbolic package === | === Symbolic package === | ||
Octave's [https://github.com/cbm755/octsympy Symbolic package] handles symbolic computing and other CAS tools. The main component of Symbolic is a pure m-file class "@sym" which uses the Python package [https://www.sympy.org SymPy] to do (most of) the actual computations. The package aims to expose the full functionality of SymPy while also providing a high-level of compatibility with the Matlab Symbolic Math Toolbox. The Symbolic package requires communication between Octave and Python. Recently, a GSoC2016 project successfully re-implemented this communication using the new [https://bitbucket.org/mtmiller/pytave | Octave's [https://github.com/cbm755/octsympy Symbolic package] handles symbolic computing and other CAS tools. The main component of Symbolic is a pure m-file class "@sym" which uses the Python package [https://www.sympy.org SymPy] to do (most of) the actual computations. The package aims to expose the full functionality of SymPy while also providing a high-level of compatibility with the Matlab Symbolic Math Toolbox. The Symbolic package requires communication between Octave and Python. Recently, a GSoC2016 project successfully re-implemented this communication using the new [https://bitbucket.org/mtmiller/pytave Pytave tool]. | ||
This project proposes to go further: instead of using Pytave only for the communication layer, we'll use it throughout the Symbolic project. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "python_cmd" interface and use Pytave directly from methods. The main goal was already mentioned: to expose the *full functionality* of SymPy. For example, we would allow OO-style method calls such as "f.diff(x)" instead of "diff(f, x)". | This project proposes to go further: instead of using Pytave only for the communication layer, we'll use it throughout the Symbolic project. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "python_cmd" interface and use Pytave directly from methods. The main goal was already mentioned: to expose the *full functionality* of SymPy. For example, we would allow OO-style method calls such as "f.diff(x)" instead of "diff(f, x)". | ||