notes from reading "A Step-by-Step Solution Methodology for Mathematical Expressions"

A Step-by-Step Solution Methodology for Mathematical Expressions
by Sahereh Hosseinpour, Mir Mohammad Reza Alavi Milani and Hüseyin Pehlivan
Symmetry 2018, 10(7), 285; https://doi.org/10.3390/sym10070285
https://www.mdpi.com/2073-8994/10/7/285/htm


The following sites parse input, take a specified action, and show the steps
(I'm not sure whether these two sites are related or clones of each other)
https://www.softmath.com/math-com-calculator/quadratic-equations/myalgebra.com.html
https://www.mathsite.org/maths-factors/perpendicular-lines/myalgebra.com.html
Also see https://www.mathway.com/Algebra and http://www.webmath.com/

I find it fascinating to read about someone else having an idea similar to mine:
"Our methodology uses a grammar-based approach to convert mathematical expressions into abstract syntax trees (AST) on which new methods can be developed for different evaluation or interpretation requirements. In this way, users can dynamically enter expressions and all the intermediate operations on them can successfully be achieved through AST nodes." ... "It can also be a good platform for the development of educational products in the field of mathematics, which can display all problem-solving steps."

I'm not clear on the distinctions of the three approaches to solvers, but it's helpful to know there's more than one approach

• computer algebra system
• rule based: "Starting with a mathematical expression, this approach transforms it into another equivalent expression and compares it with the intended target expression for equivalence verification."
• structural approach: "two mathematical expressions are first represented as two mathematical expression trees. Then, tree matching algorithm is used to compare the two trees using dynamic programming for equivalence verification.

Section 2.3 walks through the entire process of getting from BNF to an AST. 

avoiding the need for logins in the Physics Derivation Graph website

Now that the PDG interface is a webpage, and users (not just developers) are the audience, there is a question of whether users of the website need accounts.

User accounts

Having an account would enable persistence of data specific to one user.
Downsides:

• Password management and security
• user account shenanigans
• 
  

No users accounts

Live use without an account, modeled after services like https://repl.it/  and https://www.onlinecharttool.com/graph, enable users to explore the capabilities without need for registering and creating a password.

Data could be uploaded and download

Source code

Historically the Physics Derivation Graph was developed on the command line using bash and Python. This implied a single user.
The source code was available, so other developers could pull a local copy to make edits.

API calls

This would allow interfaces to be developed that are independent of the backend.

why I'm excited about the Physics Derivation Graph

A few months ago I realized that rather than try to figure out what the best storage format was (MathML, Latex, Sympy, etc) and what database should store that representation (CSV, SQL, XML, etc), the "easy" solution was to simply store strings in dictionaries as a Python Pickle. No translation needed -- simply save the internal representation to disk and read it in as a Python variable.

Then I had an insight about how the front-end was supposed to work using the Model-View-Controller (MVC) approach. Now I felt comfortable about both the back-end and front-end aspects of the PDG! I had a backlog of features which were now easy and intuitive to implement. However, that didn't result in the excitement and motivation I now feel.

In the process of reviewing my hand-written notes from graduate school, I realized I now have actual hope of converting the notes to an electronic format. My reinvigorated interest in implementing the Physics Derivation graph is because I now have the relevant aspects figured out and see a well-defined end point.

That shifted my view of what I should be working on in the PDG code. Rather than working on arbitrary features, I am now focused on addressing aspects that are blocking me from converting my paper notes into PDG content. 

surveys of knowledge graphs and historical evolution

The Physics Derivation Graph is a domain specific knowledge graph


https://www.linkedin.com/pulse/knowledge-graphs-end-user-products-from-cyc-ai-part-daniel-kornev/

https://arxiv.org/abs/2003.02320
https://news.ycombinator.com/item?id=22504133

http://knowledgegraph.today/paper.html

Tools for project maintenance

For documenting the code base:
https://github.com/sphinx-doc/sphinx

code formatting
https://github.com/psf/black

Autodetect basic issues
https://github.com/PyCQA/prospector

autopep8
https://github.com/hhatto/autopep8

Refactoring
https://github.com/PyCQA/redbaron

ASTs for Integrals

I've understood ASTs for simple expressions that only involve binary operators. I don't understand how ASTs deal with operators that have more than two arguments.
https://reference.wolfram.com/language/ref/TreeForm.html

https://demonstrations.wolfram.com/ExpressionTreesForIntegrals/

Integration path for contributions

So far I've been hesitant on collaborations involving software in the Physics Derivation Graph. I didn't have a good path for integration of contributions, especially of complex features. I think I can provide both more details explanation of what would be helpful, as well as a clear integration path.

For example, in this post I provided a set of valid and invalid and ambiguous Latex examples. I did not provide details on how I would integrate a suggested solution written by a contributor.

Here are three specific aspects I would need for integration of contributed code:

1. I will write doctests in Python. That way I can express the function as it would be integrated in the PDG project code
2. The contributed Python script should run inside a Docker image. That way the dependencies are made explicit
3. The "docker build" can assume to have Internet access, but the "docker run" process should assume no Internet connection

As an example from the above blog post, I can express the interface as a Python3 function
def is_expression_valid_latex(expr_latex: str) -> bool:
    """
    >>> is_expression_valid_latex("a = b")
    True
    >>> is_expression_valid_latex("a = b +")
    True
    >>> is_expression_valid_latex("\si a")
    False
    """

By using sys.stdin, we could expose that function to the container such that the following would be an acceptance test:
docker run -it --rm demo:latest python3 /opt/my_script.py "a = b"
True