SymPy - a suggestion

[David Bailey]

Hello,

I used to work as an independent Mathematica consultant, and as such have a detailed familiarity with their Notebook mechanism. In my opinion Mathematica notebooks made Mathematica stand out - being able to work with algebra and calculus roughly as it would appear in a textbook   made the system far easier to use than other computer algebra systems. Mathematica notebooks also provide a way to store work in a form that is easy to run again and modify, as required.

Of course, Mathematica is extremely expensive, and every new version is bloated out with ever more functionality that hardly anyone needs. Recent versions of Mathematica are also licensed to individual computers, and it is necessary to contact Wolfram Research to move to another machine. I was therefore delighted to discover SymPy - completely free, and able to tackle most of the algebra and calculus problems that engineers and scientists require. I would imagine that almost everyone who buys Mathematica, uses it to solve problems that SymPy and its related packages can tackle for free!

Unfortunately I have found the Juypiter frontend extremely hard to work with. I am posting here, because I am proposing to provide an alternative to Juypiter notebooks that does not use a browser based interface, and works directly with the Win32 API in 64-bit mode. Since I am proposing to replace Juypiter specifically for SymPy, I thought it was probably best to post here, rather than in a Juypiter-related forum.

I am mostly retired now, so if I do this, it will be as a free contribution to the SymPy project. I already have a working basic prototype.

Although this proposal relates to the Windows platform, I can see no reason why it would not port to any 64-bit platform that can run Wine.

My prototype works directly with Python using the C-Python interface, so there are no problems with communicating processes, and obviously it is not necessary to have a CMD box running in the background to make it work!

In my experience, the fact that Mathematica's notebooks do run as a frontend/kernel combination, does lead to visible complications for users of the software. Glitches of various sorts are inevitable.

If anyone wants to know why I consider Juypiter unsatisfactory, I am happy to go into more detail.

Basically I want to know what you all think about this software, which I propose to call SymPyNotebook.

David

[Matthew Brett]

Hi,

I should say that I'm a Sympy lurker, but I'd love to hear more detail
about the problems you've had. I work a lot with notebooks for
teaching, and I'd be very grateful for some reflections on what works,
and what does not.

Cheers,

Matthew

[Aaron Meurer]

The kernel architecture of Jupyter has many advantages, such as
allowing multiple languages.

>
> If anyone wants to know why I consider Juypiter unsatisfactory, I am happy to go into more detail.

I am curious. I have heard many different complaints about the
notebook interface, and I have some of my own. But it sounds like your
issues are different than what I usually hear.

I would suggest looking a jupyterlab, the new frontend to the
notebook. It's much cleaner and more responsive than the plain
notebook interface.

>
> Basically I want to know what you all think about this software, which I propose to call SymPyNotebook.

I would suggest using a name other than notebook if it isn't using
Jupyter, to avoid confusion.

Aaron Meurer

>
> David
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c6f7168a-6e94-44cd-b4ac-7de45c03c6c6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alan Bromborsky]

What are the problems with Jupyter Notebook or Jupyther Lab other than
mathjax rendering being a bit slow?

[Aaron Meurer]

I'm curious if anyone has tried this KaTeX extension
https://github.com/jupyterlab/jupyter-renderers/tree/master/packages/katex-extension.
KaTeX renders much faster than MathJax. In the past there have been
some types of LaTeX that it didn't support, but perhaps those have all
been fixed by now.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5a57f773-c088-211e-3865-e6703665e35f%40gmail.com.

[Ondřej Čertík]

Hi David,

As other said, I would also be interested in hearing what you don't like about the Jupyter notebooks.

Thanks for working on a new notebook interface that you think is better. Do you have some screenshots?

Ondrej

[David Bailey]

Thanks everyone's rapid reply to my proposal!

On Wednesday, May 1, 2019 at 6:55:10 PM UTC+1, Aaron Meurer wrote:

On Wed, May 1, 2019 at 11:47 AM David Bailey <da...@dbailey.co.uk> wrote:
.

The kernel architecture of Jupyter has many advantages, such as
allowing multiple languages.

I am proposing that SymPyFrontend (a proposed alternative name to avoid confusion with Juypiter) will be dedicated to SymPy, so it's inability to handle other languages would not be a real issue. It  sends requests to Python/SymPy via C calls to PyRun_SimpleString.

I am curious. I have heard many different complaints about the
notebook interface, and I have some of my own. But it sounds like your
issues are different than what I usually hear.

I would suggest looking a jupyterlab, the new frontend to the
notebook. It's much cleaner and more responsive than the plain
notebook interface.

 

  OK - I will look at jupyterlab, but here was my list of objections (uncovered in a few hours of use) relating to the simple Juypiter notebook software. Some of these relate particularly to the classroom context:

 

 1)       Juypiter starts up with a list of files, most of which are irrelevant to the user. You have to realise that it is only the .ipynb that should be opened. A Windows program filters an open box to display files of the type required - .ipynb in this case. If you have a file such as foo.doc in Windows, the system knows which software to use to open it, so merely double clicking on that file in the file manager will start the word processor and cause it to open the file in question. Something similar happens with Mathematica .nb files, and it will be easy to achieve this effect with SymPyFrontend (or whatever it is ultimately called).

2)         Juypiter opens a CMD box to help it interface to the browser (I don't understand exactly why), and accidentally killing that box messes up the Juypiter session and loses any work.

3)         For obvious security reasons, all file I/O is restricted to one pre-specified folder plus its sub-folders. This restriction  seems inevitable for a browser based application. It is also not easy to locate where a notebook has been saved  for example the heading just says "http://localhost:8888/notebooks/MyNotebook.ipynb" - not (for example) c:\PythonSystem\Scripts\foo.ipynb I don't know if it would cause a security breach to print the actual path here - or maybe this is unavailable. 

I was also somewhat concerned about leaving Juypiter running unattended in case it could be hacked in some other way.

A standard Windows application need have no such restriction because it cannot read commands from the internet - thus it is possible to open or close any files on the machine to which user has read/write access.

4)         After using Jupyter for a while on an existing file I get "The notebook file has changed on disk since the last time we  opened or saved it. Do you want to overwrite the file on disk with the version open here, or load the  version on disk (reload the page)?"

 I knew I didn't want to reload the file (destroying my latest work) but neither did I want to write the half finished file back to the disk! I got this wrong on at least one occasion. The random nature of this interruption was particularly unsettling.

5)          By experimenting I discovered that In[5] or Out[5] return a string representation of the corresponding input or output - which I thought could be useful - but if an input produced no output - such as "from sympy import *" then typing Out[5] generates this error:

KeyError                                  Traceback (most recent call last)
<ipython-input-9-57d9ae6d5c76> in <module>

I could only figure out what this meant because I knew what I did wrong!

6)         I would imagine that beginners may confuse x, the Python variable with x, the SymPy symbol. It might help if SymPyFrontend were (optionally) to track the state of SymPy variables for the user, who could select the variables that should be symbolic or Pythonic using an explicit Windows interface.

7)        The Out[5] error message is, of course just one of a number of really hard to understand error messages. This is inevitable because Juypiter submits a request to SymPy, which then processes it with Python code, and something goes wrong. This error message prompted me to realise that a simple syntax scan of each line could be really valuable. For example any input in which (), [], or {} were not correctly paired off could generate a specific error message - indeed my prototype incorporates this feature. Hopefully it will also be possible to pick off many other common faults and provide a message that makes sense to the guy at the far end that just wants to do some maths!

8)        I noticed that SageMath maps ^ to ** reversibly (I think), and I was wondering about incorporating an option to do the same. To me using ** to mean exponentiation, harks back to the days of Fortran. I suppose it might be necessary to map ^^ to ^ to cater for anyone who wanted to use the Python * operator. Anyway such a feature would be optional. I used to work on the FTN95 Fortran compiler, and I think the diagnostics that this produces, shows what is possible.

9)       Since I have Latex on my machine, I had hoped that Juypiter might allow me to click something and convert any output I desired into the corresponding Latex formula which would sit in place in the notebook. I think this should be possible from within SymPyFrontend.

David

 

[David Bailey]

Please excuse two or three typos in the above - I discovered too late that posts cannot be edited here!

[Aaron Meurer]

On Wed, May 1, 2019 at 3:23 PM David Bailey <da...@dbailey.co.uk> wrote:
>
> Thanks everyone's rapid reply to my proposal!
>
>
> On Wednesday, May 1, 2019 at 6:55:10 PM UTC+1, Aaron Meurer wrote:
>>
>> On Wed, May 1, 2019 at 11:47 AM David Bailey <da...@dbailey.co.uk> wrote:
>> .
>>
>> The kernel architecture of Jupyter has many advantages, such as
>> allowing multiple languages.
>
>
> I am proposing that SymPyFrontend (a proposed alternative name to avoid confusion with Juypiter) will be dedicated to SymPy, so it's inability to handle other languages would not be a real issue. It sends requests to Python/SymPy via C calls to PyRun_SimpleString.
>>
>>
>>
>> I am curious. I have heard many different complaints about the
>> notebook interface, and I have some of my own. But it sounds like your
>> issues are different than what I usually hear.
>>
>> I would suggest looking a jupyterlab, the new frontend to the
>> notebook. It's much cleaner and more responsive than the plain
>> notebook interface.
>
>
> OK - I will look at jupyterlab, but here was my list of objections (uncovered in a few hours of use) relating to the simple Juypiter notebook software. Some of these relate particularly to the classroom context:
>
> 1) Juypiter starts up with a list of files, most of which are irrelevant to the user. You have to realise that it is only the .ipynb that should be opened. A Windows program filters an open box to display files of the type required - .ipynb in this case. If you have a file such as foo.doc in Windows, the system knows which software to use to open it, so merely double clicking on that file in the file manager will start the word processor and cause it to open the file in question. Something similar happens with Mathematica .nb files, and it will be easy to achieve this effect with SymPyFrontend (or whatever it is ultimately called).

Jupyter lab (and to some degree the old notebook interface) can be
used as a full IDE. It has a text editor and extensions can be made to
open other types of files. So it makes sense to show every file, not
just notebooks. This interface may also come more from a Unix/Mac
background where typically file viewers show all files by default.

>
> 2) Juypiter opens a CMD box to help it interface to the browser (I don't understand exactly why), and accidentally killing that box messes up the Juypiter session and loses any work.
>
> 3) For obvious security reasons, all file I/O is restricted to one pre-specified folder plus its sub-folders. This restriction seems inevitable for a browser based application. It is also not easy to locate where a notebook has been saved for example the heading just says "http://localhost:8888/notebooks/MyNotebook.ipynb" - not (for example) c:\PythonSystem\Scripts\foo.ipynb I don't know if it would cause a security breach to print the actual path here - or maybe this is unavailable.
>
> I was also somewhat concerned about leaving Juypiter running unattended in case it could be hacked in some other way.
>
> A standard Windows application need have no such restriction because it cannot read commands from the internet - thus it is possible to open or close any files on the machine to which user has read/write access.

I believe there are people who have built more native-like versions of
the notebook. I'm not sure what they are or how well they work,
especially for Windows. For example, nteract.

>
> 4) After using Jupyter for a while on an existing file I get "The notebook file has changed on disk since the last time we opened or saved it. Do you want to overwrite the file on disk with the version open here, or load the version on disk (reload the page)?"
>
> I knew I didn't want to reload the file (destroying my latest work) but neither did I want to write the half finished file back to the disk! I got this wrong on at least one occasion. The random nature of this interruption was particularly unsettling.
>
> 5) By experimenting I discovered that In[5] or Out[5] return a string representation of the corresponding input or output - which I thought could be useful - but if an input produced no output - such as "from sympy import *" then typing Out[5] generates this error:
> KeyError Traceback (most recent call last)
> <ipython-input-9-57d9ae6d5c76> in <module>
>
> I could only figure out what this meant because I knew what I did wrong!

This sounds like a bug. What is the full text from the traceback?
Cells should not error when you enter code that isn't evaluable as an
expression.

>
> 6) I would imagine that beginners may confuse x, the Python variable with x, the SymPy symbol. It might help if SymPyFrontend were (optionally) to track the state of SymPy variables for the user, who could select the variables that should be symbolic or Pythonic using an explicit Windows interface.

This sounds useful. Although I believe something like this should not
be difficult to achieve with a Jupyterlab extension.

>
> 7) The Out[5] error message is, of course just one of a number of really hard to understand error messages. This is inevitable because Juypiter submits a request to SymPy, which then processes it with Python code, and something goes wrong. This error message prompted me to realise that a simple syntax scan of each line could be really valuable. For example any input in which (), [], or {} were not correctly paired off could generate a specific error message - indeed my prototype incorporates this feature. Hopefully it will also be possible to pick off many other common faults and provide a message that makes sense to the guy at the far end that just wants to do some maths!

I agree Jupyter could be a bit more interactive with syntax errors,
for instance, moving the cursor to the point in the input where the
error is, instead of just printing the syntax error message.

>
> 8) I noticed that SageMath maps ^ to ** reversibly (I think), and I was wondering about incorporating an option to do the same. To me using ** to mean exponentiation, harks back to the days of Fortran. I suppose it might be necessary to map ^^ to ^ to cater for anyone who wanted to use the Python * operator. Anyway such a feature would be optional. I used to work on the FTN95 Fortran compiler, and I think the diagnostics that this produces, shows what is possible.

SymPy's init_printing() has some flags to make interactive usage more
pleasing, such as automatic wrapping of integer literals with
sympy.Integer and automatic defining of undefined variables as
Symbols. We don't have any options to flip ^ but it could be added.
However, our general philosophy with SymPy is that people are better
off learning Python syntax, rather than a fake Python syntax that will
mislead them when they use a real Python.

>
> 9) Since I have Latex on my machine, I had hoped that Juypiter might allow me to click something and convert any output I desired into the corresponding Latex formula which would sit in place in the notebook. I think this should be possible from within SymPyFrontend.

I believe you can get the LaTeX from a MathJax rendering by right
clicking on it. Or you can use the SymPy latex() function to get the
latex formula from an expression.

Having LaTeX itself installed is irrelevant to this. However, I'll
note that you can use it with init_printing(use_latex='png'), which
makes the outputs use LaTeX instead of MathJax.

Aaron Meurer

>
> David
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/63e9cddc-47b7-4e5e-a7cf-ffd29674edc3%40googlegroups.com.

[Alan Bromborsky]

To use jupyterlab in Ubuntu 18.04 I defined a desktop launcher with the following properties -

Name: Jupyter Lab

Description: Jupyter Lab

Command: /home/brombo/.local/bin/jupyter-lab

Comment: Execute python in jupyter lab

With launcher icon:

If I drag a ipynb file over the icon on the desktop jupyterlab is started in google-chrome and the ipynb file is displayed ready to run.

[David Bailey]

As requested, here is a screen shot of SymPyFrontend (still with its old name!).

There isn't too much to see here, but note that SymPyFrontend imports the contents of SymPy and sets up symbols with names a - z and A to Z (excluding E and I).

Thus a user can start work immediately. Notice the deliberate error, which is diagnosed explicitly by SymPyFrontend.

The menu is pretty minimal at this time.

[David Bailey]

After more thought, I propose to call my software SymPyWorkbook because SymPyFrontend might be a bit vague for some people. I am definitely not a fan of weird names like 'Jupyter' - they are hard to spell, and I actually wasted some time when I first tried SymPy, looking for the notebook, because nothing looked a likely candidate!

Since I have reached the stage of sharing screen shots, I'd quite like to give my software a proper icon. Obviously I'd like to use the usual SymPy image. Would there be any problem (legal or otherwise) about doing this?

Do you have a .ICO icon file available?

[Vishesh Mangla]

Why don’t you say it PyMath and let other thinks like scipy and numfocus also use that?

 

Sent from Mail for Windows 10

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d2d2d56e-d14c-4a4e-a823-b913c025ef5e%40googlegroups.com.

[Kasper Peeters]

Hi David,

I tend to agree with most of your criticism of Jupyter. What do you intend to use in order to render mathematics? In the notebook system for Cadabra (https://cadabra.science) I went the route of feeding things through LaTeX & dvipng and then render the resulting png, which can be made to perform quite well (definitely faster than mathjax). You may want to give the Cadabra notebook a try (you can use it just do do sympy computations as well), if only to see where you agree/differ on what such a thing should look like. Am happy to collaborate too if you think there is sufficient material that you would otherwise have to re-implement.

Cheers,

Kasper

[Kasper Peeters]

Just for comparison: this is part of David's example in Cadabra:

[David Bailey]

Vishesh,

I certainly don't want to obscure the sense that this is SimPy - after all, many people here must have contributed some very sophisticated algorithms to this project - I just want to help reveal what they have done by clearing away some of the clutter that probably impedes poential users.

Kasper,

Thanks for the offer of collaboration - would you like to contact me at dave at dbailey dot co dot uk?

My intention is to provide something on each cell (probably a right-click menu item) to use Latex. FTN95 is still being sold and developed, and we recently added the ability to use Latex to convert TeX files via a series of steps into SVG format, that can then be used to annotate graphs etc. The value of SVG for this project, is that it is textual, and can be saved as part of the workbook (which is  itself textual). I should say at this point, that I use my own format for the workbook files - because that gives me far more freedom to add features - but if I can get a spec of Jupyter's output format, I'd certainly consider providing a means to import them into SymPyWorkbook when the project has matured a bit.

Does Cadabra use SymPy and Jupyter right now?

One advantage of the more basic style of output is that it can be copied/pasted and modified. Obviously this is not possible with Latex output - on area where Mathematica still has an edge!

BTW Please note that the above image still contains a glitch - long expressions are not being properly sized into the cell, and some information is lost as a result.

[Vishesh Mangla]

Sorry, if my tone was a little rough. I just wanted to suggest.

Sent from Mail for Windows 10

 

From: David Bailey
Sent: 02 May 2019 19:15
To: sympy
Subject: [sympy] Re: SymPy - a suggestion

 

Vishesh,

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/87716e06-5483-4d30-9778-ab1ff12b4852%40googlegroups.com.

[David Bailey]

Vinesh,

Not in the slightest - it is just that I would hate to mane the program something that might hide the fact that it is SymPy that is doing the calculations!

[Vishesh Mangla]

Actually I feel that sympy ‘ s algos should be available for SciPy too cause I require to solve a bunch of differential equations but I can’t use SciPy goodies in sympy. Therefore I have to think and resort to other methods. I wish both libraries could like use one another’s features and your notebook could be some kind of a string to bind them.

 

Sent from Mail for Windows 10

 

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/fd6dfbba-391a-4a0b-a9c4-c22dbd6c9bfb%40googlegroups.com.

[Alan Bromborsky]

I did the same thing, except the output is in pdf, for sympy/galgebra in pure python.  Both the function and the output are sent to LaTeX, compiled and rendered as a pdf file.  This is especially easy in python 3 since print is a function that can be overloaded.  I have attached an example.  The function "Print_Function()" in the python code causes the text of the code to be included in the .tex file verbatim.

On 5/2/19 7:04 AM, Kasper Peeters wrote:

Just for comparison: this is part of David's example in Cadabra:

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/0e1fbaa2-587f-4cbc-b9e0-25bb981a13d1%40googlegroups.com.

[Kasper Peeters]

I should say at this point, that I use my own format for the workbook files - because that gives me far more freedom to add features - but if I can get a spec of Jupyter's output format

Those specs are all on the Jupyter site. Cadabra uses a very similar format (and in fact also has a Jupyter kernel in case people want to use the program itself through a Jupyter interface).

Cadabra's own notebook interface is a native program, built using gtkmm, and builds/runs on Linux, macOS and Windows. So it does not run in a browser.

I will ping you off-line to preserve bandwidth here, but for anyone else interested, I have opened an issue about separating out Cadabra's notebook interface at

https://github.com/kpeeters/cadabra2/issues/145 for further discussion.

[S.Y. Lee]

It would be a good idea about making a new frontend for our project.

However, I think that if we make our own frontend from the scratch, we should either have to prove that we have features more efficient, or more unique from the Jupyter notebook, to make a standpoint.

For things that can stand apart from the Jupyter, I think it can be things like formula editor,

or some capability like accepting inputs more than plain texts, like images or typesetted math notations, like in Mathematica.

Mathematica also have implemented iconization in 12.

I just wonder if you have the same roadmap, if you had been a long user of Mathematica.

[Alan Bromborsky]

Remember that one of the most appealing aspects of sympy is that it uses a general purpose programming language, python, unlike other computer algebra systems.  I would not use a special syntax outside of standard python.

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/5e39ed65-f187-4bb2-81b1-747dadc0239f%40googlegroups.com.

[David Bailey]

I think my primary reason for proposing a new frontend, is that I'd like to see SymPy algebra/calculus reach more people - people whose need for computer algebra is real, but not overwhelming, or children who are learning calculus for fun, years before it was taught in school (as I did). As a consultant, I was contacted by more than one PhD student, who was fluent in his subject, and needed computer algebra, but with only a limited grasp of computers.

I didn't come to SymPy looking for a reason to write a frontend, I came because I was interested to discover how effective SymPy is compared with Mathematica.

There is lots of simple but useful free software available now - for example the post-it note program, Stickies or the clipboard storage system, Ditto. These seem to have been built by one person, and yet even they have a custom GUI, and often work on more than one platform. By contrast, SymPy is obviously a massive effort with many contributors, and yet rather than having a dedicated GUI interface, it runs via a web browser with a CMD program connected in some way. The would-be computer algebra enthusiast has to find the weirdly named Jupyter program, start it up, and then know to click Python 3, and then click 'New' in order to get to a window into which he has to import SymPy and its symbols before he can begin to type in algebra. When he comes to save his work, he again has problems, because most of his computer is inaccessible for understandable security reasons.

People who really NEED computer algebra will learn to do all that, but I am pretty sure you will lose a lot of others on the way. I think that is a shame, and that free algebra software should also be easy and friendly to use.

Indeed Kasper Peeters has already decided to create some type of stand alone frontend - part of Cadabra - that I am eager to try, but it seems to have some teething troubles right now.

I'd imagine that many - maybe most potential users of SymPy would like to simply execute algebraic commands - they don't really want to use Python explicitly unless and until they become more serious about using SymPy. I propose that my frontend will accept all the input that Jupyter will accept, but it will start connected to Python 3, with SymPy imported together with all its symbols. I also suggest that a pre-scan can pick up a variety of elementary (but common) faults, and give clean errors - unpaired quotes and missing brackets would be obvious examples. By default, this scan would also spot single character identifiers and set them up on the fly as SymPy symbols. This would mean that all the variables most used in algebra - single letters and Greek letters - would be immediately usable. More advanced users who wanted to incorporate Python code, would probably be advised to turn this feature off. I think it would also be possible to distinguish between variable names and function names and set them up appropriately.

I think producing quality error messages for other kinds of fault is also important. Everyone makes errors, and beginners make more than most - is they don't make sense, they soon give up.

I'd also like to apply some syntactic sugar in places. For example, the ability to expand expressions such as f(x**2) in powers of x is fine, but the complex notation for f`(0) and higher derivatives, makes this very hard to use.

Also, now is the age of UTF8, and clearly the frontend should at some point provide easy access to all the symbols relevant to maths. These need to be easy to input on a normal keyboard, and Mathematica provides several ways to do this, including typing things like <esc>inf<esc> to obtain an infinity symbol. The replacement is made immediately. Something along these lines could make SymPy even more attractive.

S.Y.Lee suggests creating a formula editor. By this, I think he means an editor that could operate directly on a 2-D mathematical expression - say to change the limits on an integral. In practice with Mathematica, I found this rather fiddly, and I usually suggested converting an expression to ImputForm, changing it, and then changing the result back again.

I guess this is my provisional roadmap (it wouldn't all happen at once), depending on what everyone thinks and how Cadabra works - I don't want to re-invent the wheel.

David

[Aaron Meurer]

You may also be interested in SymPy Live (https://live.sympy.org) and
SymPy Gamma (http://gamma.sympy.org/).

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/3285f96d-b1d2-75fb-4837-75460bf0c315%40dbailey.co.uk.

[Matthew Brett]

Hi,

Also - I think https://www.sagemath.org has a similar purpose,
including a custom notebook for symbolic mathematics, that uses Sympy
among other engines.

Cheers,

Matthew

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BpBBnUB3DgrEKxB%3DEG3cgGv7UhjD0d319kzT0s4w6%3Dgw%40mail.gmail.com.