Beautiful Code [206]
"A set of Level 3 Basic Linear Algebra Subprograms," J. J. Dongarra, J. Du Croz, I. S. Duff, and S. Hammarling, ACM Trans. Math. Soft., Vol. 16, pp. 1–17, 1990.
Implementation Guide for LAPACK, E. Anderson and J. Dongarra, UT-CS-90-101, April 1990.
A Proposal for a Set of Parallel Basic Linear Algebra Subprograms, J. Choi, J. Dongarra, S. Ostrouchov, A. Petitet, D. Walker, and R. C. Whaley, UT-CS-95-292, May 1995.
LAPACK Working Note 37: Two Dimensional Basic Linear Algebra Communication Subprograms, J. Dongarra and R. A. van de Geijn, University of Tennessee Computer Science Technical Report, UT-CS-91-138, October 1991.
"Matrix computations with Fortran and paging," Cleve B. Moler, Communications of the ACM, 15(4), pp. 268–270, 1972.
LAPACK Working Note 19: Evaluating Block Algorithm Variants in LAPACK, E. Anderson and J. Dongarra, University of Tennessee Computer Science Technical Report, UT-CS-90-103, April 1990.
"Recursion leads to automatic variable blocking for dense linear-algebra algorithms," Gustavson, F. G. IBM J. Res. Dev. Vol. 41, No. 6 (Nov. 1997), pp. 737–756.
The Long-Term Benefits of Beautiful Design > My Idea of Beautiful Code
15. The Long-Term Benefits of Beautiful Design
Adam Kolawa
Some algorithms for seemingly straightforward and simple mathematical equations are actually extremely difficult to implement. For instance, rounding problems can compromise accuracy, some mathematical equations can cause values to exceed the range of a floating-point value on the system, and some algorithms (notably the classic Fourier Transform) take much too long if done in a brute-force fashion. Furthermore, different sets of data work better with different algorithms. Consequently, beautiful code and beautiful mathematics are not necessarily one and the same.
The programmers who wrote the code for the CERN mathematical library recognized the difference between mathematical equations and computed solutions: the difference between theory and practice. In this chapter, I will explore the beauty in a few of the programming strategies that they used to bridge that gap.
15.1. My Idea of Beautiful Code
My idea of beautiful code stems from my belief that the ultimate purpose of code is to work. In other words, code should accurately and efficiently perform the task that it was designed to complete, in such a way that there are no ambiguities as to how it will behave.
I find beauty in code that I can trust—code that I am confident will produce results that are correct and applicable to my problem. What I am defining here as my first criterion of beautiful code is code that I can use and reuse without any shred of doubt in the code's ability to deliver results. In other words, my primary concern is not what the code looks like, but what I can do with it.
It's not that I don't appreciate the beauty in code's implementation details; I do indeed, and I will discuss criteria and examples of code's inner beauty later in this chapter. My point here is that when code satisfies my somewhat nontraditional notion of beauty in utility, it's rarely necessary to look at its implementation details. Such code promotes what I believe to be one of the most important missions in the industry: the ability to share code with others, without requiring them to analyze the code and figure out exactly how it works. Beautiful code is like a beautiful car. You rarely need to open it up to look at its mechanics. Rather, you enjoy it from the outside and trust that it will drive you where you want to go.
For code to be enjoyed in this way, it must be designed so that it's clear how it should be used, easy to understand how you can apply it to solve your own problems, and easy to verify if you are using it correctly.
The Long-Term Benefits of Beautiful Design > Introducing the CERN Library
15.2. Introducing the CERN Library
I believe that the mathematical library developed by CERN (European Organization for Nuclear