GSoC 2022 Symbolic package project

Hello Octave,


I’m Alex Vong, now living in Australia. I had previously made (small) contributions to octsympy when I was a university student in Hong Kong. I want to participate in GSoC 2022 working on the Symbolic package project.

Some thoughts on the project

I’ve read the Wiki page. My understanding is that we want to:

  1. expose full functionality of sympy through the pythonic interface
  2. deprecate python_cmd in favour of using the pythonic interface
  3. implement OO-style method calls (I am not exactly sure what to do here, are we emulating sympy API or matlab API here?)


Finally, do I need to use hg and latest octave version for this project? I will learn them if they are required. Also, I’m not exactly sure how to write a proposal. It would be great to get some guidance if possible.

Thanks for you interest in the symbolic package project and your short introduction :slightly_smiling_face: The symbolic package is highly demanded and help with its development is certainly appreciated.

@cbm and @mtmiller are potential mentors and experts for this projects and might share some thoughts with you.

1 Like

I’ve created an issue in the octsympy repo to receive feedback from potential mentors @cbm, @mtmiller and others :slight_smile:

1 Like

Hello Colin B. Macdonald and Mike Miller,

I am writing to inform you of my intention of participating in GSoC 2022 working on the Symbolic package project. @siko1056 suggested you could be my potential mentors. More details can be found in this Octave Discourse thread:

It would be great if you can share some thoughts with me. I am CC’ing the octave discourse thread to make it easier to keep track of everything.


@alexvong1995 Thank you very much for your interest and your previous engagement with the symbolic package. After one week without response by @mtmiller or @cbm, I am afraid they cannot share enough time this year for mentoring this project. Therefore, I removed this project from the wiki page for now.

If you can get an answer (maybe by direct mail) or if it happens that another Octave developer was interested in mentoring the symbolic package project, please let me know. The symbolic package is very high demanded and needs updates for recent SymPy versions.

Again, I am very sorry that this project cannot happen this year and that I did not remove the project earlier from the wiki page.

Thanks for the update. Given the current situation, is it possible for me to work on the Improve TIFF image support project instead? AFAIK the openlibm project and the YAML encoding/decoding project have already been selected by other participants.

Hi Alex,

Sorry I didn’t get to this. And thank you for your contributions in the past. I’m not opposed to mentoring Symbolic projects but I haven’t been putting much (any) time into the project recently.

Briefly on your proposal: finishing Pythonic to the point where it could be the default python_cmd would be wonderful but work on Pythonic is not something I feel I could supervise alone without @mtmiller. It could however be part of a project. There are urgent items (that are "lower hanging fruit) about porting Symbolic to the latest SymPy, porting the old deprecated/broken Travis CI stuff to either Gitlab Actions or another freer CI/CD platform, and others. If you want to try to move a proposal forward, perhaps work some of those into a longer theme.

(But perhaps Symbolic is “off the menu” this year: I’m certainly not offended. given my own lack of commitment currently).

1 Like

Shall I put it back in the wiki again? Until 2022-04-19T18:00:00Z there might appear several more requests for this project.

@alexvong1995 The good news is: no project has yet a selected contributor :slightly_smiling_face: The selection of the participants starts after April 19.

Until April 19 you and other potential contributors must convince us, that you are the right persons to work on the projects you want to work on. Actually, I think you are a great candidate for the symbolic package project and @cbm offers you support. In the end it is your decision what you would like to work on. I only wanted to avoid that you put lots of energy in this application without any response from the Octave side. This situation has changed thanks to @cbm :wink:

1 Like

I did spend a few hours getting somehow function CI working again. So sure let’s put it back on the menu.

Shall I undelete those wiki edits then?

1 Like

Many thanks :slightly_smiling_face: I added the “Symbolic package” project in the wiki again :white_check_mark: Would you also like to mentor the Pythonic project if students apply for it?

It’s nice hear that octsympy is “on the menu” again as it’s something I’m more familiar with and actually used before :slight_smile:

After considering your comment & discussion with @siko1056, I think my proposal should include:

  1. support latest sympy 1.10.1 (fix all failed tests broken by the update)
  2. fix not-so-difficult help wanted issues
  3. update sympy to use pythonic whenever make sense (e.g. expose full functionality of sympy through the pythonic interface, deprecate python_cmd in favour of using the pythonic interface, …) if time allows & mentoring is available

WDYT? I’ll go ahead and warm up if the above looks good to you.

Finally, as I’ve never written a proposal before, are there things I need to keep in mind when writing it?

That sounds good @alexvong1995. Thanks @siko1056

Re: proposal writing: it can be good to think in terms of things you definitely feel you can accomplish and then some stretch goals too. Its also good to be specific; see if you can demonstrate that you’ve thought about things beyond what others have written.

Symbolic has had some maintainer problems in the past (cough cough). How can you leave the project in a better state for the future?

1 Like

Would you also like to mentor the Pythonic project if students apply for it?

This I’m less confident about without @mtmiller. I shall try to edit the wiki a bit later to reflect current reality.

1 Like

I’ve submitted my first draft proposal. While it is obviously unfinished / unpolished, it would be great to receive some feedback so that I can work on parts which need improvement. For examples, is the summary too short / too long / just right? Also, I’m not sure which sections are needed / redundant. Thanks!

1 Like

I’ll post some general comments here publicly in the hopes they are useful to anyone else preparing applications.

  • perhaps you can use the biographical part to describe youself and why you’re a good fit for the project
  • expanding on “benefits to the community” seems like a good idea. For example, why is this package important to the community?
  • You’ve written this as core bit and then an optional bit. Can you improve how the core part leads to the optional bit? And maybe some parts of the optional bit can expanded on and made into concrete goals? Its understandable that it is a bit subject to mentor support but I think that makes it more important to expand on the plans a bit.

Yeah I think that was written before pycall_sympy__. python_cmd can (probably?) be dropped in 3.0.0

I tweaked the wiki a bit.


Great, the Wiki page is now much clearer :slight_smile:

For example, we might make "@sym" a subclass of "@pyobject".

As someone with (a bit of) functional programming background, I would argue that subclassing / inheritance often make things more complicated by coupling the implementation of the child class with that of the parent class, making it difficult to understand / change one without understanding / changing the other. Also, if the Liskov substitution principle is violated, which can happen in practice if not handled carefully, surprising behaviour will occur.

It appears to me that parametric polymorphism (e.g. type variables in Haskell and generics in Rust) and ad-hoc polymorphism (e.g. type class in Haskell and multimethods in Clojure) should be preferred over subclassing / inheritance. In fact, ad-hoc polymorphism is used routinely in Octave. For example, functions often work on input of different types, such as scalars, vectors, matrices and syms.

For octsympy, what I have in mind is to create a (classdef) class for sym acting as a thin wrapper for the underlying Sympy objects, and use octsympy functions and primitive py.sympy methods directly on sym instead of calling pycall_sympy__. I’ll put this on my proposal to make it more concrete and detailed. More experimentation is needed to show it really works.

I’ve uploaded the lastest version of my proposal. Feel free to comment on it.