Drawing Abstractions

This post shall contain observations of interest more to computer programmers than to mathematics enthusiasts.

My work experience is in creating models of hardware designs, and using the models to verify the designs by comparing the outputs of the two in response to various inputs. The difference between the models I write and the designs I verify is that the designs are synthesizable into real hardware. The models I write to verify the synthesizable designs contain more architectural than microarchitectural detail. The difference between architecture and microarchitecture is that the end user of the hardware does not have direct control over or direct access to the microarchitectural details. Corroboration between the model and design is merely anecdotal evidence of the correctness of the design. However, this sort of anecdotal verification is often essential to verify a hardware design.

The program described in the last post is a procedure to find mathematical abstractions. I can think of it as a model of some of the mathematical structures governed by theorems and definitions given in previous posts. Even though I would doubt the correctness of the theorems if I found it impossible to model the intended structures, my goal in modelling the structures is not to verify the theorems. In fact, success in modeling the structures would be only anecdotal support of the theorems. My goal in modeling the structures is to satisfy the curiosity which helped to motivate me to produce the theorems. In that way, I could more easily move on to related topics.

The challenge of modeling mathematical structures differs from the challenge of modeling hardware designs. Hardware designs are more concrete than the mathematical structures I am modeling. I have an intuitive sense of what a portion of the model must do in order to model the corresponding portion of the design. However, in my simplex overlap model, the sidednesses are represented by 1s and 0s, and sometimes I lack intuition as to whether some intermediate 1s and 0s are correct. This intuition about the correctness of intermediate results is essential to debugging a computer program. Other than by direct inspection of and reasoning about the program source code, the only way I know to debug a program is by taking it one step at a time, and checking the results after each step. For me, the direct inspection technique works better when it is used in conjunction with the intermediate result technique.

Often, the intermediate results in my simplex overlap program are the sidedness relations of linear spaces. At least for fewer than 4 dimensions, I do have an intuitive notion of what a linear space is. I can represent such a linear space by a drawing. Thus, to check that a sidedness relation does represent a linear space, I attempt to draw lines and points which satisfy the sidedness relation. Unfortunately, converting the sidedness relation to a drawing requires a lot of trial and error. This leads me to desire a program which could draw the lines and points automatically, given any linear sidedness relation. If the program failed on a particular sidedness relation, when it succeeded in much less time on equally complex sidedness relations, I would suspect that the sidedness relation it failed on was not in fact linear. In that way, I could detect faulty intermediate results in the simplex overlap program.

Another advantage of having drawings of intermediate linear space results in the simplex overlap program is that I could use those drawings to check other intermediate results which are not linear spaces. For example, the inside of a triangle overlap would be obvious from its drawing.

Yet another advantage of a program to convert the sidedness relations of a linear space into a drawing is that when I do find all of the tetrahedron overlaps, then I will be able to more easily publish drawings of them. I suspect the actual drawings will be more inspirational and convincing than a simple count of their number.

Now I will describe the program which converts sidedness relations to drawings. It starts out with random coordinates for the specified number of points and boundaries. The coordinates of a boundary are the coordinates of a point on the boundary, together with the coordinates of a unit normal to the boundary. Given a set of coordinates, the program calculates a score by taking the sum of the signed perpendicular distances of the points from the boundaries. The program attempts to increase this score by randomly changing one coordinate at a time. The program reverts the change if it does not improve the score. As the score improves, the way the coordinates are changed changes from pure random to a sort of Brownian motion.

I wonder whether this program to convert sidedness relations to coordinates would be easier to debug than the simplex overlap program it is intended to help debug. I suspect it would be easier to debug because coordinates are less abstract than sidedness relations. Coordinates are concrete in that they can be displayed on a computer screen in a graphical way. To me, graphics are less abstract than symbols.