Upon Evaluation

Most of us were exposed to the concept of the Number Line in the early years of our education.  It looks something this:

Figure 1: The Whole Number Line

Our first encounter was usually the set of Whole Numbers, because they were easy for children to understand.  Subsequently, we learned that the Line could be divided into tiny pieces and, no matter how much we zoom in, there are always more numbers in between the ones we already know:

Figure 2: An Infinite Number of Numbers

Sometimes, we called this a “Real Number” Line.  Some of us suffered through enough math to encounter Imaginary Numbers, which could be arrayed along the same line.

Those of us who are young enough to have been exposed to “New Math”1 might recall the Number Line being described as “a set of points on the line”.  The Whole Number Line had an infinite number of entities, but was “discrete”.  The Real Number Line somehow had a bigger infinite number of entities, but was continuous.  Both were still “sets of points”; one was a subset of the other.

We didn’t know it at the time, but both sets were actually “spaces”: they were “sets” for which some sort of “structure” was defined.  Here, I’m using “structure” in the sense of “somebody has imposed some orderliness or meaning to the set”.  Kreyszig defines this concept as “…a set of (unspecified) elements satisfying certain axioms”2.  He goes on to observe that “…by choosing different sets of axioms we shall obtain different types of abstract spaces.” In other words, it isn’t just the points that we care about…the structure matters, too.

It is, for some of us, unfortunate that this discussion will rely on that same basic concept: for the purposes of System Engineering, “value” can be defined as being a region within a space.  This is a very abstract concept of “space”, accommodating all manner of “values” in which System Engineering might be interested.

Examples of such spaces include:

  1. The set of whole numbers
  2. The set of rational numbers
  3. The set of irrational numbers
  4. The set of ASCII Characters
  5. The set of letters in the English alphabet
  6. The set of Elements on the Periodic Table
  7. The set of ISBN’s
  8. The set of IP Addresses
  9. The set of MIL-SPEC’s
  10. The set of Library of Congress call numbers
  11. The set of entries in this here list

Most of the example sets are discrete (1, 3-11).  One is continuous (2).  Some are clearly numeric (1-3), and others (4-11) merely point to something on a list kept by some authoritative source.

Note that the definition of “space” given here that includes no formal concept of “distance” from one point to another, nor of measuring the size of intervals between the points.  Neither does it discuss whether such spaces are vector spaces, topological spaces, manifolds, or function spaces.  All of those concepts fit within the definition above.

This is not a very restrictive concept.  Almost any technical information can be rendered into a set of possible exact values and a subset thereof.  What matters is that we can point to subset of one or more elements of the space and say “these right here are the ones we’re talking about”.

As a practical matter, Engineering will usually refer to that subset as a “range”, usually expressed as being in the neighborhood3 of a theoretically perfect “nominal” location.  The region around the nominal is usually referred to as a “tolerance” (when used in requirements) or an “uncertainty” (when expressing results).  This definition of the region, which is fairly loose, accommodates all distributions of both tolerance and uncertainty4.

Most Engineers (especially the Analysts) will see little point in this distinction, but System Engineers deal with requirements and, therefore, with defining subsets of values that are permissible.  The discipline later ensures that, for each such item, the delivered value is a subset of the required value – a subset of the subset, as it were.

In many cases, we don’t care exactly where the “actual” value happens to be in the required range, but certain types of verification5 can be executed only if we successively select different combinations of exact values from a set of properties that interact.  We almost always deal with this problem by verifying the “shape” of the value’s distribution within the region, treating the “value” as being stochastic.  In that situation, the quoted “value” is not actually a set of points, but an algorithm along with explicit inputs for that algorithm.

This notion, that we can specify an algorithm (plus some explicit inputs) in place of an explicit value, requires a bit of abstraction.  We6 permit the algorithm+inputs to be treated as interchangeable with an explicit range of points7.  This necessity is a sufficient reason for us to define two interchangeable concepts of “value”: one that is explicit – that is, a given range of points – and one that is implicit: an algorithm+explicit inputs.  We further admit to the potential for sequences or networks of algorithms, each executing on the outputs from its predecessors, provided that at there are all inputs lacking predecessors are explicit.  This notion is further developed in the discussion of measures8.

While simple, this concept of “value”, which is more concisely found here, expresses a robust theory underpinning much of what System Engineers do…and the concept is simple.  If it seems hard, then I’ve explained it poorly.  Have a beer and read it again.

If that doesn’t help, try bourbon.

Footnotes
  1. Or old enough to have been terrified when their children were.[↩]
  2. Kreyzsig, Erwin, “Introductory Functional Analysis with Applications”, John Wiley & Sonc, Inc (1978)[↩]
  3.   In the sense of set theory.[↩]
  4.   Whether contiguous or not; whether symmetric or not.[↩]
  5.   e.g., Monte Carlo analyses.[↩]
  6.   System Engineers, that is.[↩]
  7.   Which might, or might not, have more than just one addressable point in it.[↩]
  8.   Which lies near the end of the sequence on Topical Analysis and Parameterization.[↩]