Summer of Code - Getting Started: Difference between revisions

The {{manual|decic}} function for selecting consistent initial conditions for ode15i can be made more Matlab compatible by using [https://faculty.smu.edu/shampine/cic.pdf another algorithm].  Another useful extension is to make ode15{i,s} work with datatypes other than double and to improve interpolation at intermediate time steps.

* '''Required skills'''

* '''Potential mentors'''

== Using Python within Octave ==

Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list].  You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests.  As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?

* '''Required skills'''

* '''Potential mentors'''

== Improve TIFF image support ==

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.

* '''Required skills'''

* '''Potential mentors'''

== PolarAxes and Plotting Improvements ==

Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listeners to get things to work.  What is needed is the implementation of a dedicated "polaraxes" object in C++.  This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object.  When "polaraxes" exists as an object type, then m-files will be written to access them, including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m.  This relates to bug {{bug|49804}}.

* '''Required skills'''

* '''Potential mentors'''

== Table datatype ==

Based upon the existing approaches, the goal of this project is to define an initial subset of [https://www.mathworks.com/help/matlab/tables.htmlMatlab's table functions], which involve sorting, splitting, merging, and file I/O and implement it within the given time frame.

* '''Required skills'''

* '''Potential mentors'''

[https://en.wikipedia.org/wiki/YAML YAML], is a very common human readable and structured data format.  Unfortunately, GNU Octave (and Matlab) still lacks of builtin support of that omnipresent data format.  Having YAML support, Octave can easily read and write config files, which often use YAML or JSON.  The latter JSON format has been [[Summer of Code#GSoC_2020 | successfully implemented for Octave during GSoC 2020]].

Then evaluate (and to cherry pick from) existing implementations above, compare strength and weaknesses.  After this, an Octave package containing en- and decoding functions (for example <code>yamlencode</code> and <code>yamldecode</code>) shall be created.  This involves proper documentation of the work and unit tests to ensure the correctness of the implementation.

* '''Required skills'''

* '''Potential mentors'''

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 ''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'''

* '''Potential mentors'''

The [[TISEAN package]] provides an Octave interface to [https://www.pks.mpg.de/~tisean/Tisean_3.0.1/index.html TISEAN] is a suite of code for nonlinear time series analysis.  In 2015, another GSoC project started with the work to create interfaces to many TISEAN functions, but [[TISEAN_package:Procedure | there is still work left to do]].  There are missing functions to do computations on spike trains, to simulate autoregresive models, to create specialized plots, etc.  Which are of importance for many scientific disciplines involving statistical computations and signal processing.

* '''Required skills'''

* '''Potential mentors'''

[[Category:Summer of Code]]

[[Category:Project Ideas]]