Features to discuss in-depth

[asmeurer]

SymPy has a ton of features. Here are some suggestions on which ones we should discuss in depth. This already feels like a lot, so we may need to cut some of it as well.

• Basic operations (the core)
• Calculus (differentiation, integration, limits). Integration and limits in particular have nontrivial algorithms behind them.
• Solvers (regular equations, maybe also mention other types of solvers like ODEs/recurrence/Diophantine)
• Matrices (worth including to stress that they are symbolic)
• Assumptions system (could also be part of the core)
• Logic (could also be part of the assumptions section)
• Physics module (some sampling, to show that it is there)
• Printing (results will be printed anyway, so it's worth mentioning it)

This doesn't include discrete math, concrete math, plotting, geometry, statistics, polys, combinatorics/group theory, code generation, lie algebras, cryptography, category theory, special functions, sets, matrix expressions, series, or vectors.

Feel free to disagree with me on what should/shouldn't be discussed in-depth.

[scopatz]

It seems like a lot of these are domain subpackages. So, there should probably be a section on the architecture and extensibility of SymPy to add new subpackages. Then, we could list a few (probably the most used) as examples. Features such as basic operations and printing (and calculus?) would get there own sections

[certik]

I would still mention, at least briefly, the other things you mention, one a simple example.

[asmeurer]

The architecture (and as part of that, extensibility) should probably be its own top level section. "Basic operations" may end up just being part of that section.

I would still mention, at least briefly, the other things you mention, one a simple example.

You mean one example per item?

[certik]

You mean one example per item?

Yes, just one or two examples per item. That usually gives a very good idea what the feature is about. E.g. the statistics can just show a few symbolic distributions.

[asmeurer]

I'm all for it. The paper will end up being a lot of examples, but that's not necessarily a bad thing.

[skirpichev]

ton of features.

And redundant ones ;-) I.e. solvers, assumptions: you have two (or three?) incompatible (for now) systems... Are you planning to explain all this mess?

Integration and limits in particular have nontrivial algorithms behind them.

btw, known to be implemented wrongly (c.f. Gruntz algorithm in the maxima). Are you sure that there are any non-trivial algorithms, not implemented already in some open CAS?

[ashutoshsaboo]

How about if we also add some details about SymPy Live and SymPy Gamma in the paper as well? Maybe just we can describe some important features like the integration steps etc.

[Upabjojr]

How deep are you going to describe the submodules? I can provide targeted descriptions of the parts I know well.

[fredrik-johansson]

And redundant ones ;-) I.e. solvers, assumptions: you have two (or three?) incompatible (for now) systems... Are you planning to explain all this mess?

This depends a bit on the intended audience. For people interested in computer algebra and mathematical software as a field, and not just using the software, it's instructive to explain why there is a mess, and how you try to solve it. Science is not just about documenting what works but also what doesn't.

[skirpichev]

@fredrik-johansson, I'm glad to see that you admit there is something to be explained.

[certik]

@skirpichev are you interested to be an author on this publication?

[skirpichev]

On Wed, Mar 16, 2016 at 08:08:45AM -0700, Ondřej Čertík wrote:

[1]@skirpichev are you interested to be an author on this publication?

Why do you think so? No. I'm not a sympy author.

[certik]

@skirpichev Anybody who contributed substantially to SymPy can be an author on this paper if he or she is interested. So that's why I was asking you. If you are not interested, that is fine. Thank you.

[asmeurer]

@skirpichev given the tone of your comments and the fact that you aren't interested in actually contributing, you're clearly not here to be constructive in any way. I've therefore blocked you. I didn't include it in this repo but the sympy code of conduct applies here.

Let's please return to the original discussion of what features to include in the paper.

[fredrik-johansson]

Again, this depends on the audience, but it's good to try to make the paper more than a laundry list of features with examples.I think it's important to cover how SymPy uses Python classes to represent mathematical objects, and the pros and cons of this. That also goes for managing to do computer algebra with Python's limited syntax. The ideas going into assumptions are important too.

From my own perspective, I would like to have a short section on numerical evaluation, which could include just a short paragraph about mpmath, since there is no standalone mpmath paper (and I don't think I have time to write one). Obviously, mpmath is just a dependency of SymPy now, but I think it's still morally a part of SymPy to the extent that it could deserve a mention. It's worth mentioning that SymPy makes some effort to track errors, though it does so nonrigorously (just like Mathematica). The pros and cons of this can be discussed. If I were to show one feature with an example, I would say that SymPy can evaluate typical definite integrals numerically, both when no symbolic answer is found (numerical integration) and when there is a symbolic form that involves complicated special functions (e.g. Meijer G-functions). I don't want to hijack the paper for my ends in any way, so this is just an idea for a brief addition if no one objects to it.

[asmeurer]

@fredrik-johansson I agree. This issue is supposed to just be to figure out the section that does go over the features. I was trying to figure out how to restrict it, so that it doesn't become a laundry list.

[asmeurer]

And I agree that we should have at least a paragraph on numerics and mpmath, since that is a very core part of SymPy.

[Sumith1896]

I'll write up about the Logic module. We can mention the two variants of dpll that we have and the heuristics implemented(variable selection, etc). I shall be interested in writing about the Polys. May need some help though, this is huge

[asmeurer]

See also https://github.com/sympy/sympy-paper/issues/6

[moorepants]

How about a short section that mentions the capabilities of the physics package? I'm willing to write that.

I'd also like to discuss the code gen stuff and would be willing to write something about that too.

[fredrik-johansson]

Code generation is good. It also makes sense to emphasize the way SymPy fits into the larger Python scientific ecosystem, with the possibility to easily combine it with NumPy (lambdify, is there anything else?).

[shivamvats]

I would like to write about the series module and a brief overview of series expansion strategies we have tried (focusing on speed bottlenecks). Or is it too overcrowded already?

[leosartaj]

I can also help out with the series part. Plus, a brief introduction to how formal power series operate in sympy.

On 31 March 2016 at 11:28, Shivam Vats notifications@github.com wrote:

I would like to write about the series module and a brief overview of series expansion strategies we have tried (focusing on speed bottlenecks).

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sympy/sympy-paper/issues/5#issuecomment-203767646

Regards Sartaj Singh

Mathematics and Computing, Indian Institute of Technology, Varanasi - 221 005 INDIA

E-mail: singhsartaj94@gmail.com, sartaj.singh.apm13@itbhu.ac.in sartaj.singh.apm13@itbhu.ac.in

[shivamvats]

Great!

[Upabjojr]

We should also mention something about the tensor module, though it's far from complete.