1,852
edits
Summer of Code - Getting Started: Difference between revisions
Jump to navigation
Jump to search
→Adding functionality to packages: Some improvments.
(→Adding functionality to packages: Alphabetical order.) |
(→Adding functionality to packages: Some improvments.) |
||
| Line 122: | Line 122: | ||
== Adding functionality to packages == | == Adding functionality to packages == | ||
=== OCS === | === OCS package === | ||
[[Ocs package | OCS]] is a circuit simulator | The [[Ocs package | OCS package]] is a circuit simulator. The objective of this project is to increase compatibility with [https://en.wikipedia.org/wiki/SPICE SPICE] and improve compatibility with other Octave packages, e.g. the [[Control package]]. Please study the [https://octave.sourceforge.io/ocs/overview.html available functions] of this package. | ||
* '''Required skills''' | * '''Required skills''' | ||
| Line 135: | Line 133: | ||
=== Symbolic package === | === Symbolic package === | ||
The [[Symbolic package]] provides symbolic computing and other [https://en.wikipedia.org/wiki/Computer_algebra_system computer algebra system] 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. In 2016 another GSoC project successfully re-implemented this communication using the new [[Pythonic|Pythonic package]]. | |||
This project proposes to go further: instead of using Pythonic 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 Pythonic directly from methods. The main goal was already mentioned: to expose the | This project proposes to go further: instead of using Pythonic 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 Pythonic 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 <code>f.diff(x)</code> instead of <code>diff(f, x)</code>. | ||
* '''Required skills''' | * '''Required skills''' | ||