Grim expressions

[Fredrik Johansson]

Hi all,

First off, congratulations to the SymPy community for version 1.5!

I'm interested in feedback about the symbolic formula language I'm developing for Fungrim (http://fungrim.org/).

I have a draft writeup about the language (now named Grim) here: http://fungrim.org/grim/

It's still very much a work in progress and many aspects of the design could certainly be changed. A central constraint is that I'm trying to have constructs that work reasonably well both for representing symbolic expressions and for representing natural mathematical notation (sometimes these goals clash with each other).

Here is a minimal start of a SymPy-Grim interface: https://github.com/fredrik-johansson/fungrim/blob/master/pygrim/sympy_interface.py

Fredrik

[Aaron Meurer]

This looks nice. Some basic comments:

- Since you mention that Grim should be parsable by languages other
than Python, I would suggest specifying a formal grammar for it. If
you want to keep that grammar as a strict subset of Python's grammar,
including semantics around operator precedence, I think that's a good
idea.

- It seems like you only allow symbol names to be ASCII characters. I
think that's fine, since LaTeX does the same, although there are
certainly people who will want to write something like π instead of
pi. But a question that comes up is how to represent arbitrary
formatting for certain symbols. Does that have to be represented in
the printer somehow, or can it be put on the symbol name. And if the
former, how is that stored in the expression? Does it mean that any
symbol with custom printing has to be represented as a custom function
(non-atom, I guess you call it). For example, sometimes people will
use something like Symbol('x^0_1') or Symbol(r'\mathbf{x}') in SymPy
which prints as such. Another option is to explicitly disallow such
things by requiring them to be part of the semantics. So for instance,
a if you want to have a vector that prints in bold face you have to
represent it as a vector, like Vector(x) or something like that.

I know you state that Grim is not a typesetting system, and that's a
good thing to state. But in my experience people will want to use it
as one nonetheless.

- If I understand it correctly, Grim doesn't do any sort of semantic
type checking, allowing you to create formulas that are completely
nonsense. If that is not the case, I think you will need to add a type
system, which complicates things quite a bit (you'll probably want to
look to formal proof systems for inspiration).

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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/c608241b-0f34-44ea-a616-64de84c063a1%40googlegroups.com.

[Fredrik Johansson]

Thanks for the input!

> - Since you mention that Grim should be parsable by languages other
> than Python, I would suggest specifying a formal grammar for it. If
> you want to keep that grammar as a strict subset of Python's grammar,
> including semantics around operator precedence, I think that's a good
> idea.

Yes, that might be worth doing. For operator overloading, it might look
different in different host languages though (e.g. ** vs ^ for powering).

> - It seems like you only allow symbol names to be ASCII characters. I
> think that's fine, since LaTeX does the same, although there are
> certainly people who will want to write something like π instead of
> pi. But a question that comes up is how to represent arbitrary
> formatting for certain symbols. Does that have to be represented in
> the printer somehow, or can it be put on the symbol name. And if the
> former, how is that stored in the expression? Does it mean that any
> symbol with custom printing has to be represented as a custom function
> (non-atom, I guess you call it). For example, sometimes people will
> use something like Symbol('x^0_1') or Symbol(r'\mathbf{x}') in SymPy
> which prints as such. Another option is to explicitly disallow such
> things by requiring them to be part of the semantics. So for instance,
> a if you want to have a vector that prints in bold face you have to
> represent it as a vector, like Vector(x) or something like that.

Definitely. I have considered several ways of doing that:

* Recognizing LaTeX (or LaTeX-like) strings in symbol names
* Allowing arbitrary non-atom expressions to be used as symbols, say
  Symbol(Subscript(x, 0))
* Allowing the user to override the LaTeX output for individual symbols
  in the pygrim latex() method (so you can use the symbol x but have it
  printed as \mathbf{x}, with something like .latex(custom_printing={x:r'\mathbf{x}'}).
* Allowing the user to override the LaTeX output using special expressions
  within a formula; something like
  WithCustomPrinting(Equal(3*x, y), Tuple(x, r'\mathbf{x}'), Tuple(y, r'\mathbf{y}')).

In fact, it would probably make sense to allow all of these approaches.
Implementing all them is not difficult, and different ways would be useful in
different circumstances.

> - If I understand it correctly, Grim doesn't do any sort of semantic
> type checking, allowing you to create formulas that are completely
> nonsense. If that is not the case, I think you will need to add a type
> system, which complicates things quite a bit (you'll probably want to
> look to formal proof systems for inspiration).

Correct. I think I will write some kind of basic type checker sooner or later.
Since types can depend on values, checking types fully is as hard as formal theorem
proving, but you should be able to do some simple type inference to catch
obvious mistakes that result from transposing function arguments,
using the wrong symbol names, and such.

Fredrik

You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/O6TeAa3IHnA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2B42eOw7ayQ%3DP-s%3DjCsmmnEokSCawUw8fkrDea6ZX4pfQ%40mail.gmail.com.

[Ondřej Čertík]

Hi Fredrik,

Thanks for documenting the new language Grim. I think you are onto something and while many of the goals of SymPy and Grim are similar, there are important differences that mandate a separate language.

Here is a relevant discussion:

https://twitter.com/hypergeometer/status/1206552744460509184

and my latest opinion why we should consider using Grim for our docstrings:

https://github.com/sympy/sympy/issues/14964#issuecomment-566282722

Ondrej

[Ondřej Čertík]

I also started documenting the pros and cons of Grim and SymPy as a language here:

https://github.com/fredrik-johansson/fungrim/issues/24

Ondrej