Math Expert

Let me do your work

Preview

Introduction

Math Expert is our (@salastro, @younis-tarek, @marawn-mogeb) math high school graduation project. The project tackles the problem of generating beautiful, quick, and useful mathematics. While most software can either only generate beautiful formatted PDF (i.e. LaTeX) or sufficiently solve mathematical problems (e.g. Wolfram|Alpha). There may be, however, alternatives to these tools, yet they can not fully grasp the potential of either of them or are slow and hard to use. Therefore, this project tries to do what others failed.

Inner Workings

Our approach was to create an easy-to-use graphical user interface (GUI) that uses different components to reach our goal. LaTeX is the main PDF generation backend due to its indubitable abilities and speed; it is the universal standard for mathematical notation. However, it is reasonably hard to use making it difficult to use in a short-term practical context. This makes the application even more useful. It was mainly interacted with through PyLaTeX; it provides a usable set of commands that make use of LaTeX's capabilities. The standard article document class with numbered math alignment environment and TikZ drawings was used.

Although both SymPy and NumPy were used, the focus was on SymPy due to its nature of symbolic manipulation and its alignment with the goals of the project. The latter is powerful in mathematical evaluations, which — although supported — is not the focus of this project. The results of all functions, other than Evaluate, are performed through SymPy. It provides more than one function to perform some of the operations at hand, but the one that proves to be the most effective is used. For example, there are integrate and manualintegrate, and although the latter can show steps (non-human-readable), the former was chosen for its wide variety of solutions.

Unlike the previous two, the choice of a GUI framework was not a straightforward decision. Kivy was a serious candidate, but due to its own unique syntax for designing being its bedrock and lack of some convenient Python capabilities use, it was not feasible. Another option was Tkinter, which is considered the main framework for Python. However, it is very lacking some modern UI design features and is not plain sailing in some considerable aspects. The final option was PyQt5, which is a Python binding for the Qt cross-platform framework. Basically utilizing all of the powerful aspects of the Qt framework, which avoids the aforementioned limitations, while maintaining a usable toolkit. A highly programmable interface that is easily integrable into other environments was the product of this decision.

Philosophy

Although the infamous it just works are spread throughout the codebase, which is not ideal for a structured project, the goal of our is to define a great code that follows best practices (e.g. PEP 8) to have a readable, maintainable, and legacy-free codebase to stand in the way of passing time for the longest. As such, a minimal amount of code is necessary to avoid using breakable functions; a suitable modus operandi is the suckless philosophy. On the other hand, extensibility and customizability are as important. Unix philosophy is the one method that is well-regarded as the jewel in the crown.

Object orientation was used due to its inheritance, encapsulation, and other proprieties; some of which can not be achieved through modularity alone resulting in a more complex codebase. In addition, the structural way PyLaTeX handles documents would make it even harder to avoid object-oriented programming, despite its known disadvantages. However, parts of SymPy and NumPy code were written more procedurally.

Codebase

As mentioned above, the goals of the code are minimalism, functionality, extensibility, and customizability. The program is divided into 3 separate files: gui.py for all of the UI elements, func.py for all the operations on documents, and main.py for the main program and linking of the two. This was to ease the switching of undesired modules and separate development based on the working context.

func.py was mainly structured as one class (MathDoc) with multiple methods for document manipulation (e.g. Inte, Diff, etc). The class is instantiated and used in main.py in the __name__ == "__main__" if statement after the imports outside the conditional; on every button click the corresponding method is called. In contrast, explicit mentions of gui.py are rare (besides the linkage ones) since all of its handlings is in the file itself.

Properties

Advantages

• Easy-to-use
• Fast
• Accurate
• Concise Formatting
• Extensible
• Programmable

Disadvantages

• poor error handling
• limited syntax input
• limited operations
• no-preview before add
• undoable actions

Neutral

• Unappealing UI
• No indication when unsolvable

Future plans

See issues

Usage

Although the interface is obvious, some clarifications may need to be made.

• First text input is the file name without extension
• Second text input is the document title
• Third text input is the author(s) title
• Fourth (and last) text input is the mathematical expression to be operated on
  • Euler's number should be written as exp(x) instead of e^(x)
  • log is the natural logarithm.
  • Multiplication should be written in the form 2*x
• After defining all the previous inputs, click Generate PDF
• Choose the type of operation you want to perform, then click Generate PDF again

Dependences

Building

• Python 3.10:
  • PyLaTeX 1.4
  • SymPy 1.10
  • NumPy 1.22
  • PyQt5 5.15

Running

• LaTeX (see #9)
• Perl (see #12)

COCOMO estimates

Using scc

───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
Python                       4       465       36        24      405         17
───────────────────────────────────────────────────────────────────────────────
Total                        4       465       36        24      405         17
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $10,457
Estimated Schedule Effort (organic) 2.431055 months
Estimated People Required (organic) 0.382159
───────────────────────────────────────────────────────────────────────────────
Processed 19228 bytes, 0.019 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────