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
On Mon, Dec 16, 2019 at 9:14 PM Aaron Meurer <asmeu...@gmail.com> wrote:
> 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
>
> On Mon, Dec 16, 2019 at 12:00 PM Fredrik Johansson
> <fredrik.johans...@gmail.com> wrote:
> >
> > 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
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c608241b-0f34-44ea-a616-64de84c063a1%40googlegroups.com
> .
>
> --
> 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+unsubscr...@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
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAJdUXTL6v29W-%2BhAWbR_iuysjbOp%3D%3D8t2yV_CFF8djggX-JzPQ%40mail.gmail.com.
