This post is due to the requests of several independent engineers and programmers. They expressed disappointment at their mathematics education and its failure to impart a deeper understanding of the formulas and algorithms they were taught to use.
This also reflects my observations of teaching university mathematics over the years. I started as a TA (and frequent substitute lecturer) in 2008, and have taught all levels of calculus, basic statistics, and advanced statistics at both the undergraduate and graduate level. I’ve certainly noticed even since 2008 a de-emphasis on proofs and “why” in favor of more examples, applications, and formulas in general. In fact, proofs were passed over in lectures in calculus courses meant for general engineers because “there wasn’t enough time”, or it was not considered something engineers needed to know.
This attitude is actually fairly recent. Many of the older calculus books in my library were written for engineers in an undergraduate program, and these books are quite proof-heavy. Some examples are F. Hildebrand's Advanced Calculus for Engineers (1949), Tom Apostol's Calculus (Volumes 1 and 2), and R. Courant's Differential and Integral Calculus (1938), to name a few. For a more modern text that still has some proof treatment, the 10th edition of Calculus: One and Several Variables, by Salas et al is a good resource. I used this one both as a student at Georgia Tech and an instructor. (I'm pretty sure I've done every single problem on every single page of that text..) However, when I taught at University of Texas at Arlington as a grad student from 2013-2015 and then Foothill College in early 2018, the texts they chose to use were woefully inadequate to suit a college-level calculus course; proofs were nonexistent, and reasoning was thrown away in favor of contrived examples. The course was designed to steer engineers away from any proofs or thorough reasoning, showing the experience is somewhat widespread.
I do not want to discuss the reasons for this departure; this isn’t an education site. What is important now is to discuss how to satisfy the desire of an engineer or other highly technical person using various mathematical topics/formulas to develop a deeper understanding of what he is doing. It wouldn’t be particularly helpful to simply suggest acquiring books and reading the proofs.
The best thing an education can give is the ability to teach oneself through developing methods of logical thought and creativity. There are books on formal logic and mathematical proofs circulating, but they can be a bit daunting to start with, as they are quite abstract and discuss mathematical logic and proof theory in general. For those who do want a formal proofs resource, I recommend How to Read and Do Proofs, by Daniel Solow, and Proofs from the Book by Martin Aigner and Gunter Ziegler.What I’ll give here can be considered a friendly introduction to the use of mathematical proofs to facilitate understanding.
Def. 1:The degree of a vertex $v $ in a graph $G $ is the number of edges connected to $v $.
Def. 2:The degree of a vertex $v $ is the number of vertices adjacent (connected to) $v $.
Def. 3:The degree of a vertex $v $ is the number of vertices in (or cardinality of) the neighborhood of $v $. (Formally, mathematicians would say that the number of elements in a set is the cardinality of the set.)
An end-vertex or pendant vertex in a graph is a vertex of degree 1.
Here we are taking a specific example and looking to see if a definition is satisfied, typically because we know that (due to theorems) we get certain properties we either want (or maybe don’t want) if the definition is satisfied.
For example, network engineers like to have resilient networks. By “resilient”, I mean that they’d like to be able to tolerate a link failure and still be able to send information anywhere on the network. It would be really bad if a particular link failure isolated a node/switch so that no information could reach it.
Let’s try to frame that in mathematical terms. A network can be drawn as a graph, with circles representing nodes/switches/computers, and edges between nodes representing the physical links connecting them. We want to design a network so that a single link failure anywhere in the network will not isolate a node.
We can mathematically represent a link failure by the removal of an edge. So we can take our graph representing our network, and start testing edges by deleting them to see if a node ends up isolated with no edges emanating from it. Or..we could return to a definition from earlier and think ../about this mathematically.
If a single link failure isolates a particular node, then that means only one edge sticks out from it. That means that node has degree 1, by our first definition of degree. Thus, we may now conclude that this node also fits the definition of an end-vertex.
Moving back to the practical space, we conclude: a vertex can only be isolated via a single-link failure if it’s an end-vertex. We can also write the statement the other way: If a vertex is an end-vertex, then the deletion of its incident edge isolates it.
Now, thanks to these definitions, and our understanding of them, we can find a way to spot all the end-vertices in a network. Since we have multiple ways of looking at this problem, we can find the way that suits us best.
Using definition 1, we can count the number of links from each node. Any node that has only one link connected to it is an end-vertex, and the failure of that link will isolate that node.
Using definition 2, we can count the number of adjacent neighbors, especially if we have a forwarding table stored for each node. If any node only has one other node in its table, it’s an end-vertex, and the removal of the link connecting the two nodes would isolate our vertex.
I used a fairly visual, practical definition and example here. Other definitions in mathematics can get fairly involved; I’ve spent hours simply picking apart a definition to understand it. But the strategy doesn’t change. The first step in developing a deeper understanding of mathematics is to pay attention to definitions--not just what they say, but what they mean. The next article will discuss how we use definitions to write theorems and understand proofs.