Summer of Code - Getting Started: Difference between revisions

The following is distilled from the [[Projects]] page for the benefit of potential [https://summerofcode.withgoogle.com Google] and [https://socis.esa.int/ ESA] Summer of Code (SoC) students. Although students are welcome to attempt any of the projects in that page or any of their own choosing, here we offer some suggestions on what good student projects might be.

*:* '''Hang out in our [https://webchat.freenode.net/?channels=#octave IRC channel]'''. Ask questions, answer questions from users, show us that you are motivated, and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your public application to increase the strength of your proposal!

*:* When you email the list and mentors, do not write it to say in what project you're interested. Be specific about your questions and clear on the email subject. For example, do not write an email with the subject "GSoC student interested in the ND images projects".  Such email is likely be ignored.  Instead, show you are already working on the topic, and email "Problem implementing morphological operators with bitpacked ND images".

*:* It is good to ask advice on how to solve something you can't but you must show some work done.  Remember, we are mentors and not your boss.  Read [http://www.catb.org/esr/faqs/smart-questions.html How to ask questions the smart way]: <blockquote>''Prepare your question. Think it through. Hasty-sounding questions get hasty answers, or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.''</blockquote>

*: It's '''critical''' that you '''find a project that excites you'''.  You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).

*:* Only the organization admin and the possible mentors will see this data.  You can still edit it after submitting until the deadline!

*: Unless your primary mentor has a strong preference for some other method of communication, the IRC channel will likely be your primary means of communicating with your mentor and Octave developers.

[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/libinterp/dldfcn/__ode15__.cc __ode15__.cc],

[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15i.m ode15i.m] and

[http://hg.savannah.gnu.org/hgweb/octave/file/4890b1c4a6bd/scripts/ode/ode15s.m ode15s.m].

* make ode15{i,s} with datatypes other than double

Other tasks, not strictly connected to ode15{i,s} but closely related that could be added  

bicgstab, cgs, gmres, and qmr (general matrices). The description of some of them (pcr, qmr) and their error messages are not aligned. Moreover, they have similar blocks of code (input check for instance) which can be written once and for all in common functions. The first step in this project could be a revision and a synchronization of the codes, starting from the project [https://socis16octave-improveiterativemethods.blogspot.com/ SOCIS2016] which is already merged into Octave (cset {{cset|6266e321ef22}}).

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 [[Pythonic|Pythonic package]].

[http://jupyter.org Jupyter Notebook] is a web-based worksheet interface for computing.  There is a [https://github.com/Calysto/octave_kernel Octave kernel for Jupyter].  This project seeks in first place to improve that kernel to make Octave a first-class experience within the Jupyter Notebook.

In general the [https://nbformat.readthedocs.io/en/latest/ Jupyter Notebook Format] is a plain JSON document, which is supported since Octave 7 (current development version).  Another valuable project outcome was to run (and fill) those Jupyter Notebooks from within Octave.  This would enable Jupyter Notebook users to evaluate long running Octave Notebooks on a computing server without permanent browser connection, which is [https://github.com/jupyter/notebook/issues/1647 still a pending issue].

For example, there are specifications published by freedesktop.org about where files should go ([http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html base directory spec]) and Windows seems to have its own standards.

One horrible way to workaround this by is choosing increasingly complex package names that give no hint on the package purpose.

As part of GSoC 2013, the core functions for image IO, {{codeline|imwrite}} and {{codeline|imread}}, were extended to better support this type of images. Likewise, many functions in the image package, mostly morphology operators, were expanded to deal with this type of image. Since then, many other functions have been improved, sometimes completely rewritten, to abstract from the number of dimensions. In a certain way, supporting ND images is also related to choosing good algorithms since such large images tend to be quite large.

This project will continue on the previous work, and be mentored by the previous GSoC student and current image package maintainer. Planning the project requires selection of functions lacking ND support and identifying their dependencies. For example, supporting {{codeline|imclose}} and {{codeline|imopen}} was better implemented by supporting {{codeline|imerode}} and {{codeline|imdilate}} which then propagated ND support to all of its dependencies. These dependencies need to be discovered first since often they are not being used yet, and may even be missing function. This project can also be about implementing functions that have [[Image package#Missing functions | not yet been implemented]]. Also note that while some functions in the image package will accept ND images as input, they are actually not correctly implemented and will give incorrect results.

: m-file scripting, and a fair amount of C++ since a lot of image analysis cannot be vectorized. Familiarity with common CS algorithms and willingness to read literature describing new algorithms will be useful.  

There are a lot of image formats. To handle this, Octave uses [http://www.graphicsmagick.org/ GraphicsMagic] (GM), a library capable of handling [http://www.graphicsmagick.org/formats.html a lot of them] in a single C++ interface. However, GraphicsMagick still has its limitations. The most important are:

* GM supports unsigned integers only thus incorrectly reading files such as TIFF with floating point data

* GM hides away details of the image such as whether the image file is indexed.  This makes it hard to access the real data stored on file.

* implement the Tiff class which is a wrap around libtiff, using classdef. To avoid creating too many private __oct functions, this project could also create a C++ interface to declare new Octave classdef functions.

* port the bioformats into Octave and prepare a package for it

* prepare a matlab compatible implementation of the FITS package for inclusion in Octave core

: Knowledge of C++ and C since most libraries are written in those languages.

Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listerners to get things to work.  What is needed is a first class implementation of a "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" exist 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.  relates to {{bug|35565}}, {{bug|49804}}, {{bug|52643}}.