99
edits
Summer of Code - Getting Started: Difference between revisions
Jump to navigation
Jump to search
→Symbolic package: tweaks and formatting
(→YAML encoding/decoding: reduce project size) |
(→Symbolic package: tweaks and formatting) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 89: | Line 89: | ||
== 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 | 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]]. | ||
This project proposes to | This project proposes to take this work further while also improving the long-term viability of the Symbolic package. Some goals include: | ||
* 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>. | |||
* Improvements to the Pythonic package and its long-term maintenance. | |||
* 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. | |||
* 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''' | * '''Project size''' [[#Project sizes | [?]]] and '''Difficulty''' | ||
| Line 99: | Line 106: | ||
* '''Potential mentors''' | * '''Potential mentors''' | ||
: [https://octave.discourse.group/u/cbm Colin B. Macdonald], [https://octave.discourse.group/u/mtmiller Mike Miller], Abhinav Tripathi | : [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 == | ||