Beyond Coding: Key Skills for Successful Automation Projects

Translating mathematical equations into code is part of, but also removed from, the development of automation projects involving computer solutions. We must consider the efficacy of the mathematical equations relative to the needs of the project being developed. We must also consider the solution method for solving the equations with the data and timing involved.

Data issues that reach the solution algorithm must be detected, controlled, and when possible, corrected. Precision management must occur at various stages of the process. Errors created along the way by the solution process and implementation must be detected and managed.

This is a subject for books, but hopefully the thought process can be moved along with a few hundred words.

First, keep in mind that not everything we do not make specifically deterministic is, by default, stochastic. Computers and the procedures by which they solve problems can introduce obscure biases that, with analysis, are clearly deterministic—just not intentional. The simple ones that illustrate the problem go to precision. In many instances, we would like to think that intermediate values are exactly right or at least rounded using criteria we know from mathematics.

At various levels, truncation—instead of rounding—forces calculated numbers to fit into the variable size provided for them. Sometimes this doesn’t matter, but sometimes it introduces biases. It can be useful to use mathematical procedure and practice to actively manage the stored value of all calculated values so that the solution engine preserves the accuracy expected for them. This is commonly taught in programming classes, and frequently neglected because understanding and managing precision is boring and tedious.

Sometimes the observations lack consistency (e.g., because of sampling or synchronization issues) or reliable precision at the instant of measurement (e.g., due to transient instabilities). There are often ways to clean that up (e.g., by boundary limit checking, data analysis, and regression techniques). There are often ways to make something more than disclosed by the data stream, but many of them involve programmer conjecture about what may be happening. Be careful of this—a good outcome is too important to reject a priori, but an incorrect result can be more damaging than the value of the potential improvement it facilitated.

Sometimes the solution procedure itself, even with appropriate precision management, can introduce problems. Suppose we want to integrate a streaming function from now to infinity. Even very small errors or ambiguities, insignificant in a single calculation, grow to astronomical values when continuously accumulated over long periods of time. This can get mixed up with rounding and truncation and produce a disparity due to continuously biased measurement or integration methodology. This can manifest over time in huge errors, for example, in the “I” term of a PID controller. There are data control and precision management procedures, as well as mathematical ways of approaching the problem for the needed solution that resolve these issues, but the path to discovering them can be embarrassing.

Sometimes mathematics gets applied to a requirement without fully understanding the problem, the mathematics, or what the mathematics is actually designed to do. It may be possible, for example, to sometimes detect a situation and other times completely miss it using the exact same math.