Euclid21: Euclid's Elements for the 21st Century - Getting Started ... and Getting Finished

Getting Started

At this point the nature of my interest in the project began to change. Finding those propositions which supported the Pythagorean Theorem gave way to the more general problem of finding the dependency structure among all of the propositions in all thirteen books of The Elements.

In my History of Mathematics course in Spring 2011, I proposed this as a project to Roberge, Brown, and Dahiya. We spent that semester and the following summer skimming, sometimes reading closely, through all thirteen books of The Elements [2] and gathering the information we would need to create a complete graph of the dependency structure of the propositions of Euclid. Milbrand learned of the project and joined the team that summer as well.

Very early on it became clear that a static graph would be neither interesting nor useful. Whatever we built would have to be interactive because, paradoxically, a complete, but static, graph of the dependencies in The Elements gives both too much and too little information. That is, it is so completely overwhelming as to be almost useless. The graph in Figure 4 is nearly complete. See for yourself.

Figure 4. A graph of all 13 books of Euclid’s Elements

Also, while the dependency structure is interesting, without the actual text of the propositions it is only a curiosity. We therefore set ourselves the task of implementing a dynamic, interactive visualization of the dependency structure of all axioms, definitions, postulates and propositions in all thirteen books of The Elements. In addition, the English text of each would also be available at the click of a mouse. We chose to use Fitzpatrick's [2] translation for this part because it is freely available.

When the code was nearly completed we presented it at the 2011 MathFest in Madison, Wisconsin, that August. To be sure, there was still some debugging to do but we were confident that it was nearly finished.

Getting Finished

Alas, it was not so. Upon returning from Madison we tried eliminating the bugs in our code but each time one was tamped down (I wouldn't say “fixed”) another, sometimes several more, popped up. We were caught in a seemingly endless bout of “Whack-A-Bug.”

It is easy to understand how this happened. The code had grown organically as we learned more about the internal dependencies in The Elements, sprouting new features as they suggested themselves to us, rather than according to an overall design. We proceeded this way in the beginning because we didn't know exactly what we were creating.  We were just having fun.

As a result our code had several features which were ultimately not very useful. Other, more useful features were buggy. That is, they didn't always work as intended and sometimes not at all.

However at this point we had gathered all of the dependency data from [2], and we had very precise ideas of what the code should and should not do. Clearly, it was time to scrap our first efforts and rebuild everything from the ground up, this time working from a clear set of design specifications. This was only possible because we had learned so much from our first efforts.

Unfortunately the students on the team were all near graduation and they were unaccountably unreceptive to the suggestion that they delay graduating in order to finish this project. Since I cannot program in Java (or any modern programming language) I had resolved to wait for another, equally motivated group of students with whom to complete the project.

Then the last member of our team, my daughter Mary Boman, joined the project.

She had been following our progress thoughout her senior year of high school, and was about to enter college as a Computer Science major. And, crucially, she could write Java code. When I expressed my disappointment that finishing the project would be delayed, she volunteered to take a stab at the re-write. I explained the design specifications to her and she completed the new version within a few months.