Higher Algebra with Operator Overloads (Brian Beckman)



Recently I did a Channel 9 interview with Beth Massi where I walked through a Visual Basic program that used Generics and Operator overloads to perform some higher mathematics. I thought I’d follow up with a post explaining the details of exactly what I did.

Operator overloads with Generics enable some beautiful designs for data types in Higher Algebra, a branch of mathematics, sometimes called Abstract Algebra. Consider fields and vector spaces. I’ll show you operator overloads at THREE levels in a single design. First, background: In this context, a “field” is a collection of unspecified objects, closed under two associative operators, + and *, that obey the distributive law.

Closed means that for any a, b, and c in the field, a+b and a*c are in the field. Associative means

a + (b + c) = (a + b) + c

a * (b * c) = (a * b) * c

Distributive means

a * (b + c) = a * b + a * c

(b + c) * a = b * a + c * a

The field must also have two special members: the additive unit 0 and the multiplicative unit 1, where

a + 0 = 0 + a = a

a * 1 = 1 * a = a

and must have for every a, an additive inverse, -a, such that a + -a = -a + a = 0. There must also be a multiplicative inverse for every element except 0, written 1/a, such that a * 1/a = 1/a * a = 1.

Some authors insist on the commutative laws (a + b = b + a, a * b = b * a), too, but we don’t, here. The most common examples of fields are the Rationals, the Real numbers, the Complex numbers, all of which have commutative addition and multiplication; and the Quaternions, which have non-commutative multiplication.

Don’t confuse the mathematical “field” with a “field” in a record, structure or class.

In each instance of a field, we define + and * to do anything we want so long as they obey the associative and distributive laws. A “vector space over a field” is the set of n-tuples or vectors built up from members of the field and closed under an additional linear combination law, written with no operator symbol, or sometimes with *. If v and w are any two vectors, and f and g are any two members of the underlying field, then f v + g w is a vector, and, furthermore,

f (v + w) = f v + f w

(v + w) g = v g + w g

(f + g) v = f v + g v

w (f + g) = w f + w g

Vector spaces are central in physics and simulation. Imagine 6-vectors of real numbers; such things represent particle states in “phase space” in classical mechanics. Imagine 4-vectors of complex numbers; such things appear in quantum mechanics. Similar structures occur all over Quantum Theory and Gravitation


  • “Vector Calculus, Linear Algebra, and Differential Forms” [VCLADF], by John H. Hubbard, Barbara Burke Hubbard;
  • “Lie Groups, Lie Algebras, and Some of Their Applications,” by Robert Gilmore
  • “The Geometry of Physics,” by Theodore Frankel

Applications for vectors of quaternions are not so easy to come by, but, they are perfectly well defined, and, if we do our software design right, they “just work.” Ditto for vectors over a purely symbolic field or over any other kind. It’s not difficult to support field-like algebraic structures with non-associative multiplication within the same software design. Such things include the Cayley numbers or octonions, but, because of non-associativity, they don’t mesh easily with linear algebra, and that’s where we want to go. Stop with the quaternions.

We extend the design to inner-product spaces, in which every vector has a dual, and to linear algebras: sets of linear transformations of vectors, realized as matrices. With just a little code, we build a general, extensible, optimizable library suitable for physics, engineering, and mathematics in any finite-dimensional vector spaces.

We want three layers:

  • underlying types
  • field types, generic over the underlying types
  • linear-algebra types, generic over the field types

The underlying types comprise built-ins like Double, and custom types like Rational, Complex, Quaternion, and Symbol. Underlying types should implement the basic field operations, but can have many more operations for convenience, like optimized division routines. Operator overloading is a no-brainer for the underlying types.

At the top level of the linear-algebra types, operator overloads are again a no-brainer for vector + vector, matrix * vector, vector * matrix, matrix * matrix, vector * vector, and so on.

At the middle layer, the field types abstract and narrow the operations down to the bare minimum so that the linear-algebra types know what and only what to expect. In this layer, operator overloading is not quite a no-brainer, and there are a couple of different ways to go with a design.

The first paragraph showed the field axioms, and these are what we must design into our field types. One way to do that is to impose the field operations by interface:

An upside of this design is that both Structure types and Class types can implement the interface. Thus, the linear-algebra classes are independent of differences of copy semantics. Programmers may use Structure types for run-time speed at both the underlying-type level and at the field level.

Here’s an example of a Structure implementing a field of Doubles

A Big Downside though, for the purposes of this exercise, is no operator overloads at the field level, because operator overloads
are Shared by definition (i.e., static) and interfaces can’t support static methods (the reason is that static virtual methods don’t make sense in .NET, and all methods in an interface are virtual).

But, we want operator overloads at the field level, and we can get them through an alternative base-class design for fields. We lose Structures at the field level, since particular fields must inherit from a base Class, but the underlying types can still be structures.

Now we have operator overloads at the field level, but they’re not virtual (they can’t be). What they do is statically dispatch to
virtual ADD and MUL methods, which are just like the ones we had in the interface design for the field level. Nice, eh? Here are the implementations for the field of Complexes, which are implemented in an underlying Structure type:

And here is its underlying type:

Now, we have an example of a Field generic on an underlying type, How about the Vector space? I wrote one vector space generic
on the interface-style Field design, and another vector space generic on the base-class Field design. Here is the latter one, it’s prettier:

There we go: operator overloading at three levels! I’ve uploaded a zipped Visual-Studio 2008 project to my Public folder with all this code.
Play around, let me know what you think.

Beth Massi

Follow Beth   

No Comments.