Symbolic algebra and typing
Incomplete thoughts.
If you start from scratch, asking yourself “How would I build a tool to help me perform classical mathematical computations more efficiently?” One of the challengies that quickly arrises is figuring out how to represent classical expressions in their full generality.
Last week, I was doing some prep work for class, and wanted to extend sympy to allow perplex and dual number systems, the same way it handles imaginary numbers. In the abstract, this didn’t seem like it should be so hard a task – these number systems have allot of similarities to complex numbers, and pretty much all of the properties I was interested in could be defined in terms of one new variable for each.
The task turned out to be more difficult than I’d hoped. In sympy, many of the properties of the imaginary unit \(i\) are hard-wired into the code in ways that don’t reveal themselves until you start making changes intended to chage the behavior of \(i\).
I am not an expert in computational algebra, but I have made some contributions. One of the major break-throughs in computational symbolic algebra was the leveraging of object-oriented type structures to implement expression representations. Using object-based representations allows arbitrary expression trees and atomic variable properties, freeing algorithms of the burdens of representation.
While sympy’s class-structure for computational algebra seems revolutionary when you first learn to parse it, the overall implementation of sympy turns out to have some overall weaknesses. I think we need a re-implementation, based on multiple dispatch and more robust term typing.
Multiple dispatch is a language tool that allows functions to be called based on a name AND the types of its arguments. Thus, you can write multiplication between different objects and expect the language to make the appropriate interprettation without the usuer having to make explicit reference.
The big question is typing – we see a growing need for stronger typing in python, but typing carries its own downsides and dangers, and it remains unclear to me how to implement typing so that is both comprehensive, generalizable, and concise.
Consider the problem of typing an abstract finite group. The elements of the group are symbols – we can name them and list them. But in the abstact, those symbols only have meaning IN THE CONTEXT OF THEIR GROUP. Outside of their group, these abstract symbols are meaningless. But often, these abstract groups have concrete representations (in terms of permutation matrices are some other objects), and these objects do have meaning outside of a particular group – they may have a particular meaning in a particular context that is orthogonal to that abstract group they are also elements of. So, how are we to organize typing so that an object – the same object – may or may not be associated with a group, depending on the context we’re interested in working in at a time?