What math do I need to learn to create a general equation solver? I'm interested in creating a general equation solving engine, akin to wolfram alpha (though it doesn't need to be quite as advanced). I'd like it to be able to solve any of the equations students encounter from grade school to early college; so including...


Simple real number polynomials
Equations of complex variables
Vector and Matrix equations
Equations with differentiation and integration
Differential equations
(Possibly) Boolean equations


Also, I'd like to be able to solve these equations axiomatically. For example if you wanted to solve $x + 3 = 5$, you could find the steps like...

Subtract $3$ on the right hand side

$$(x + 3) - 3 = 5 - 3$$

Associativity of addition

$$x + (3 - 3) = 5 - 3$$

Additive inverse

$$x + 0 = 5 - 3$$

Identity element

$$x = 5 - 3$$

Subtraction

$$x = 2$$

So I realize this is a lot, and before I get myself in too deep, I'm looking to know what math I should know before I would be able to create something like this.

So I'm assuming it'd be mostly algebra. I've studied group theory a bit, and touched on rings. Could someone with more knowledge, point me in the right direction? Is this even feasible for a single person?
Think for approaches yourself and then have a look at how others did it.

Back in my early undergraduate days I thought "Why not write a program that produces theorems in an endless fashion and then go pick some new to publish them?" Given that cute idea I wondered how math worked at core and how to formalize it. I noticed two things:


Math objects have a class hierarchy pattern. A group is a pair of a set and a binary operation on it. A pair is a two-element set etc. pp.
Functionals in a boarder sense, i.e. objects that assign objects to objects play a central role and just using functions/methods (in the programming sense) capsuled in classes would not be enough to imitate this.


So in the end I came to believe I would need an object-oriented functional language to bring math into the computer. Imagine my surprise when I found out about Coq and that it does exactly that.

Notice that, as opposite to Wolfram Alpha, Coq is open source, so you can learn a lot from it and also use it as backend.

In the end, I became more interested with formally proofing theorems than to find them (I also realized my idea is close to read interesting information out of $\pi$), so now I'm a Mizar enthusiast. Mizar is not open source, and it doesn't proof things for you but checks your proofs, very rigorously.
Think for approaches yourself and then have a look at how others did it.

Back in my early undergraduate days I thought "Why not write a program that produces theorems in an endless fashion and then go pick some new to publish them?" Given that cute idea I wondered how math worked at core and how to formalize it. I noticed two things:


Math objects have a class hierarchy pattern. A group is a pair of a set and a binary operation on it. A pair is a two-element set etc. pp.
Functionals in a boarder sense, i.e. objects that assign objects to objects play a central role and just using functions/methods (in the programming sense) capsuled in classes would not be enough to imitate this.


So in the end I came to believe I would need an object-oriented functional language to bring math into the computer. Imagine my surprise when I found out about Coq and that it does exactly that.

Notice that, as opposite to Wolfram Alpha, Coq is open source, so you can learn a lot from it and also use it as backend.

In the end, I became more interested with formally proofing theorems than to find them (I also realized my idea is close to read interesting information out of $\pi$), so now I'm a Mizar enthusiast. Mizar is not open source, and it doesn't proof things for you but checks your proofs, very rigorously.