Step-by-Step mathematics in SymPy

[S.Y. Lee]

There are some of step-by-step solvers out in the market

- Qanda
- Photomath
- Wolfram Alpha Pro
- Microsoft Math
- Integral Calculator

I'd question if they can better be developed, or fund-raised by an open source community that practices symbolic computation 'professionally'. For example, we can launch a library, end user software or mobile app for them because there are some 'free apps' but there could be literally no apps from open source, and in good quality that passed some academic review.

An abstraction of 'rule-based' or 'step by step' solver should be abstract rewriting system by the nature of reflexivity and transitivity of relation generated by problem solving steps, and if such step by step solver is also aware of congruence, they nonetheless can be characterized as term rewriting system.

So to summarize, I find that term rewriting system is the step-by-step mathematics as well as the mathematics for the step-by-step that should be studied for. And the only thing that makes sympy deviant from pure term rewriting system is its automatic evaluation.
For example, sympy has automatic evaluation capability, from flattening the parenthesis and doing arithmetic of integers, to complicated functional identities.
However, the only problem is that such automatic evaluation is 'irreversible' if they are done in python operational semantics, however, if we just begin new project with uniform treatment of terms and rewriting, and have deliberate control of evaluation and side effects, they are not difficult to implement.
Those step-by-step solutions listed above, try to respect baby steps of adding integers to solving polynomial equations, and try to earn some money by presenting them to students. 

Ultimately, we could assert that our system is complete (Noetherian and Church-Rosser) system in problem solving in elementary algebra and calculus, to have some advantage over the other projects listed above.
And could also benefit the community to have better insight for developing calculus of expand, simplify, or RUBI project we already had.

There are also some deep results of term rewriting systems that can be implemented as a library, focused purely uniform treatment of its syntactical nature.
For example, Equational Unification or Knuth-Bendix completion can be developed, which can bring some machine learning capability for general rule-based systems.

I believe that my prompt can already address and solve the problem below, and beyond the fact that the calculus is merely Turing-complete
(such that we can develop a library to be closed against anti-pattern practices by developers for stability),
it also provides pretty much well-studied and uniform representation for the application, without introducing some deviated object by some nerds and having poorly defined calculus over it.

- Abstract algebra
- Decimal object
- Algebra with SymPy
- ...

I also believe that this is also an elaboration of ghosted attempts like sympy/unify or sympy/strategies, and can be seen as completing those ideas as well. I'd like to receive some questions from the community if there are some critical views about this idea, or need some elaboration, or too difficult to understand, or so on.

[gu...@uwosh.edu]

S.Y.,

The only part of what you are proposing that I believe I understand is that you suggest sympy should avoid automatic evaluation/simplification/collapse of expressions. The specific example I can think of where this would often be useful is with differentiation (the default behavior of Derivative() does this, but not the convenience implementation diff()). I have certainly had to be careful while trying to define a partial derivative operation that works the way we usually use it in the physical sciences (for thermodynamics in particular). Can you illustrate how your proposal would provide a clean and mathematically sound way of defining things such as a total differential (e.g. df = (df/dx)_y dx + (df/dy)_x dy) and the derivative relationships they imply? Would this ease the handling of the circularity of functional dependence implied by the Euler circular chain rule used to figure out what combinations of measurable quantities (partial derivatives) will provide values for partial derivatives that cannot be measured directly?

I appreciate your interest in helping to improve the open source mathematical offerings. Can you provide a baby implementation that does not impinge on the intellectual property of your employer (Qanda) for us to consider?

A word to the wise: I know you are not a native English speaker. However, I think you need to be more careful about broad statements such as the one below.

On Wednesday, December 28, 2022 at 1:35:17 PM UTC-6 syle...@gmail.com wrote:

I believe that my prompt can already address and solve the problem below, and beyond the fact that the calculus is merely Turing-complete
(such that we can develop a library to be closed against anti-pattern practices by developers for stability),
it also provides pretty much well-studied and uniform representation for the application, without introducing some deviated object by some nerds and having poorly defined calculus over it.

- Abstract algebra
- Decimal object
- Algebra with SymPy
- ...

 I, like you, am not a mathematician by training. Your training is in engineering mine is in physics/chemistry. I do not claim to be cognizant of all details necessary to generate completely general representations of many mathematical operations. Thus, I am always happy to get issues with my understanding corrected. However, I have been working with and teaching about the multidimensional partial differential equations of quantum mechanics and thermodynamics for longer than you've been alive. They are very specific applications of calculus over a well specified domain. Please do not belittle things that allow physical scientists such as myself to work effectively in that domain. I suggest in the future you provide specific examples of where these tools do not work and then we can address those specific issues. It may be that a more general implementation that can then be used to easily provide the same behavior is possible, but we need specific examples.

Regards,

Jonathan

[S.Y. Lee]

I think that software engineers should be satisfied for solving 'easy' and 'decidable' problems for derivative, like formal deriviative,
which is sometimes a sound reasoning for the actual physical/analytical derivative, however, not always.
and even if you attempt to relate more physical implementation just by 'software engineering',
I'd only warn that it would not be merely more than some 'heuristics', 
and such 'heuristics' are just going to define less uniform and awkward formal grammar about the inputs the software it accepts,
rather than making it more deeply connected with the physics.

Similar as how you'd usually perceive that numeric analysis need hypothesis about approximating the physical world problem by numeric errors,
I also believe that any symbolic computation need hypothesis that it just approximates the the physical/business world problem as syntactical way.
And to develop the useful and stable library, the only thing to concern is that we get at least the syntactical part correctly.

[S.Y. Lee]

And at least the term-algebraic definition of computing total derivative, is not evaluating dy/dx -> 0. In that sense,
if the chain rule is implemented faithfully, dy/dx itself becomes normal form, such that no further computation is done for it.
And the triple product rule for derivative is implemented as something like viewing derivative as fraction, which may not be very mathematically sound reasoning,
but for practices in term rewriting, we try to detach the semantics and try to solve problems only by syntax, which also gives a plausible reasoning how to combine problem solving skills, and even more abstract or deeper view of it.

[S.Y. Lee]

> I, like you, am not a mathematician by training. Your training is in engineering mine is in physics/chemistry. I do not claim to be cognizant of all details necessary to generate completely general representations of many mathematical operations.

If I have to apologize, I should be.
I would not want to see this thread contaminated by arguments by university major, job experience, ...
and which makes the conversation toxic and look like a fallacy overall.

[gu...@uwosh.edu]

I agree that we should avoid arguments unrelated to the question at hand.

For the part of this proposal that I think I understand (avoiding evaluation/simplification unless requested), does this imply you want the user to deal with collapsing expressions to avoid them becoming too large?

Jonathan

[S.Y. Lee]

I think that simplify or evaluation should rather be decomposed in many components
such that 'simplify' is not a silver bullet solution,
but users can mix in some components of 'simplify' to solve math problems in the very precise way what they want to.
I still need some time to write out full proposal about this because I'm studying some part of it to fill in the gaps.

[Sam Brockie]

If you've not come across e-graphs and egg then you may find this interesting reading: https://egraphs-good.github.io

They allow the application of rewrite rules (until saturation) but the nature of the data structure also helps to ensure that the data structure representing the expression does not grow exponentially in certain situations.

[gu...@uwosh.edu]

On Monday, January 2, 2023 at 6:33:38 AM UTC-6 syle...@gmail.com wrote:

I think that simplify or evaluation should rather be decomposed in many components

To a great extent I think sympy already does this through the specialized simplification options such as `radsimp()`. However, I do think it is hard to figure out which options are available unless you are using an interface with tab completion of `obj.` and are comfortable using tab completion combined with reading the API. I personally think that the overall `.simplify()` option should not disappear, but possibly the precise tools should be extended and some thought should go into making them easy to discover.

[Oscar Benjamin]

No one is suggesting that the simplify function should be removed.
Rather it should be easier to control evaluation and simplification
for those who want to. The problem with SymPy right now is that
automatic "evaluation" (really automatic simplification) prevents
expressions from having certain forms e.g.:

>>> print(1/sqrt(2))
sqrt(2)/2

Here I might want the expression to stay as 1/sqrt(2) rather than
evaluate to sqrt(2)/2 but it's difficult to make that happen. You can
use evaluate=False but then you need to keep using evaluate=False all
the time and not all operations even accept evaluate=False.

All of automatic evaluation, doit and simplify suffer from the basic
premise that there is only one way that an expression should be. For
example doit presumes that there is only one thing that should be done
when there are many possible things that you might want to do in
transforming an expression from one form to another. Of course with
doit and simplify you have the option not to call those functions but
in the case of automatic evaluation you don't really have that option
in SymPy as it stands. The evaluate(False) context manager breaks most
things and the evaluate=False keyword argument is tedious and not
universally usable.

What is needed is a system that at least at the lowest level does not
have automatic evaluation. It is possible to build any kind of
evaluation on top of that at a higher level but the converse is not
true.

--
Oscar