Until I began studying discrete math, my idea of a function was something along the lines of formulae such as** f(x) = x ^{3}**,

**, or**

*e=mc*^{2}**. Very likely, this is true for most people. Math education from elementary algebra to differential equations focuses on functions that return a real number value. However, this is a very limited view of functions. Functions are a special type of relation, and they may be used with sets that do not include real numbers. Here is the formal definition of a function as offered by Epp in**

*F=ma**Discrete Mathematics with Applications 4*

^{th}Ed.A function from a set

Xto a setY, denotedf : X –> Y,is a relation fromX, the domain, toY, the co-domain, that satisfies two properties: 1) every element inXis related to some element inY, and 2) no element inXis related to more than one element inY. (1)

From this definition, it is clear that functions are more restrictive than relations in how they connect sets. Like binary relations, functions consist of ordered pairs. In a relation, a domain element may be related to more than one co-domain element. Functions, on the other hand, permit a domain element to have ** only **one co-domain link. For example, a relation may contain the following ordered pairs:

** R **= {(1,2), (1,3), (2,7), (3,5), (3,8)}

However, function rules do not permit the duplicate domain elements (the first elements of ordered pairs). Therefore, the following pairs would be acceptable in a function.

** F** = {(1, 2), (2, 7), (3,5)}

In addition, relations permit domain elements to have no co-domain link at all, whereas functions require that all domain elements be linked to one, and only one, co-domain element. The contrast between relations and functions is best seen with a diagram.

Here is a relation.

**Figure 1**

Notice two things: 1) one dot has two arrows going from it to the co-domain (okay for a relation, but a no-no for a function), and 2) there is one dot with no arrow going from it; also a no-no for a function.

Here is the diagram of a basic function.

**Figure 2**

Note here, that every domain element has an arrow from it to an element in the co-domain and that no domain element has more than one arrow going from it. It is okay that some co-domain elements are not paired up and that some receive more than one arrow.

**Range vs co-domain
**The co-domain of a function consists of all elements that can potentially be paired with a domain element. The

**of a function consists of all elements that are actually paired up with domain elements. Thus, the range of a function is a subset of its co-domain. In Figure 2, there are four total dots within the co-domain, but since only three of those dots are paired with domain elements, the range consists of just those three dots.**

*range*Now that we have seen the differences between relations and functions, we can look at three basic types of functions—*injective, surjective *and* bijective*.

**Injections**

An injection is a type of function that is referred to as ** one-to-one **(1). In one-to-one functions, co-domain elements are connected to one and

**one domain element. This restriction is shown in Figure 3. Each co-domain element is paired with ONLY one domain element. (There is no requirement that EVERY co-domain element be paired with a domain element).**

*only***Figure 3**

*One-to-one practical example*

When patients are being seen in an ambulatory setting, they are placed in an exam room prior to being seen by a provider. A function that assigns patients to available exam rooms must assure that: 1) every patient is assigned to a room, 2) no patient is assigned to more than one room, and 3) no two patients are assigned to the same room at the same time. Thus, at any given time, there is a one-to-one pairing between patients prepped to be seen by a provider and occupied exam rooms. Injective functions may have ranges that contain fewer elements than the co-domain. In Figure 2,** the domain ={A,B,C,D}; co-domain = {1,2,3,4,5}; and the range = {1,2,4,5}**

**Surjections**

Surjective functions map EVERY element of the co-domain to an element in the domain, making the range and co-domain equal (1). Figure 4 illustrates a surjective function. The** co-domain = {1,2,3,4} **and the **range = {1,2,3,4}.** Surjections are also referred to as ** onto** functions.

**Figure 4**

*Onto practical example*

In an ICU, every patient is assigned a specific nurse. In addition, every nurse has one or more patients. This makes ICU nurse/patient assignment surjective. Since this is a function and not a relation, two patients may have the same nurse **(e.g., B and D both point to 3),** but two nurses may NOT have the same patient (**e.g.,** **B cannot point to 1 and 3**). Another example of a surjection would be assigning teams to projects. If every project must be assigned at least one team, and each team may have one, and only one, project then project/team assignment is a surjection.

**Bijections**

The third type of function arises from the combination of the first two. Functions that are injective and surjective are referred to as *bijective *(1). They also called *one-to-one correspondences*. Bijections are special for a few reasons. First, each domain element is paired with one, and only one, co-domain element. Second, the reverse is true as well—each co-domain element is paired with one, and only one, domain element. Third, bijections have inverses, which mean they can be undone. Practically this means that if you arbitrarily select a co-domain element, you can determine with certainty its domain element partner. Figure 5 illustrates a bijection; notice how the arrows are bi-directional.

**Figure 5**

*One-to-one correspondence practical example*

A great example of a one-to-one correspondence is the match between a patient and his/her medical record number. Every patient must have a MR#, and no two patients may have the same number. Primary keys for entities in relational databases are another example of a bijection.

**Functions and relations as analytical tools** **and programming aids**

While relations and functions are abstract, the fact that they offer standard ways of linking one set with another makes them invaluable as analytical and programming tools. Though it may not seem obvious on causal review, clinical care deals with sets. Clinical care is really the interaction between the set ** Patients **and any number of other sets: medications, diseases, symptoms, providers, hospitals, terminologies, insurers, and many others. When looking at these interactions, it can be quite useful to know which are relations and which are functions. Why? Because relations and functions are well-defined programming entities and both transfer quite readily to software development. Knowing that the sets

**and**

*SSNs***are linked by a bijective function helps when designing software and databases. Of course, one could design software without knowing about bijections, but knowing about them means less time spent reinventing the wheel.**

*People***Function composition**

Functions may be participate in compositions. That is, the output (range) of one function may be used as the input (domain) for another. This view allows one to think of a series of functions as leading to a final output. Consider a workflow as a series of functions. A patient registers, has vitals taken, is assigned a room, sees a provider, and checks out. Each of these processes could be seen as a function where the input is a patient in a specific state and the output is a patient in a different state**: registered ->vitals_complete-> in_exam_room->with_provider->checked_out**. From a software development standpoint, this makes it easier to move from analysis to design to code (at least for me).

In summary, functions are more than just formulae where one plugs in a few numbers and out pops another number; they are fundamentally a way of linking two sets—any two sets.

The final post is this series will look at the basics of graph theory. See you then…

1. Epp SS. *Discrete Mathematics with Application, **Fourth Edition.* Belmont, CA: Thomson-Brooks/Cole; 2010