Advanced Engineering Mathematics (AEM) can be used in a course for engineering students who are at the beginning graduate or advanced undergraduate level. It could also be used in a course for junior undergraduate engineering students who have undergone an elementary course on ordinary differential equations (ODEs) and matrices. In addition, this book could be used by undergraduate engineering students in a variety of their post-calculus mathematics courses and by undergraduate students pursuing applied mathematics courses.
This book aims to (1) be comprehensive and self-contained, (2) be relatively “lean and lively,” (3) have an appropriately varied pace, (4) be accessible and well written, and (5) have a large choice of appropriate and varied homework problems. It is designed for a heterogeneous group of engineering students in order to extend and enrich their knowledge and to introduce them to new topics. Students who use this book will become well prepared for their engineering courses.
This book successfully blends intuition and logical reasoning. It deals with more advanced material than most textbooks of its kind but does so in a way that is accessible to advanced undergraduate audiences. It helps students understand the basic “what” and “why” questions and learn material at several levels, thus extending their capabilities. Software packages evolve and are even replaced, but the “what” and “why” questions they address are more constant. The habits needed to discern these questions will serve engineers well as they progress through their careers.
For most engineering students a deductive, “theorem/proof/special case” style of exposition is alien to their ways of learning things. But most people appreciate the need to explain things that they are interested in. Sometimes, a plausibility argument is the most accessible explanation. Most engineering graduate students need more practice with logical arguments that explain why techniques are correct or at least plausible, and this will enhance their problem-solving and communication skills.
Often an example leads to its standardization in a definition or a theorem with general applicability. The style of exposition is usually inductive rather than deductive. Also, in order to not overwhelm them, I show students the difficulties gradually and often begin with analogies to familiar topics. It is precisely the students who are less well prepared who need this book the most.
As Epsteen (1913) wrote, “The professor of engineering is certainly on firm ground when he takes the stand that the mathematics taught to his students should not be too abstract on the one hand nor too concrete on the other. If the subject matter is too abstract it is unintelligible or uninteresting to the beginner; if it is too concrete the science degenerates to the mere performing of certain mechanical operations to a common tool instead of a valuable instrument.” This is still a very good guide to follow.
As Henderson (1997) wrote when discussing a survey of what businesses looked for in hiring bachelor’s degree holders: “Although engineers may not often need to develop novel mathematical techniques, an ability to read, interpret and implement such techniques is still a vital part of engineering research and development.” In this book, the role of theory is to organize results, provide solution techniques, illuminate what to calculate, and to assure when it is best to calculate. Theorems allow us to avoid reinventing the wheel” and thus are part of a style of establishing formulas and other results that is analogous to the engineering style of standardization. In general, theory in this book directly relates to methods. Usually, “theory” consists of derivations of useful identities.
My choice of what to explain is driven by what I can reasonably expect the readers to explain when they do the problems. What most readers learn from the text connects to what they really learn from working on the problems.
A lot of what engineers do these days is to use software packages; some engineers in research and development also help create software. As much as possible, software should not be a “black box” for the user. While this book is not a book about software packages, I want to give students the mathematical tools they need to understand what their software hopes to do and sometimes even how the software does it. In context, I show students useful MathematicaTM and MATLAB commands in strategic places.