For new readers and those who request to be “好友good friends” please read my 公告栏 first.
(Applied Mathematics, Theoretical System Engineering, and its Experimental Counterpart.)
Up until the middle of last century, applied mathematics often is taken to be synonymous with theoretical physics. In fact the famed Cambridge University in England still has a department of Applied Mathematics and Theoretical Physics (DAMTP) where the Lucasian chair resides (past occupants include Isaac Newton, Paul Dirac, and Stephen Hawkings). The history of physics rest on the triumvirate of experimental evidence, theory building, and mathematical proof. This is true with astronomical observations on which Newton builds the theory of universal gravitation whose validity and proof was enabled by the invention of calculus. Current cosmology also relied on the experimental observations from various atomic accelerators, the theory of strings, and the Yau-Calabi mathematics. This tradition is well established.
Since the rise of disciplines such as operations research and control systems, applied mathematics became not only as a descriptive (mathematics applied to physical phenomena ) but also a prescriptive methodology. It is concerned with not just “how things are” but also “how things should be” (see http://www.sciencenet.cn/m/user_content.aspx?id=38683) Descriptive applied mathematics is directed mostly to physical phenomena (fluid dynamics, thermodynamics, electricity and magnetism, etc) while Prescriptive applied mathematics dealt with manmade phenomena (electric power grid, air traffic systems, manufacturing automation, etc). Here the nature of the problem undergoes a subtle change. In physical phenomena, you live with whatever God given existing laws governing the underlying physical phenomena. Mathematics and mathematical models are primarily used to explain and understand succinctly such physics. In mathematics applied to manmade phenomena, we are dealing often not with existing objects but objects we have only imagined. These objects behave according to manmade rules of operation which can themselves be changed to suit our desires. Thus we are creating as well as controlling such systems. Mathematics is used to design such systems. The idea of “optimization” or “making it better” naturally creeps in.
Here the importance of “rigor” in mathematics comes in, i.e., you better be absolutely sure what you are talking about or creating is only based on “truthful axioms” and “logical deductions”. Mere “Intuition” can be dangerous. The rationale here is that without “rigor” you may be building “空中楼阁” or a “house of cards”. Otherwise, how can you trust the outputs of a computer? On the other hand in mathematics of physical phenomenon you always have reality to face or to guide you. In the operations research, control and system field however, we enter the “twilight zone”. We are both designing (creating) systems as well as controlling existing physical systems with equal emphasis on both tasks. Here often the arguments and disputes for and against “rigor” become heated and confused. In my opinion, the need for “rigor” and the utility of “intuition” depend on what you do. If you are proving the convergence of a newly untested computing algorithm on a mathematical problem you created, you’d better be sure that the proof is rigorous. On the other hand, many well known and applicable results, such as the Draper prize winning Kalman filter, have been successfully used in situations where we know the assumptions and conditions are only approximately true or not even true. Here intuition and experience are as necessary if not more so than “rigor”. The difference here is not between absolute right or wrong but between applied mathematics with a big “A” versus big “M”. Mutual respect and understanding will go a long way towards resolving conflicts.
Putting this in personal terms, I do not feel bad when I am accused of being not “rigorous” in my papers. I deal with real world problems and/or problem-driven methodology research. Reality always provides sanity checks for me and prevents me from being dead wrong. Ideas, intuition, and practical usefulness are important to me in my work. But I always insist that my engineering students be conceptually rigorous and understand what is meant by a “proof” (easily said than done). A working knowledge of the language of mathematics so that one is capable of accessing mathematical literature is useful regardless whether or not you are application or theory oriented (just like English is useful for S&T work regardless of your mother tongue) Instead of letting applied mathematics be synonymous with theoretical physics as in olden days, I’d like to suggest it can also be equated to “theoretical engineering” in particular to theoretical systems engineering. But then question arise as to what is the counterpart to experimental physics in this new triumvirate of Applied Mathematics, Theoretical Engineering, and Experiment Engineering. In simple application of physical laws to real word engineering problem, this is not much of an issue since the physics behind the engineering is already well understood, tested, and codified in handbooks and practical formula. But in the realm of complex system engineering problems, experimental observations are often difficult if not impossible to obtain. The systems under discussion may not even exist or impractical to be experimented upon. It is here the idea of “SIMULATION” was born.
Simulation in simplest terms is to build an electronic/digital replica of the real world system upon with which we wish to experiment. Two issues are involved. First, we need to make sure that the replica faithfully models the real world. Short of duplicating the real system down to the very last detail, approximations, assumptions, and simplifications are inevitably involved in model building. How to construct a model that will capture the essential properties of the real system of course is problem-dependent and varies according to the system under consideration. The second issue deals with the computational burden of performance evaluation of a simulation model. Almost all simulation models involve computing expected value of a random variable (i.e., the performance of the system on the average) since in complex systems uncertainties and randomness abound. Computing expected value requires averaging the results of repeated simulation of a model over many different realizations (in principle an infinite number of realizations) of randomness. Thus, in practice, with finite computing budget such expected values are always ESTIMATED. The problem of estimation accuracy and confidence of estimates of using a simulation model becomes a sub-discipline of statistics. Most simulation textbooks dwell on this topic at length. We won’t repeat the essence here.
Furthermore, executing many replications of a complex simulation model is computationally intensive to the point that a single evaluation of expected performance of a complex simulation can take several hours of computer time (e.g., Y.C. Ho Ordinal Optimization , Springer-Kluwer, 2007, page 2). And if we wish to use the simulation model to design or improve system performance by searching in design parameter space via repeatedly running the simulation model, the task soon becomes an impossible. My own researches for the past 15 years have been involved in overcoming this seeming impossibility (see book referenced above and http://www.sciencenet.cn/m/user_content.aspx?id=2501 )
By hindsight, the discovery of the theoretical engineering tool of Perturbation Analysis via experimental system engineering and ultimate rigorous mathematical proof of the same is another illustration of this experiments-theory-mathematics triumvirate of the subtitle of this article (see also related article http://www.sciencenet.cn/m/user_content.aspx?id=29014 )
(Note: portion of the text of this article first appeared in one of my earlier blog articles. I repeat them here for the convenience of the reader so that their reading will not be interrupted requiring referencing back-and-forth between several articles).