Differences between revisions 7 and 10 (spanning 3 versions)
Revision 7 as of 2015-02-08 15:11:51
Size: 1386
Editor: vdelecroix
Comment:
Revision 10 as of 2015-02-10 14:32:51
Size: 3720
Editor: schilly
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
== Introduction ==
Sage is a GPLed open-source mathematical software system. It is designed to be not just a computer algebra system, but more like a complete environment for doing mathematics and related calculations. It is based on a vast collection of existing open-source software tools and libraries and ties them together via Python. This is also the primary interface language for the user and its object-oriented way of expressing concepts is used to express calculations - of course, there are also many “normal” functions :-) Behind the scenes, the Sage library executes the commands and calculations by its own algorithms or by accessing appropriate routines from the included software packages. On top of that, there are various ways how users can interact with Sage, most notably a dynamic web-site called “Notebook”.

All projects will start with an introduction phase to learn about Sage’s internal organization and to get used to its established development process. This is documented in the documentation for developers and all students will be instructed by the mentors on how to get their hands dirty. We use Git for revision control and trac for organizing development and code review. Our license is GPLv2+. Feel free to contact Mentors before you send us project proposals.

Feel free to introduce yourself and your project idea in our [[https://groups.google.com/forum/#!forum/sage-gsoc|mailing list]].

To get a better feeling how Sage works, please check out the [[http://sagemath.org/doc/developer/index.html|developer guide]].
Line 20: Line 28:
In Sage there are various places where we have several possibilities to execute a task (e.g. calling pari or gap or a native sage function). It would be interesting to have a way of choosing the default parameters by performing benchmarkings at build time. That would also allow to check coherency between various implementations. In Sage there are various places where we can choose between several algorithms or underlying softwares to solve a problem. In Sage, this is often related to the presence of the keyword ''algorithm'' or ''method'' in methods and functions. The aim of this task is to build a generic dispatcher that would choose depending on the parameters the fastest solution available. The solution must be very light and not affect performance. The dispatch threshold must be static and decided at build time. This generic dispatcher could also be used to check coherency between the various implementations.

Note that it is different from what is called multimethods where the dispatch depends only on the input type. Here we consider a dispatcher that might also depend on the input values.

 * competence: good knowledge of Python and notions of Cython and C
 * (draft) timeline:
  1. write a simple prototype of generic dispatcher
  2. identify Sage functions/methods that could benefit from the dispatcher and test it
  3. release a first candidate for the dispatcher
  4. Sage integration

Project ideas for GSoC 2015 for Sage

Introduction

Sage is a GPLed open-source mathematical software system. It is designed to be not just a computer algebra system, but more like a complete environment for doing mathematics and related calculations. It is based on a vast collection of existing open-source software tools and libraries and ties them together via Python. This is also the primary interface language for the user and its object-oriented way of expressing concepts is used to express calculations - of course, there are also many “normal” functions :-) Behind the scenes, the Sage library executes the commands and calculations by its own algorithms or by accessing appropriate routines from the included software packages. On top of that, there are various ways how users can interact with Sage, most notably a dynamic web-site called “Notebook”.

All projects will start with an introduction phase to learn about Sage’s internal organization and to get used to its established development process. This is documented in the documentation for developers and all students will be instructed by the mentors on how to get their hands dirty. We use Git for revision control and trac for organizing development and code review. Our license is GPLv2+. Feel free to contact Mentors before you send us project proposals.

Feel free to introduce yourself and your project idea in our mailing list.

To get a better feeling how Sage works, please check out the developer guide.

Notebook mode with execution from top to bottom

In the current notebook (both Sage notebook and IPython notebook) the cells can be executed in any order. From a teaching point of view this is terrible and from a scientific point of view this leads to highly non reproducible computations.

The purpose of this task is to have a new mode for the IPython notebook that would force computations from top to bottom. If a cell is executed, then the state in which it is executed must be the one you obtain by executing all the cells above it. In order to make it work, one needs to save the Python state after each cell.

note: this is note completely Sage oriented... (see with IPython people)

Native GUI

Adapt Spyder to work with Sage.

See also this thread on sage-devel.

generic dispatcher

In Sage there are various places where we can choose between several algorithms or underlying softwares to solve a problem. In Sage, this is often related to the presence of the keyword algorithm or method in methods and functions. The aim of this task is to build a generic dispatcher that would choose depending on the parameters the fastest solution available. The solution must be very light and not affect performance. The dispatch threshold must be static and decided at build time. This generic dispatcher could also be used to check coherency between the various implementations.

Note that it is different from what is called multimethods where the dispatch depends only on the input type. Here we consider a dispatcher that might also depend on the input values.

  • competence: good knowledge of Python and notions of Cython and C
  • (draft) timeline:
    1. write a simple prototype of generic dispatcher
    2. identify Sage functions/methods that could benefit from the dispatcher and test it
    3. release a first candidate for the dispatcher
    4. Sage integration

Android App

iOS App

SageMathCloud

T.B.A.

GSoC/2015 (last edited 2015-03-16 20:44:44 by schilly)