# FA18:Lecture 7 jectivity

We define 'jectivity and related it to the existence of inverses.

- Last semester: Lecture 6 Function Properties and Lecture 7 Inverses
- File:Fa18-lec07-board.pdf

## Contents

# Function Properties

Some functions behave more "nicely" than others. One set of properties that functions can have is their 'jectivity, which we define here. We'll see below that these properties are closely related to inverse functions.

## Injectivity

one-to-one is a synonym for injective.

A good way of thinking about injectivity is that the domain is "injected" into the codomain without being "compressed". In other words, no two (different) inputs go to the same output.

The following function is **not** injective:

because but ).

and are both 2 (## Surjectivity

**Surjective**

In short, every element of the codomain gets "hit". (Mnemonic device: the prefix sur- means "over" or "above", as in "surcharge" or "surname", etc. So each element of the codomain has at least one preimage (and maybe more)).

The following function is **not** surjective:

because there is no with .

## Bijectivity

A bijection (or bijective function) gives a way of matching every element of one set to every element of another set. Formally:

# Relationship between inverses and 'jectivity

You may have noticed a pattern in the examples above. The injective functions seem to have left inverses, and the surjective functions have right inverses; two-sided inverses seem to be connected with bijectivity. Indeed, there is a connection between 'jectivity and inverses, as we will prove in the next lecture:

- injections have left inverses, and functions with left inverses are injective
- surjections have right inverses, and functions with right inverses are surjective
- bijections have two-sided inverses, and functions with two-sided inverses are bijective

We did part of the proof of the first part of the first claim. You can see the first part of all three claims by clicking on them; the second parts are left as an exercise.

## example: file formats

Suppose you are writing a program to convert data from one file format to another (or a function to convert one data structure to another). Such a program describes a function . You can think of as describing the original file format, and as describing the new file format.

It is sensible to check that bijection. The reason a bijection is desirable is because it has a two-sided inverse which can be used to convert the file back into the original format.

is aIf injective, then it is "lossy": some information about the original file is lost.

is notIf surjective, then the resulting file format has more data than the original. Further edits to the data in the format (in other words, functions from to ) may prevent the object from being mapped back to the original file format.

is not## example: user operations

Many user interfaces can be thought of as a collection of functions that transform a document into another document. For example, let be the set of all plain text files. Pressing the 'x' key in a text editor causes an 'x' to be inserted; you can think of this as applying a function that takes the document without the 'x' and outputs the document with the 'x'.

If you want to provide an undo/redo capability, then the functions should be bijections. If they are, then their two-sided inverses give the undo operations.

Sometimes you can make a function into a bijection by adding an "undo log": by expanding the set you can keep enough history to implement an undo function.

## example: solvable equations

One way of understanding surjections and right inverses is as the existence of a solution to an equation. For example, the function given by is not surjective. This is reflected in the fact that you cannot solve the equation for an arbitrary ; indeed, there is no with .

If we restrict the codomain of so that the function becomes surjective (i.e. let ), then there is a right inverse (namely the function).