2012/2/14 Ondřej Čertík <[email protected]>: > Hi, > > Here are a few more GSoC ideas. Let's brainstorm it a little bit > and then add to the wiki. > > 1) Better integration with ipython (html) notebook. > > Goal: Allow people to use the .ipynb (ipython notebook) > format just like people currently use the .nb Mathematica > notebook format. > > This my or may not be a good fit for GSoC, as Brian > has already implemented most of the things, but > anyway: > > This means, to make sure that latex/mathjax printing works > out of the box, that plotting works as easily as in Mathematica > (out of the box). > > Probably write some scripts/document how to load the notebook > in an ipython session and in the html notebook. How to > manipulate notebooks. > > Possible extensions are loading to and from ReST.. > > Integration with Sphinx --- so that sphinx pages like this: > > http://theoretical-physics.net/dev/src/math/spherical-harmonics.html > > that contain lots of math and Python/SymPy code can be made > interactive using the ipython notebook --- I don't know if > this means to convert ReST (sphinx) into the notebook and back, > or adding some markups into sphinx, or something like that. > > Speaking for myself, as a user: I want to keep the book in sphinx > (so that it looks uniform on the web as well as in printed form using > latex), but I also want to make it interactive using the notebook. > I would prefer to keep it in sphinx, but possibly add some markups, > so that an ipython notebook can be automatically created from it. > > > Currently the notebook can only be used locally, since there is > no public notebook service so far (i.e. hosted by somebody). > Once there is, it would > be nice to be able to use the notebook interactively online.
This is indeed important. Also, should convert our examples to use the notebook, which would require doctesting support (https://github.com/ipython/ipython/issues/1195). I'm not sure if this alone is enough for a GSoC summer, though. Also, many things here are actually improvements to the IPython notebook, so we would have to make sure that they are onboard as well. > > 2) online shell + plotting > > Allow to make the sphinx examples interactive in the sphinx. > Implement plotting. > > See also the discussion in the thread "Some ideas for GSoC". I forgot about this. Part of improving SymPy Live would be to finalize Mateusz's Sphinx extension that puts it in SymPy Live (see http://code.google.com/p/sympy/issues/detail?id=2871. Unfortunately, it seems that the live demo is broken). This would make our docs interactive. Perhaps we could further improve SymPy Live to be compatible with the IPython notebook, essentially getting everything. By the way, what is your opinion on the ideas I expressed in that thread? It would be great if you could reply to that thread. > > 3) Plotting (matplotlib, app engine) > > Allow to do plotting on the online shell. Honestly, > rather than duplicating the work of ipython notebook, > the best would be to reuse it somehow. > > On the other hand, the ipython notebook doesn't > run on the appengine (and thus it is not served > online anywhere), while our code does. > > So I don't know. The App Engine is supposed to support numpy at some point, if I remember correctly. In that case, we should be able to run matplotlib. Does anyone know what the timeline for that is? > > 4) Documentation > > Our documentation can be greatly improved, > from making it more detailed, to have some list > of the most used functions/classes in some easy to access > format, something like: > > http://www.mathstudio.net/manual/ > > or > > http://reference.wolfram.com/mathematica/guide/MathematicsAndAlgorithmsOverview.html > > (We need to write this completely on our own without reusing anything > from their sites, not even the structure.) We should just use Sphinx. We are almost there, to have every public docstring in Sphinx. What we need to do is improve our doctest quality tester to check for this (see http://code.google.com/p/sympy/issues/detail?id=3075). Then, it's just a trivial matter to import the docstrings that aren't there. Individually, the first four ideas are not really enough for a project, I think. But we could combine them into one or two, and it should be enough. For example, we could have a project to improve documentation, which would include: - Improving docstring/doctest coverage to 100%. - Importing all docs into Sphinx. - Improving coverage_doctest.py to properly test the above, and run it with sympy-bot (setup.py test) - Fix up the SymPy Live extension for Sphinx, so that we can have interactive docs - Allow to run the docs interactively in an IPython notebook as an alternative to using the SymPy Live extension (or somehow merge the two). - Write further documentation (examples, tutorials, writeups for modules, etc.) > > 5) Assumptions > > Goal is to add lots of examples and documentation for the new assumption, > implement missing features, make sure refine() and ask() work for everything > that Mathematica can do. Make sure the solver() and integrate() can work > with new assumptions. > Note: the goal is not to remove the old assumptions (too difficult, > not suitable for GSoC). I don't know if I agree with that. I think such a project should be to remove the old assumptions, and then use whatever time remains to improve the new assumptions. It seems to me that it would be better to start using the new assumptions before we improve upon them, so that we will know about what will work and what won't. > > > > > Ondrej > Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
