There are a lot of similarities between the languages Grim and SymPy. As such, it can be confusing why one would like to choose one over another, for example to write expressions in SymPy docstrings (https://github.com/sympy/sympy/issues/14964). Let's use this issue to figure out the design and other differences between Grim and SymPy and then document it somewhere to make such decisions easier.
Common design goals:
Open source
Easy to write / read
Easy to parse
Symbolic
Syntax based on Python
Goals of SymPy that Grim does not have:
Strict about semantic correctness (you will get an exception if you write something that does not make sense)
Use canonical form (x+x -> 2*x; also a+b is semantically indistinguishable to b+a) to simplify and speedup internal representation. This is particularly true for SymEngine, where it is essential to deliver performance.
Primarily designed for manipulating symbolic math and working with math on a computer, and only secondary to represent arbitrary math to look like on a paper
Goals of Grim that SymPy does not have:
Not strict about semantic correctness
Not use canonical form (by default assumes unevaluated expressions like x+x or 1+2; also a+b is different to b+a)
Primarily designed to look good and be closer to what you write by hand on a paper, and thus less semantically strict, but with features to represent 99% of math that you actually write accurately. Only secondary to allow manipulating symbolic math and working with math on a computer.
As such, I would say that each step in the following represents more semantic control and simpler/easier/faster to represent and more robustly manipulate in the computer and less control over how things end up looking:
Handwritten math formula
LaTeX
Grim
SymPy
I would say that Grim fits the goal of giving up just a little bit of control over how things look like in LaTeX, but gaining SymPy like syntax and representation. So Grim is a much better fit if we have text in LaTeX and we want it to look pretty much the same, but we want to gain semantic representation, understanding and SymPy like syntax. But unlike SymPy, Grim is better designed to make the generated LaTeX look good and easy to write.
There are a lot of similarities between the languages Grim and SymPy. As such, it can be confusing why one would like to choose one over another, for example to write expressions in SymPy docstrings (https://github.com/sympy/sympy/issues/14964). Let's use this issue to figure out the design and other differences between Grim and SymPy and then document it somewhere to make such decisions easier.
Common design goals:
Goals of SymPy that Grim does not have:
x+x -> 2*x; alsoa+bis semantically indistinguishable tob+a) to simplify and speedup internal representation. This is particularly true for SymEngine, where it is essential to deliver performance.Goals of Grim that SymPy does not have:
x+xor1+2; alsoa+bis different tob+a)As such, I would say that each step in the following represents more semantic control and simpler/easier/faster to represent and more robustly manipulate in the computer and less control over how things end up looking:
I would say that Grim fits the goal of giving up just a little bit of control over how things look like in LaTeX, but gaining SymPy like syntax and representation. So Grim is a much better fit if we have text in LaTeX and we want it to look pretty much the same, but we want to gain semantic representation, understanding and SymPy like syntax. But unlike SymPy, Grim is better designed to make the generated LaTeX look good and easy to write.