Tags: Mobile edit Mobile web edit |
|
(2 intermediate revisions by 2 users not shown) |
Line 1: |
Line 1: |
| {{Note|GNU Octave is a [https://summerofcode.withgoogle.com/programs/2022/organizations/gnu-octave mentoring organization for GSoC 2022].}} | | {{Note|GNU Octave is applying to be a [https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-octave mentoring organization for GSoC 2023].}} |
|
| |
|
| Since 2011 the GNU Octave project has successfully mentored: | | Since 2011 the GNU Octave project has successfully mentored: |
Line 76: |
Line 76: |
| == 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 much of the 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]]. | | 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 much of the 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 a GSoC project successfully re-implemented this communication using the new [[Pythonic|Pythonic package]]. In 2022, a GSoC project revitalized and improved the maintainability of the package. |
|
| |
|
| This project proposes to take this work further while also improving the long-term viability of the Symbolic package. Some goals include:
| | Possible ideas for improving the Symbolic package: |
| * the possibility of using Pythonic directly rather than as one possible communication layer. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "pycall_sympy__" interface and use Pythonic directly from methods. Note: there are open questions about how to do this during a transition time when we still support other IPC mechanisms.
| |
| * exposing more functionality of SymPy with ''less glue'' in between. For example, we could allow OO-style method calls such as <code>f.diff(x)</code> as well as <code>diff(f, x)</code>. | | * exposing more functionality of SymPy with ''less glue'' in between. For example, we could allow OO-style method calls such as <code>f.diff(x)</code> as well as <code>diff(f, x)</code>. |
| * Improvements to the Pythonic package and its long-term maintenance. | | * Fix the storage of non-expressions by working with upstream SymPy: currently we rely on deprecated functionality in SymPy. |
| * fixing up Symbolic to work with the latest releases of SymPy and Octave. The project has lagged for a few years and needs some efforts to port to recent and upcoming changes in SymPy code.
| | * Fix classdef-related issues in Octave itself. |
| * making Symbolic easier to maintain. The project currently has a low ''bus factor'': improving the CI, making regular releases easier, improving other aspects of maintenance and making the project more welcoming to newcomers.
| |
| | |
| Working on this project involves and interesting and challenging mix of m-file code, Python code, and in the case of Pythonic, perhaps some lower-level C code.
| |
| | |
| * '''Project size''' [[#Project sizes | [?]]] and '''Difficulty''' | |
| : ~350 hours (medium)
| |
| * '''Required skills'''
| |
| : Octave, C/C++, Python; object-oriented programming (OOP) in Octave
| |
| * '''Potential mentors'''
| |
| : [https://octave.discourse.group/u/cbm Colin B. Macdonald], [https://octave.discourse.group/u/mtmiller Mike Miller], Abhinav Tripathi
| |
| | |
| == Improve TIFF image support ==
| |
| | |
| [https://en.wikipedia.org/wiki/TIFF Tag Image File Format (TIFF)] is the de facto standard for scientific images. Octave uses the [http://www.graphicsmagick.org/ GraphicsMagic] (GM) C++ library to handle [http://www.graphicsmagick.org/formats.html TIFF and many others image formats]. However, GM still has several limitations:
| |
| | |
| * GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image:
| |
| ** Building GM with '''high quantum''' means that images of smaller bitdepth will take a lot more memory when reading.
| |
| ** Building GM with '''low quantum''' will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.
| |
| * GM supports unsigned integers only, thus incorrectly reading files such as TIFF with floating-point data.
| |
| * GM hides details of the image such as whether the image file is indexed. This makes it hard to access the real data stored on file.
| |
| | |
| This project aims to implement better TIFF image support using [https://en.wikipedia.org/wiki/Libtiff libtiff], while leaving GM handle all other image formats. After writing a [https://octave.org/doc/v6.1.0/classdef-Classes.html classdef] interface to libtiff, improve the Octave functions {{manual|imread}}, {{manual|imwrite}}, and {{manual|imfinfo}} to make use of it.
| |
| | |
| * '''Project size''' [[#Project sizes | [?]]] and '''Difficulty'''
| |
| : ~175 hours (medium)
| |
| * '''Required skills'''
| |
| : Octave, C/C++
| |
| * '''Potential mentors'''
| |
| : [https://octave.discourse.group/u/carandraug Carnë Draug]
| |
|
| |
|
| == PolarAxes and Plotting Improvements == | | == PolarAxes and Plotting Improvements == |