If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is – John von Neumann
Abstraction is a fundamental human skill and tool for understanding the universe. If you’re an artist expressing emotions and visual experiences, if you’re a mathematician investigating theorems and proofs, if you’re an engineer designing models and performing simulations, if you’re a software developer creating code for software systems, or if you’re an educator in need for transferring knowledge and motivating skills you must use abstraction to “create and communicate”. In one book about abstraction 1 the following definition is adopted:
abstraction is deﬁned as “the process of extracting the underlying essence of a mathematical concept, removing any dependence on real world objects with which it might originally have been connected, and generalizing it so that it has wider applications.” A good illustrative example of this abstraction process is geometry, which started from the observation and measurement of physical spaces and forms, moving then to the abstract axioms of the Euclidean geometry, and, later on, to non-Euclidean geometries, farther and farther removed from the perceived physical world. An interesting aspect of abstraction is that an increase in the level of abstraction is paralleled by a deepening in the understanding of the connections among mathematical concepts. For instance, by abstracting the Non-Euclidean geometry to “the study of properties invariant under a given group of symmetries” has revealed deep connections between geometry and abstract algebra. Moreover, abstraction can suggest direction of knowledge transfer among different domains.
I’ve been dealing with mathematical abstractions most of my life, as a student then as a software engineer and faculty member, on various levels and forms. My experience is like trying to find a safe path in a big forest of data and ideas that keep on growing and changing each day. Abstractions are like trees in the big forest; some are very tall and hard to climb but if you could reach their top you uncover vast areas of ideas and directions and you may even gain some wisdom about life itself. Some other abstractions are so weak and short-lived they just keep you warm at night or perhaps you can make a rope to climb the other tall trees of abstraction the next morning. Some abstractions are elegant and beautiful but may bare little fruit for quite some time (practical applications). Some abstractions are ugly but many depend on them for their practical usefulness. It also may happen that strong useful trees of abstraction can hide taller and better ones from our “mental vision” and at some point we have to either jump from them or completely cut them down from our minds to get higher. Finding a safe path inside such forest is a blessing not all are granted. Worse yet you could find your safe path and walk it alone as no other sees its elegance, usefulness, and security except you. Then you would have to call for company by creating a website like this one.
Writing your first computer code at 11 and continuing to write more code for 25 or more years gives you many joys, disappointments, questions, ideas, and ultimately more knowledge. From an early stage you realize that mathematics is both a fuel and limit for your computing skills. The more efficient your mathematical abstractions are the more powerful ideas you have, the more you can realize in your code, and the more wisdom you gain. This intuition was emphasized in my engineering study and practice through the universal presence of mathematics in computer science books and articles more than any other engineering discipline. Searching for and using good mathematical abstractions is, in my opinion, an important task for anyone in my position.
The Linear Engineer
Up to high school one gets usually familiar with some useful but “apparently distinct” mathematical abstractions. Several number systems (typically natural, rational, real, and complex numbers) are introduced. Polynomial algebra on real numbers is studied. Euclidean geometry in 2D and 3D (usually started by trigonometry and some analytic geometry) is presented. And some calculus is used to link the physical world to the mathematical world 2. Each of these abstractions are usually taught as sets of “mathematical recipes” that are barely related together by any common thread of thought. This method of teaching is very annoying, and ultimately limiting, to “deep thinkers” on both sides: teachers and students.
The first shock usually comes in the “higher education” at the university. One would expect that the sets of “mathematical recipes” would somehow merge into a set of smaller, more powerful and seamlessly integrating mathematical abstractions to suit the needs of engineers and scientists. Instead I found myself lost in a larger, more divided forest of “mathematical tools” rather than the well designed “garden of abstract knowledge” that I expected to enter in my engineering study. Instead I found myself lost in a larger, more divided forest of “mathematical tools” rather than the well designed “garden of abstract knowledge” that I expected to enter in my engineering study.
During my first year 3 I found the first step to my path, a.k.a Abstract Linear Algebra 4. I was blessed to be taught this course by Dr. Muhammad Yossuf 5 who had us view vectors and linear transforms as the elegant abstractions of Euclidean directions, positions, and motions, but with richer, deeper meanings and wider applicability by treating matrices as “convenient computational tools” rather than “mindless mathematical recipes”. This was my first time to climb a big abstraction tree and see the heavens and earth from higher grounds. The power of this concept of “linear abstraction” enabled me to view hidden links between seemingly diverse subjects of study in later years (like automatic control, differential equations, numerical analysis, and signal processing for example). Now I could invent new “mathematical recipes” and cook them into large amounts of computer code without losing insight into the basic idea behind the code. And once you find such path it’s impossible to go back.
It’s not strange that linear algebra is very important to engineers in all fields 6. For example the following statement taken from one signal processing book 7 can be found in many engineering books in some form or another:
Much information is available for both the analysis and design of LTI (linear time-invariant) systems. This is especially true for system design. In fact, in preliminary design stages for non-LTI physical systems, we often fit a LTI model to the physical system so as to have a starting point for the design. The LTI model may not be very accurate, but the use of an LTI model allows us to initiate the design process with standard design procedures.
I discovered after graduation, as my second shock, that the universe is mostly non-linear, that there is noting that can be time-invariant because of the second law of thermodynamics, and that most systems are very sensitive to initial conditions to be predictable for indefinite periods of time (as clearly stated by chaos theory and widely experienced in practice). Nevertheless, a linear system is a good starting point to model and solve almost all problems in engineering; mostly because many engineers are afraid of the darkness of the mathematics of non-linear chaotic systems, a very dark part of the mathematical forest of abstractions.
The Geometric Engineer
In Arabic the word engineering is pronounced “Handasah” and is said to be of Persian origin meaning “the ability to solve problems”. The word geometry is also called “Handasah” in Arabic; definitely not a coincidence. Since the dawn of human civilization geometry and engineering were the same. It appears that the need for regulating water supply and creating landmark buildings in the ancient world along with the in-built ability of the human brain to reason in 3D space was the origin of all engineering. Engineers can never understand, model, create, or maintain any technology without using a geometry of some sort. The natural way of expressing and understanding geometry is to draw elegant diagrams that made us proud in our first years as engineering students while taking care of drawing each line and writing every dimension. The natural way of expressing and understanding geometry is to draw elegant diagrams that made us proud in our first years as engineering students while taking care of drawing each line and writing every dimension. Although lines and planes are common in many engineering designs, they are not the only objects; not even the most important ones. Spheres, cylinders, cones, and many more complex non-linear objects are known and have been used through history.
Throughout history the main efforts to further our understanding and use of geometry have always been through algebra. From the very old theory of Pythagoras, through the vast advancements of algebra, trigonometry, and geometry by Muslim mathematicians 8, to the modern view of Cayley–Klein geometry 9, the struggle was to find algebraic abstractions to express geometric ideas. Currently we have many such algebraic abstractions (too many in fact); the problem now is not to find such abstractions, but how to teach them to whom it may concern!
The Computational Engineer
To create software based on geometric abstractions it’s impossible to “directly” explain yourself to a computer through the human method of diagrams and verbal explanations. One must use algebra, expressed as data structures and algorithms, to “generate” the code that implements the intended geometric knowledge. Even software systems with graphical user interfaces (GUIs) like AutoCAD and 3ds Max use algebra-based data structures and algorithms internally. The GUI is just a layer for our human convenience not for any intrinsic need of the computer itself 10. In our study as engineers the use of vector algebra and vector calculus is dominant. Any software library dealing with geometry must have matrices and vectors built into its core. My third “shock of abstraction” that happened after completing my M.Sc. was to find this use not motivated by the lack of better algebraic systems, but rather by a “series of unfortunate events!” 11. My third “shock of abstraction” that happened after completing my M.Sc. was to find this use not motivated by the lack of better algebraic systems, but rather by a “series of unfortunate events!” In addition, not all problems that can be described mathematically can be computed. The set of problems that we can “theoretically” compute solutions for is closely linked to the existence of an algorithm to solve the problem. Even in that theoretical set of computable problems we need to find an algorithm that produces acceptable results in “reasonable” time, hardware, and input-size requirements (remember the big O notation). One other problem is to find a programming language that “suits” the algorithm we found. The code should be writable, readable, and in general beautiful code 12. The first two problems are the hardest theoretically; the third is the hardest practically.
There are two main kinds of programming languages: the general and the specific. General purpose programming languages are dominant in creating geometric-algebraic solutions to our problems. Everybody knows C++, Java, C#, Python, or some other such language. But generality comes with many problems in readability, writablity, and elegance of written code. In addition creating code by a general purpose programming language usually separates the designer of the algorithm from the developer of the code. If the “geometric modeller” tries to write the code himself, as he should, using a general purpose language all kinds of problems often occur including memory leaks, bad performance, and having to learn the full details of a whole language just to create an efficient implementation of a required algorithm. Object oriented programming may solve some of these problems, but a good tool to implement computational software should contain a domain specific language (DSL)13 that can be used directly by the “domain expert” to write code that can be translated automatically to machine code or to a general purpose language code as an intermediate stage of compilation.
The Pedagogical Engineer
Pedagogy is the discipline that deals with the theory and practice of education; it thus concerns the study and practice of how best to teach. A good teacher is always on the search for better ways to transfer knowledge and skills to students. The most important skill to be transferred to engineering students is the ability to self-educate. Dealing with new technology every day, especially in computer science, is impossible without such vital skill. But all engineering is based on mathematical abstractions; especially the algebraic, geometric, and computational abstractions. The nature of many mathematical abstractions used in teaching is, in my own experience as an engineering student and teacher, the most limiting for motivating and transferring the skill of self-education. The same conceptually intuitive geometric abstraction is expressed using too many algebraic tools. Let’s take the simple concept of “rotation” as an example. Rotation is so geometrically basic that we deal with it easily in childhood; as individual children and as early human collective knowledge. Then we are taught to express rotations in the plane using trigonometry, After some time we use orthogonal matrices for the same purpose in 2D and 3D. If we take a course in electrical circuits we discover that electrical engineers deal with constant frequency “rotating vectors” in the form of exponential functions. If we use some computer graphics library like DirectX we use something called a quaternion to perform rotation in 3D space. The simple concept of rotation is expressed using too many algebraic abstractions with no apparent connection and no easy way of deciding when to use each tool and how to convert the geometric data to suit that algebraic tool. The direct result of such problem is a limited number of geometrically competent engineers; a very frustrating outcome for many teachers and students alike. Another consequence is the need for many teaching hours per subject to establish a mathematical base of algebraic tools specific to that subject 14. If there were a single abstract framework to be taught once for most subjects that would make more time for teaching the engineering concepts rather than the mathematical tools. The current state of affairs in engineering teaching is a lack of such a unifying framework; after all, abstraction is about unification through extraction of common patterns.
Geometric Algebra Computing
- We need to be linear engineers; to find linear approximations for non-linear systems and create models accordingly.
- We need to be geometric engineers; to think geometrically about our models and express our ideas algebraically.
- We need to be computational engineers; to develop algorithms and implement them, at least partially, using domain specific languages suitable for our needs.
- We need to be pedagogical engineers; to find a unifying mathematical abstraction suitable for building engineering skills in ourselves and our students in the most efficient manner.
The key point here is “algebraic abstraction”. We need to find some compact mathematical algebraic abstraction, superseding the common ones, that directly corresponds to our human geometric intuition. This abstraction should be general enough to express and generalize familiar abstractions (like complex numbers, quaternions, subspace operations, linear transformations, and more) using a unified framework of algebraic tools. Now we can think geometrically and directly express our algorithms using a uniform algebraic framework and interpret the results efficiently. Creating a simple DSL based on such abstraction would be much easier as a great step in unifying computational geometry. Teaching geometry using such algebraic and programmatic tools would be efficient, fulfilling, and much more productive to students and teachers.
The reason this website is mainly dedicated to Geometric Algebra is that it has the potential of being the algebraic abstraction system for geometric processing for this century, just as vector algebra was for the 20th century. My goal isn’t to add to the mathematics behind GA, that’s already been done quite sufficiently, but rather to illustrate, reformulate, explore, and implement solutions to common problems in engineering and computer science in the abstract language of GA. That step has already been taken in physics with remarkable success. It’s about time to do the same on a wide scale in engineering and computer science. The title of this site “Geometric Algebra Computing” may have several meanings associated with it. One such meaning is given by Dr. Dietmar Hildenbrand (http://www.gaalop.de/dhilden/) the author of the book “Foundations of Geometric Algebra Computing” and creator of “Geometric Algebra Algorithms Optimizer (Gaalop)” software. In his book, he defines “Geometric Algebra Computing” as:
The geometrically intuitive development of algorithms using geometric algebra with a focus on their efficient implementation.
Personally, I think about Geometric Algebra as a way of symbolic geometric thinking, not just another algebraic system. Computers can only be programmed when we fully understand the abstractions and processes involved in the problem at hand. Computing with Geometric Algebra is fascinating because it’s a high-level language for geometry as we humans think and understand and, at the same time, a logical algebraic system suitable for being a universal base for creating computer code for geometric processing using current compiler technology. Most of my research efforts are dedicated to illustrating and realizing the full potential of GA in various scientific computing applications.
I hope this site is successful in illustrating the power of GA-based linear models and DSLs. I hope you find your own path in the great forest of mathematical abstractions enjoyable and maturing.
- Saitta, L. “Abstraction in Artificial Intelligence and Complex Systems”. Springer, 2013 ↩
- Earl William Swokowski, “Calculus with Analytic Geometry: Alternate Edition”. Brooks/Cole, 1983 ↩
- Our study begins with a general preparatory year followed by 4 years of specialized engineering study. So my first year was actually my second. ↩
- Axler, S. J. “Linear Algebra Done Right, 3rd Edition”. Springer, 2014 ↩
- In that same year I got a copy the hand written lecture notes of another Abstract Algebra introductory course Dr. Muhammad Yossuf taught in earlier years. Though he didn’t give me the abstract algebra course himself, the lecture notes were enough to deliver his “messages of abstraction” elegantly; I’m deeply grateful for both courses ↩
- Engineers rely on linearity to such extent that reminds me with the joke about the man who lost his money in a dark place but went to look for it in a far well-lit place because he simply can’t see in the dark ↩
- Charles L. Phillips, John Parr, Eve Riskin, “Signals, Systems, and Transforms, 4th Edition”. Prentice Hall 2007 ↩
- See J.L. Berggren, “Episodes in the Mathematics of Medieval Islam”. Springer 2003; and Jim Al-Khalili, “The House of Wisdom: How Arabic Science Saved Ancient Knowledge and Gave Us the Renaissance”. Penguin Books, 2012 ↩
- Isaak Moiseevich Yaglom, “Geometries, Groups and Algebras in the Nineteenth Century – A History”. Ishi Press 2009 ↩
- Actually, all such systems have some kind of scripting language or API to be used for modeling activities, and is preferred in many situations over GUI modeling ↩
- The details of which is the subject of my second blog post ↩
- Andy Oram, Greg Wilson (Editors), “Beautiful Code: Leading Programmers Explain How They Think”. O’Reilly Media, 2007 ↩
- Martin Fowler, “Domain-Specific Languages”. Addison-Wesley Professional, 2010 ↩
- The mathematical tools needed for signal processing and electrical circuits are different from computer graphics and robotics, for example ↩