Introduction

[asmeurer]

Does it seem like a good intro? What else should be mentioned here?

[moorepants]

This makes me want to step back and talk about what the "theme" of the paper is. Being that we are submitting this as an academic publication, it would be worth thinking about what the academic contribution of SymPy is. If the paper is strictly a description of a particular software, I'm not sure typical journals will be that fond of accepting it (have we chosen a journal?). The intro can set the tone for the theme. Another good question I like to ask when writing papers is "What story do we want to tell?".

It isn't yet clear to me what story we are telling. It would be nice if we can show how SymPy solves particular problems better than other CASs, or is more suitable for scientific work, or that community driven CAS development creates software that better suites scientific computing needs.

Have we had any conversation about this yet? I may have missed it.

This intro could help set the tone of all the other sections.

[Upabjojr]

an ===> a

[asmeurer]

Yeah, OK, let's discuss what the introduction should be. I just sat down and wrote what I felt should go here, but I think it could be better.

The point of the paper is to be the paper for SymPy, i.e., this will be the paper that people cite when they use SymPy.

To that end, I feel it should primarily answer two questions: "what is SymPy?" and "why were the various aspects of its design done the way they were?"

So my goal in writing this was to give high level answers to these questions. The rest of the paper will go into more detail. For example: what is SymPy? It's an open source computer algebra system written in Python. Why is it written in Python? I tried to answer that here. What are the core principles of its design, and why? I also attempted to hit this here, with at least one core principle (usability as a library). I may have gone off too much on a tangent with some nuances from choosing Python (it probably should be moved to the architecture section).

What are the other core design principles, which deserve discussion in the introduction? I'm not sure. "Using Python" and "being a library" are two that come to mind, but I may have missed some. Perhaps the goal of being "full featured" deserves some further discussion. Also, this can be inspiration.

I do think that we collectively are not really agreed on the theme of the paper, which is clear from the conflicting desires of the various pull requests. So what do others think the theme should be? Do you agree with my assessment above?

[moorepants]

Aaron, I like what you say above:

• Should be the paper for SymPy.
• Should answer "What is SymPy?"
• Should answer "Why were the various aspects of design done the way they were?"

I'd add these:

• Should answer "Why is SymPy useful to researchers, educators, and companies?"
• Should answer "How does SymPy compare to other similar software and why should you use it instead of or alongside them?"

I think these two are a bit more important wrt to the sympy paper than the design decisions. The design decisions are more interesting to designers of CAS systems and less so for users.

One question to ask ourselves:

Who is the intended audience?

Finally, I was thinking that we could write the abstract first. If we can agree on an abstract it will frame the "mission" of the paper. Then when each person writes their section, they can refer to the mission to judge whether what they are writing fits the theme.

[aktech]

• Should answer "Why is SymPy useful to researchers, educators, and companies?"
• Should answer "How does SymPy compare to other similar software and why should you use it instead of or alongside them?"

I think these two are a bit more important wrt to the sympy paper than the design decisions. The design decisions are more interesting to designers of CAS systems and less so for users.

@moorepants I cannot agree with you more, here. +1

[ashutoshsaboo]

Hi,

I somewhat agree with @moorepants . It'll be very useful, if we mention the way SymPy helps educators, researchers, and companies, as Mr. Moore suggested. It would also provide the targeted audience a reason, as to why to use SymPy if we write about the above. So, I guess, the addition of the 2 points that Mr. Moore suggested above, would make our introduction, a pretty good one @asmeurer .

In that way, we could also easily build up for explaining all the full, extensive features list of SymPy as well.

But, I guess we must also not miss upon the important architecture details of SymPy as a CAS, and I feel that, they must only be mentioned in the Architecture section, and not the Introduction. @asmeurer

[moorepants]

@asmeurer Can you fix @Upabjojr's comments?

We can move the theme discussion to a new issue.

[scopatz]

This sentence sounds more like an advertisement. I would get rid of it or move it later in the paper. This isn't supposed to be a paper on the community, per se. And @certik is an author of the paper so it is weird to mention his name here.

[asmeurer]

Maybe Ondrej's name shouldn't be mentioned, but I did want to highlight the community.

[asmeurer]

It sounds like this will need to be rewritten.

[asmeurer]

OK, everyone, see my rewrite. I've tried to de-subjectify most of it.

I also tried to expand a bit of the intro paragraph about the community, taking some bits from @moorepants's #84, but it probably could use some work (feel free to suggest a rewrite).

[asmeurer]

I have finished the introduction, and made other changes here as well. I will merge tomorrow if no one has any comments.