From c73480483c5c5b5d28f3a18ae07a5477f3868224 Mon Sep 17 00:00:00 2001 From: Boris Marinov Date: Sun, 31 Oct 2021 02:21:39 +0300 Subject: [PATCH] stuff --- _chapters/01_set.md | 42 +- _chapters/02_category.md | 4 +- _chapters/03_monoid.md | 18 + _chapters/04_order.md | 81 +- _chapters/04_order/preorder_map.svg | 264 +++++ .../04_order/preorder_map_equivalence.svg | 286 ++++++ _chapters/04_order/preorder_sports.svg | 627 ++++++------ _chapters/04_order/preorder_state_machine.svg | 371 +++++++ _chapters/06_functors.md | 264 +++-- _chapters/06_functors/category_sets.svg | 948 ++++++++++++++++++ _chapters/06_functors/finite_categories.svg | 348 +++++++ _chapters/06_functors/finite_one.svg | 72 ++ _chapters/06_functors/finite_three.svg | 169 ++++ _chapters/06_functors/finite_two.svg | 112 +++ _chapters/06_functors/finite_zero.svg | 51 + .../06_functors/preorder_map_functor.svg | 475 +++++++++ _chapters/07_natural_transformations.md | 88 +- .../natural_functors.svg | 297 ++++++ .../natural_functors_objects.svg | 332 ++++++ .../natural_transformation.svg | 372 +++++++ 20 files changed, 4782 insertions(+), 439 deletions(-) create mode 100644 _chapters/04_order/preorder_map.svg create mode 100644 _chapters/04_order/preorder_map_equivalence.svg create mode 100644 _chapters/04_order/preorder_state_machine.svg create mode 100644 _chapters/06_functors/category_sets.svg create mode 100644 _chapters/06_functors/finite_categories.svg create mode 100644 _chapters/06_functors/finite_one.svg create mode 100644 _chapters/06_functors/finite_three.svg create mode 100644 _chapters/06_functors/finite_two.svg create mode 100644 _chapters/06_functors/finite_zero.svg create mode 100644 _chapters/06_functors/preorder_map_functor.svg create mode 100644 _chapters/07_natural_transformations/natural_functors.svg create mode 100644 _chapters/07_natural_transformations/natural_functors_objects.svg create mode 100644 _chapters/07_natural_transformations/natural_transformation.svg diff --git a/_chapters/01_set.md b/_chapters/01_set.md index 68c6218..079a815 100644 --- a/_chapters/01_set.md +++ b/_chapters/01_set.md @@ -6,9 +6,9 @@ title: Sets Sets === -We will begin our inquiry by looking at the basic theory of sets. You will understand why shortly. For now, it suffices to say that sets are an example of a category. +Let's begin our inquiry by looking at the basic theory of sets. You will understand why shortly. For now, it suffices to say that sets are an example of a category. -Preface: What is an Abstract Theory +What is an Abstract Theory === > Instead of asking what can be defined and deduced from what is assumed to begin with, we ask instead what more general ideas and principles can be found, in terms of which what was our starting-point can be defined or deduced. @@ -75,38 +75,40 @@ We will encounter the empty set again. Functions === -A function is a relationship between two sets which matches each element of one set, called the *domain* of the function, with exactly one element from another set, called the converse domain, or the *codomain* of the function. +A function is a relationship between two sets which matches each element of one set, called the *input set* of the function, with exactly one element from another set, called the **output set** of the function. + +Some alternative way to call these two sets: *domain* and *codomain*, *source* and *target*. In programming) *argument* and *return value*. In logic they correspond to *premises* and *conclusion*, but it is all the same thing. > By function I mean the unity of the act of arranging various representations under one common representation. > Immanuel Kant, from Critique of Pure Reason -Here is a function, **f** which maps each ball from the set **R** to the ball with the opposite colour in another set **G** ( in mathematics a function's name is often accompanied by the names of its domain and codomain, like this: **f: R → G**) +Here is a function, **f** which maps each ball from the set **R** to the ball with the opposite colour in another set **G** (in mathematics a function's name is often accompanied by the names of its input and output sets, like this: **f: R → G**) ![Opposite colors](function_one_one.svg) -This is probably one of the simpler types of functions there exists. That is because it encodes a *one-to-one relationship* between the sets - *one* element from the domain is connected to exactly *one* element from the codomain (and the other way around). +This is probably one of the simpler types of functions there exists. That is because it encodes a *one-to-one relationship* between the sets - *one* element from the input is connected to exactly *one* element from the output (and the other way around). -But functions can also express relationships of the type *many-to-one*, where *many* elements from the domain might be connected to *one* element from the codomain (but not the other way around). +But functions can also express relationships of the type *many-to-one*, where *many* elements from the input might be connected to *one* element from the output (but not the other way around). -For example, a function can express a relationship in which several elements from the domain relate to the same element of the codomain. +For example, a function can express a relationship in which several elements from the input set relate to the same element of the output set. ![Function from a bigger set to a smaller one](function_big_small.svg) -It can also express relationships in which some elements from the codomain do not play a part. +It can also express relationships in which some elements from the output set do not play a part. ![Function from a smaller set to a bigger one](function_small_big.svg) -One thing that you cannot have is a domain element which is not mapped to anything, or which is mapped to more than one codomain element. That would mean the relationship expressed by the function will be *many-to-many*, and, as we said in the beginning, functions only model many-to-one relationships. There is a reason for that "design decision", and we will arrive at it shortly. +One thing that you cannot have is a input element which is not mapped to anything, or which is mapped to more than one output element. That would mean the relationship expressed by the function will be *many-to-many*, and, as we said in the beginning, functions only model many-to-one relationships. There is a reason for that "design decision", and we will arrive at it shortly. Sets and functions can express relationships between all kinds of objects, and even people. Every question that you ask can most probably be expressed as a function. -The question "How far are we from New York?" is a function with a domain the set of places in the world and a codomain, consisting of the set of all positive numbers +The question "How far are we from New York?" is a function with set of all places in the world as input set and an output set consisting of the set of all positive numbers. -**Question:** Some people might say that the codomain of this function is bigger than it should be. How would you refine it? +**Question:** Some people might say that the output of this function is bigger than it should be. How would you refine it? -The question "Who is my father?" is a function whose domain is the set of all people in the world. +The question "Who is my father?" is a function whose input is the set of all people in the world. -**Question:** What is the codomain of this function? +**Question:** What is the output of this function? Note that the question "Who is my child?" is *NOT* a straightforward function, because a person can have no children, or can have multiple children. We will learn to represent such questions as functions later. @@ -140,7 +142,7 @@ There is a unique function from the empty set to any other set. Note that this statement is also a result from the one saying that there is a function between a Subset and a Set, and the one that says that the empty set is a subset of any other set. -**Question:** What about the other way around. Are there functions with the empty set as a codomain as opposed to a domain? +**Question:** What about the other way around. Are there functions with the empty set as an output as opposed to its input? Functions and Singleton Sets --- @@ -170,12 +172,12 @@ For example, squaring a number is a function from the set of real numbers to the I will use the occasion to reiterate some of the more important characteristics of functions: -- All numbers from the codomain have (or should have) two arrows pointing at them (one for the positive square root and one for the negative one), and that is OK. +- All numbers from the output have (or should have) two arrows pointing at them (one for the positive square root and one for the negative one), and that is OK. -- Zero from the domain is connected to itself in the codomain, and that is OK. -- Some numbers aren't the square of any other number. That is also OK. +- Zero from the input set is connected to itself in the output set - that is permitted. +- Some numbers aren't the square of any other number - that is also permitted. -Overall everything is OK, as long as you can always provide exactly one result (also known as *The result™*) per value, and in mathematics almost always do. Actually, math is designed in a way so its operations are valid functions: +Overall everything is permitted, as long as you can always provide exactly one result (also known as *The result™*) per value, and in mathematics almost always do. Actually, math is designed in a way so its operations are valid functions: > Every generalisation of number has first presented itself as needed for some simple problem: negative numbers were needed in order that subtraction might be always possible, since otherwise a − b would be meaningless if a were less than b; fractions were needed in order that division might be always possible; and complex numbers are needed in order that extraction of roots and solution of equations may be always possible. > Bertrand Russell, from Introduction to Mathematical Philosophy @@ -245,7 +247,7 @@ Hm, something is not quite right with this diagram as well - Because of the new Functional Composition === -Let's assume that we have two functions, **g: Y → P** and **f: P → G** and the codomain of the first one is the same set as the domain of the second. +Let's assume that we have two functions, **g: Y → P** and **f: P → G** and the output of the first one is the same set as the input set of the second one. ![Matching functions](functions_matching.svg) @@ -290,7 +292,7 @@ If we have a function **g: P → Y** from set **P** to set **Y**, then for every ![Functional composition connect](morphism_general.svg) -For example, if we again take the relationship between a person and his father as a function, with the set of all people in the world as a domain, and the set of all people that have children as its codomain, then each person whom my father is related to is automatically my relative - my father's father is my grandfather, my father's wife is my mother and so on. +For example, if we again take the relationship between a person and his father as a function, with the set of all people in the world as an input, and the set of all people that have children as its output, then each person whom my father is related to is automatically my relative - my father's father is my grandfather, my father's wife is my mother and so on. Isomorphisms === diff --git a/_chapters/02_category.md b/_chapters/02_category.md index 9ff56e7..a32da4d 100644 --- a/_chapters/02_category.md +++ b/_chapters/02_category.md @@ -220,7 +220,7 @@ Wait a minute - we said that all sets form a category, but at the same time any This particular analogy (a set as a category with no morphisms) is, however, not very useful. Not because it's in any way incorrect, but because category theory is *all about the morphisms*. If in set theory arrows are nothing but a connection between a source and a destination, in category theory it's the *objects* that are nothing but a source and destination for the arrows that connect them to other objects. This is why, in the diagram above, the arrows, and not the objects, are coloured: the category of sets should really be called the category of set functions. -Speaking of which, note that objects in a category can be connected by multiple arrows and that arrows having the same domain and codomain does not in any way make them equivalent. +Speaking of which, note that objects in a category can be connected by multiple arrows and that arrows having the same input and output sets does not in any way make them equivalent (it does not actually mean that they would produce the same output value). ![Two objects connected with multiple arrows](arrows.svg) @@ -287,7 +287,7 @@ Ancient mathematicians invented the number zero that, although useless by itself ![The identity morphism (but can also be any other morphism)](identity.svg) -It's important to mark this morphism, because there can be (let's add the very important (and also very boring) reminder) many morphisms that go from one object to the same object, many of which actually do stuff. For example, mathematics deals with a multitude of functions that have the set of numbers as domain and codomain, such as **negate**, **square**, **add one**, and are not at all the identity morphism. +It's important to mark this morphism, because there can be (let's add the very important (and also very boring) reminder) many morphisms that go from one object to the same object, many of which actually do stuff. For example, mathematics deals with a multitude of functions that have the set of numbers as input and output, such as **negate**, **square**, **add one**, and are not at all the identity morphism. **Question:** What is the identity morphism in the category of sets? diff --git a/_chapters/03_monoid.md b/_chapters/03_monoid.md index 18b33de..1b1bd9a 100644 --- a/_chapters/03_monoid.md +++ b/_chapters/03_monoid.md @@ -100,6 +100,7 @@ This touches a programming concept which is very popular in category-theory insp In general, we use monoids and related structures as a way to model how a set of (associative) actions that are performed on a given object (or objects) alter it's state. We can do that, provided that the object's state is determined solely by the actions that are performed on it, this allows us to leave the object out of the equation and concentrate on how the actions are combined. And as per usual, the actions (and elements) can be anything, from mixing colors in paint, or adding a quantities to a given set of things etc. @@ -280,6 +281,11 @@ Those two operations and their composite results in a group called **Dih3** that **Question:** Besides having two main actions, what is the defining factor that makes this and any other group non-abelian? + + Monoids as Categories === @@ -319,3 +325,15 @@ The intuition behind this representation is encompassed by the requirement of ** |Closure | | X | X | When we view a monoid as a category, this law says that all morphisms in the category should be from one object to itself - a monoid, any monoid, can be seen as a category with one object. + + + diff --git a/_chapters/04_order.md b/_chapters/04_order.md index 56a6f40..e1e086b 100644 --- a/_chapters/04_order.md +++ b/_chapters/04_order.md @@ -197,14 +197,12 @@ In terms of arrows, the rule means that if you add an arrow to a point, the poin This arrangement allows us to compare any two points by just seeing which one is above the other e.g. to spot the *join* of two elements, you just have to identify the ones they connect to and see which one is lowest. -Examples of partial orders -=== - -We all know many examples of total orders (any form of chart or ranking is a total order), but there are probably not so many obvious examples of partial orders that we can think of off the top of our head. So let's see some. In addition to providing a little context, this will help us understand joins and see why are they significant. Color order --- +We all know many examples of total orders (any form of chart or ranking is a total order), but there are probably not so many obvious examples of partial orders that we can think of off the top of our head. So let's see some. In addition to providing a little context, this will help us understand joins and see why are they significant. + To stay true to our form, let's revisit our color-mixing monoid and create a color-mixing partial order in which all colors point to colors that contain them. ![A color mixing poset](color_mixing_poset.svg) @@ -314,6 +312,11 @@ The implications of the tendency to use trees to model everything as opposed to > In simplicity of structure the tree is comparable to the compulsive desire for neatness and order that insists the candlesticks on a mantelpiece be perfectly straight and perfectly symmetrical about the center. The semilattice, by comparison, is the structure of a complex fabric; it is the structure of living things, of great paintings and symphonies. + + Preorder === @@ -342,18 +345,69 @@ And as a result of that, all "circle" relationships (e.g. where you have a weake All of that structure arises naturally from the simple law of transitivity. -![Transitivity](transitivity.svg) +Maps as preorders +--- +We use roadmaps all the time, and so most people do not realize that they are actually diagrams. More specifically, some of them are preorders - the objects represent intercections, the relations represent are the roads. + +![A map as a preorder](preorder_map.svg) + +Reflexivity reflects reflects the fact that if you have a route allowing you to get from point **A** to point **B** and one that allows you to go from **B** to **C**, then you can go from **A** to **C** as well. Two-way roads may be represented by two arrows that form an isomorphism between objects. Intercections such that you can get from one to the other form equivalence classes (ideally all intercections would be in one equivalence class). + +![preorder](preorder_map_equivalence.svg) + +However, maps that contain more than one road (and even more than one *route*) connecting two intercections, cannot be represented using preorders. For that we would need categories (don't worry, we are almost there.) + + +State machines as preorders +--- + +Let's now reformat the preorder that we used in the previous two examples, as Hasse diagram that goes from left to right. Now, it (hopefully) doesn't look so much like a hierarchy, nor like map, but like a description of a process (which if you think about it is also a map, just one that is temporal, rather than spatial.) This is actually a very good way to describe a computation model known as *finite state machine*. + +![A state machine as a preorder](preorder_state_machine.svg) + +A specification of a finite state machine consists of a set of states that the machine can have, which, as the name suggest must be finite (so they can be mapped to diagrams, like finite categories.) and a bunch of transition functions that specify which state do we transition to (often expressed as tables.) + +But as we saw, a finite state machine is similar to a preorder with a greatest and least object, in which the relations between the objects are represented by functions. + +Finite state machines are used in organization planning e.g. imagine a process where an item gets manifactured, gets checked by a quality control person, who, if they find some defficiencies, pass it to the necessary repairing departments and then they check it again and send it for shipping - this process can be modelled by the above diagram. + +They are used in software too. Orders as categories === -Now let's look at transitivity law again, but from a different perspective. What it tells us that if we have two pairs of relationship **a ≤ b** and **b ≤ c**, then we automatically have a third one **a ≤ c**. In other words, it tells us that the **≤** relationship composes i.e. if we view the "bigger than" relationship as a morphism we would see that it fits the categorical definition of composition. +We saw that preorders are a powerful concept, so let's take a deeper look at the law that governs them - the transitivity law. What this law tells us that if we have two pairs of relationship **a ≤ b** and **b ≤ c**, then we automatically have a third one **a ≤ c**. + +![Transitivity](transitivity.svg) + +In other words, the transitivity law tells us that the **≤** relationship composes i.e. if we view the "bigger than" relationship as a morphism we would see that it fits the categorical definition of composition. ![Transitivity as functional composition](transitivity_composition.svg) @@ -363,11 +417,11 @@ What about that other law that was required in order to be a category - the iden ![Reflexivity](reflexivity.svg) -So it's official - preorders are categories (sounds kinda obvious, especially after we also saw that orders can be reduced to sets and functions (the inclusion order) and sets and functions form a category in their own right). +So it's official - preorders are categories (sounds kinda obvious, especially after we also saw that orders can be reduced to sets and functions using the inclusion order, and sets and functions form a category in their own right.) -And since partial orders and total orders are preorders too (as they obey those two laws), they are categories as well. +And since partial orders and total orders obey those two laws, they are preorders too. And also categories as well. -Starting to compare the categories of preorders, and partial and linear orders to other categories, like the (quintessential) category of sets, immediately sets them apart. In other categories there can be *many different morphisms (arrows)* between two objects and in orders can have *at most one morphism*. That is, for two objects **a** **b** we either have **a ≤ b** or we do not. +When we compare the categories of orders to other categories, like the quintessential category of sets we see one thing that immediately sets them apart: in other categories there can be *many different morphisms (arrows)* between two objects and in orders can have *at most one morphism*. That is, for two objects **a** **b** we either have **a ≤ b** or we do not. ![Orders compared to other categories](arrows_one_arrow.svg) @@ -375,12 +429,12 @@ That is in the contrast with the category of sets where there are potentially in ![Orders compared to other categories](order_category.svg) -Note that although two objects in an order might be directly connected by just one arrow, they might still be be indirectly connected by more than one arrow. So when we define an order in categorical way it's crucial to specify that *these ways are equivalent* i.e. that all diagrams that show orders commute. +Note that although two objects in an order might be directly connected by just one arrow, they might still be be *indirectly* connected by more than one arrow. So when we define an order in categorical way it's crucial to specify that *these ways are equivalent* i.e. that all diagrams that show orders commute. Products and sums --- -While we are rehashing diagrams from the previous chapters, let's look at the diagram defining the *coproduct* of two objects in a category. +While we are rehashing diagrams from the previous chapters, let's look at the diagram defining the *coproduct* of two objects in a category, from chapter 2. ![Joins as coproduct](coproduct_join.svg) @@ -406,4 +460,3 @@ In the realm of orders, we say that **G** is the *join* of objects **Y** and **B ![Joins as coproduct](coproduct_join_morphisms.svg) We can see that the two definitions and their diagrams are the same. So, speaking in category theoretic terms, we can say that the *categorical coproduct* in the category of orders is the *join* operation. - diff --git a/_chapters/04_order/preorder_map.svg b/_chapters/04_order/preorder_map.svg new file mode 100644 index 0000000..8a5cbb4 --- /dev/null +++ b/_chapters/04_order/preorder_map.svg @@ -0,0 +1,264 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/04_order/preorder_map_equivalence.svg b/_chapters/04_order/preorder_map_equivalence.svg new file mode 100644 index 0000000..4c420c9 --- /dev/null +++ b/_chapters/04_order/preorder_map_equivalence.svg @@ -0,0 +1,286 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/04_order/preorder_sports.svg b/_chapters/04_order/preorder_sports.svg index d7c109f..4e1ee15 100644 --- a/_chapters/04_order/preorder_sports.svg +++ b/_chapters/04_order/preorder_sports.svg @@ -11,7 +11,7 @@ version="1.1" id="svg3397" sodipodi:docname="preorder_sports.svg" - inkscape:version="1.0.1 (0767f8302a, 2020-10-17)"> + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)"> @@ -20,7 +20,7 @@ image/svg+xml - + @@ -39,352 +39,311 @@ inkscape:window-height="1376" id="namedview3399" showgrid="false" - inkscape:zoom="2" - inkscape:cx="350.91475" - inkscape:cy="3.7406242" + inkscape:zoom="2.7965438" + inkscape:cx="290.73609" + inkscape:cy="93.670367" inkscape:window-x="0" inkscape:window-y="27" inkscape:window-maximized="1" - inkscape:current-layer="g2760-0" + inkscape:current-layer="svg3397" inkscape:document-rotation="0" showguides="true" inkscape:guide-bbox="true"> + id="guide3917" + inkscape:locked="false" /> - - - - - - - - - - M - - - - - - - G - - - - - - F - - - - - - - - - - - - - - - - - - D - - - - - - - O - - - - - - - - - - - - - - - - - + inkscape:transform-center-y="-1.2312622" + inkscape:transform-center-x="1.7679659" + transform="matrix(-0.14942153,-0.15015823,-0.19429302,0.22334457,-23.432194,58.695738)" + id="g1482-7-0-7-0-1" + style="display:inline;fill:#dddddd;stroke:#838383;stroke-width:6.38899994;stroke-miterlimit:10"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/04_order/preorder_state_machine.svg b/_chapters/04_order/preorder_state_machine.svg new file mode 100644 index 0000000..29065ff --- /dev/null +++ b/_chapters/04_order/preorder_state_machine.svg @@ -0,0 +1,371 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/06_functors.md b/_chapters/06_functors.md index c9c6226..db55288 100644 --- a/_chapters/06_functors.md +++ b/_chapters/06_functors.md @@ -6,17 +6,19 @@ title: Functors Functors === -This chapter we will change the tactic a bit (as I am sure you are a bit tired of jumping through different subjects) and we will examine some purely categorical concepts, using the structures that we saw so far as context. We will also generalize some of the concepts that we saw in these structures so they are valid for all categories. +From this chapter on, we will change the tactic a bit (as I am sure you are a bit tired of jumping through different subjects) and, we will dive at full throtle into the world of categories, using the structures that we examined so far as context. This will allow us to generalize some of the concepts that we saw in these structures so they are valid for all categories. Categories we saw so far === -So far we saw many different categories and category types: +So far, we saw many different categories and category types. Let's review them before we dive in to functors. -Set +The category of sets --- -We saw the mother of all categories - *the category of sets* and we learned that there are many other categories that are based on it, such as the category of types in a programming languages. +We began (in chapters 1 and 2) by reviewing the mother of all categories - *the category of sets* which is not only the prototype of a category, but it contains many other categories, such as the category of types in a programming languages. + +![The category of sets](category_sets.svg) Category types --- @@ -28,25 +30,39 @@ We learned that they are special types of categories, like categories that have Other categories --- -We also defined a lot of *categories based on different things*, like the ones based on logics/programming languages, but also less "serious ones", as for example the color-mixing one. +We also defined a lot of *categories based on different things*, like the ones based on logics/programming languages, but also less "serious ones", as for example the color-mixing one. ![Category of colors](category_color_mixing.svg) Finite categories --- -And most importantly, we saw some categories that are *completely made up and have no value whatsoever*, such as my made-up soccer hierarchy. We call those *finite categories*. - -Although few finite categories are useful by themselves, *the concept of finite categories* is very important - we can draw any combination of points and arrows and call it a category, in the same way that we can construct a set out of everything. +And most importantly, we saw some categories that are *completely made up and have no value whatsoever*, such as my made-up soccer hierarchy. We call those *finite categories*. Although few the finite categories are useful by themselves, the idea of finite categories is important - we can draw any combination of points and arrows and call it a category, in the same way that we can construct a set out of every combination of objects. ![Finite categories](finite_categories.svg) -For future reference, let's see some basic finite categories. +For future reference, let's see some basic finite categories. The simplest category is **0** (enjoy the minimalism of this diagram.) + +![The finite category 0](finite_zero.svg) + +The next simplest category is **1** - it is comprised of one object no morphism besides its identity morphism (as usual, we don't take note of the identity morphisms unless they are rellevant.) + +![the finite category 1](finite_one.svg) + +If we increment the number of objects to two, we see a couple of more interesting categories, like for example the category **2** containing two objects and one morphism. + +![the finite category 2](finite_two.svg) + +**Task:** There are just two more categories that have 2 objects and at most one morphism between two objects, draw them. + +And finally the category **3** has 3 objects and also 3 morphisms (one of which is the composition of the other two.) + +![the finite category 3](finite_three.svg) Categorical Isomorphisms === -Many of the categories we saw have similarities between one another, as for example both the color-mixing order and categories that represent logic have greatest and least objects. To pinpoint such similarities and understand what they mean, we specify formal ways to connect categories to one another. In chapter 1 we talked about set isomorphisms, which establish an equivalence between two sets. If you remember a set isomorphism is a *two-way function* between two sets or, alternatively, two "twin" functions each of which equals identity when composed with the other. +Many of the categories we saw have similarities between one another, as for example both the color-mixing order and categories that represent logic have greatest and least objects. To pinpoint such similarities and understand what they mean, we specify formal ways to connect categories to one another. In chapter 1 we talked about set isomorphisms, which establish an equivalence between sets. If you remember, a set isomorphism is a *two-way function* between two sets or, alternatively it can be seen as two "twin" functions each of which equals identity when composed with the other. ![Set isomorphism](set_isomorphism.svg) @@ -54,13 +70,15 @@ Then, in chapter 4, we mentioned order isomorphisms and saw that they are the sa ![Order isomorphism](order_isomorphism.svg) -We can extend this definition to work for categories as well. However, unlike orders, categories can have more than one morphism between two objects, so the definition is a little more complex. It is the following: given two categories, an isomorphism between them is an invertible function between the underlying sets of objects, *and* an invertible function between the morphisms that connect them, which maps each morphism to a morphism with the same signature. If you haven't seen the word, the "signature" of a function is just its input and output, so two functions have the same signature if they have the same input and output. +We can extend this definition to work for categories as well. However, unlike orders, categories can have more than one morphism between two objects, so the definition is a little more complex. + +It is the following: given two categories, an isomorphism between them is an invertible function between the underlying sets of objects, *and* an invertible function between the morphisms that connect them, which maps each morphism to a morphism with the same signature (the "signature" of a function is just its input and output, so two functions have the same signature if they have the same input and output sets). ![Category isomorphism](category_isomorphism.svg) -Although a little more complex, this definition is the same as the one we have for orders - it is just that with categories we can have more than one morphism between two objects and so we need to explicitly specify which one corresponds to which, while in order theory we only need to verify that the corresponding morphism actually exist (for orders is done by the *order-preserving* condition.) +Although a little more complex, this definition is the same as the one we have for orders - it is just that when dealing with categories, we have to account for the fact that we can have more than one morphism between two objects and so we need to explicitly specify which one corresponds to which, while in order theory we only need to verify that the corresponding morphism actually exist (for orders is done by the *order-preserving* condition.) So those are categorical isomorphisms. -So those are categorical isomorphisms. But isomorphisms are actually very rare. The only one that comes to mind is the Curry-Howard-Lambek isomorphism from the last chapter. If two categories are isomorphic they basically contain the same data and it would be more accurate to refer to them as different representations of the same category, then as separate categories. +However, categorical isomorphisms are actually pretty rare - the only one that comes to mind is the Curry-Howard-Lambek isomorphism from the last chapter. If two categories are isomorphic, they basically contain the same data and it would be more accurate to refer to them as different *representations* of the same category than as separate categories. + +The other functor law trivial, it just says that the one and only identity object of the input group (which corresponds to the identity morphism of its one and only object) should be mapped to the one and only identity object of the output group. + + + +Functors in orders === -I got you this time, didn't I? You probably thought that I won't introduce another category in this chapter, but this is exactly what I am going to do. And another surprise is that the new category won't be the category of functors (don't worry, we will introduce that in the next chapter.) +And now let's talk about one concept that is completely unrelated to functors, nudge-nudge (I know you are tired of this, but hey, bad jokes are better than no jokes at all.) In the theory of orders we have functions between orders which is unsurprising, as orders, like monoids/groups, are based on sets. And one very interesting type of order function which has applications in calculus and analysis is a *monotonic function* (also called *monotone map*). This is a function between two orders that preserves the order of the elements. So a function **F** is monotonic when for every **a** and **b** in the input order, if **a ≤ b** then **F(a) ≤ F(b)**. -Instead, we will examine the category of small categories (we say *small* because otherwise the category will include itself and it's going to be Russell's paradox all over again.) This category has all the categories that we saw so far as objects and functors are its morphisms. +For example, the function that maps the current time to the distance travelled by some object is monotonoc because the distance travelled increases (or stays the same) as time increases. -**Task:** go through the functor definition and see how you can make functors compose. +![A monotonic function](monotonic_function.svg) + +If we plot this or any other monotonic function on a line graph, we see that it goes just one direction. + +![A monotonic function, represented as a line-graph](monotonic_function_line_graph.svg) + +Now we are about to prove that monotonic functions are functors too, ready? + +Object mapping +--- + +The object mapping component of functors between monoids is trivial. Here it is the reverse - the object mapping is the central component of the functor. + +Morphism mapping +--- + +In orders, there can be just one morphism between given two objects, and so morphism-mapping component of functors between them is trivial. Given two objects from the input order, if there is a morphism between them we map that morphism to the morphism between their corresponding objects in the output order. The fact that the monotonic function respects the order of the elements, ensures that the latter morphism exists. + +Functor laws +--- + +It is not hard to prove that monotone maps obey the functor laws - monotone maps match all identity morphisms with one another because in orders identities are the only morphisms that go between a given object and itself. And they preserve composition for the same reason. + +Here is the full proof: One thing we know about monotonic maps is that they preserve the order of the elements, which means (in category-theoretic terms) that if a morphism with a signature **a ➞ b** in the input order exists, then the morphism **F(a) ➞ F(b)** in the output order would exist too. Let's denote these two morphisms **f** and **F(f)**. + +Suppose that there exist another morphism **b ➞ c** in the input. Then by the same logic **F(b) ➞ F(c)** would exist as well. Let's denote these morphisms **g** and **F(g)**. + +If we compose the two morphisms in the output order, we get a morphism **F(g)•F(f) :: F(a) ➞ F(c)**. + +And if we compose the two morphisms in the input order, we get a morphism **g•f :: a ➞ c**. And from it, we can get the corresponding morphism in the output category - **F(g•f) :: F(a) ➞ F(c)**. + +But both morphisms **F(g•f)** and **F(g)•F(f)** have the same signature - **F(a) ➞ F(c)** and for orders we know that there can exist only one morphism with a given signature. So **F(g•f) = F(g)•F(f)**. + +In this case the compositions +But this means that the composition of these two pairs of morphisms should exist as well, so + + +**F(g•f) = F(g)•F(f)**. + + + +Free and Forgetful Functors +--- + +Some other functors +=== + +Before we continue, we will review the functor-related concepts that we saw so far, as well as some that we will see later on. + + + +Diagram +--- + +As we saw, a diagram, can be represented as functor from a finite category, called an *index* category (or a *map* as we dubbed it earlier) to some other category. + +Homomorphism functor +--- + +For any category, we can generate the set of all morphisms that have a specific type signature + +![Homomorphism set](homomorphism_set.svg) + +Between those two categories, there is a functor, calle the homomorphism functor, between the objects and the morphism sets, where the the morphisms play the role of objects. Again, the morphisms are objects. + +This category will have morphisms for object and morphism composition. For example, if we take the color-mixing category, the functor **Hom(B,_)** (the Black ball) would look like this. + +![Homomorphism functor](homomorphism_functor.svg) + +Endofunctor +--- + +When programming, we are working in just one category - the category of types in the language that we are working with, so all functors that + +Identity functor +--- + +There is one particular endofuctor that will probably look familiar to you - it is the identity functor - one which maps each object and morphism to itself. + +The category of small categories +=== + +Ha, I got you this time (or at least I hope I did). You probably thought that I won't introduce another category in this chapter, but this is exactly what I am going to do. And another surprise is that the new category won't be the category of functors (don't worry, we will introduce that in the next chapter.) Instead, we will examine the category of (small) categories. + +This category has all the categories that we saw so far as objects and functors are its morphisms. + +**Task:** Go through the functor definition and see how you can make functors compose. **Question:** What are the initial and terminal object of the category of small categories. @@ -241,42 +393,26 @@ There isn't much to say about this category, it is just a good exercise to try t [The category of categories](category_of_categories) -Recursiveness of Cat +The ghost of Russell's paradox --- -But how can one and the same object appear in so many places in different roles? +We say *small* because otherwise the category will include itself and it's going to be Russell's paradox all over again. -Interlude: objects are overrated +Categories all the way down --- ->The world is the collection of facts, not of things. -Ludwig Wittgenstein +The recursive nature of category theory might leave some of you confused: we started by saying that categories are composed of objects and morphisms, but now we are saying that there are morphisms between categories as well. Does that mean that categories are an example of categories? -Objects are all around us, both in mathematics and in real life - virtually everything that we see or imagine can be viewed as an object. Because of this, we might be inclined to think that the key to understanding the world is to understand what objects are. And this indeed is an idea shared between many people, you might even say that this is what set theory does. +Yes. Sounds a bit weird on intuitive level (as for example biscuits don't contain other biscuits and houses don't use houses as building material) but it is perfectly legitimate. -However there is another way to look at things. Because what is an object, when viewed by itself? Can we study just one object in isolation? And is there anything left to study about it, once it is detached from its environment? When we think hard about everyday objects we realize that each of them has a specific *function* or functions without which, it would be just a piece of junk, and in many ways it won't be an object at all. And this is even more so for mathematical objects which you cannot even recycle when they are no longer useful - functions, or relations are key. -So instead of thinking about objects which just happen to have some morphisms between them, we might take the opposite view and say that objects are only interesting as domains and codomains of morphisms. -This view is best expressed by category theory and specifically by the notion of universal properties (limits) - as we said in the previous chapter universal properties define an object *up to a unique isomorphism*. This means that if there are two or more objects that are isomorphic to one another and have exactly the same morphisms to all other objects in the category, then these objects are for all intends and purposes equivalent. +category theory does *categorize* (see what I did there) everything as categories, so it is categories all the way down, like for example, every monoid is a category with one just object. -Equivalent categories ---- +But at the same time, monoids can be seen as belonging to one category - the category of monoids - with monoid homomorphisms acting as objects. -In the beginning of the chapter, we were wondering what does it mean for two categories to be equal. And this question is even more interesting in the context of the category of categories. We said that categorical isomorphism is somewhat too rigid to accurately capture the concept. The paragraph above can serve as a good summary as to why this is the case: in isomorphic categories, isomorphic *objects* aren't considered equal (in the way that they are considered equal in universal properties.) for example the following two categories are not isomorphic. +At the same time we have the category of groups, for example, which contains the category of monoids as a subcategory, as all monoids are groups. -![Simple non-isomorphic categories](simple_non_isomorphic_categories.svg) +There may be many more levels of categories within categories. -Being isomorphic means that two structures are completely the same. A map is isomorphic to an area only it represents the area completely, like if there is a arrow for each route and a point for each intersection. - -![Isomorphic categories](isomorphic_categories.svg) - -Suppose, though that there are two intersections that are positioned in such a way that for every road that goes to and from one of them, there is an identical road to the other one (maybe the one of these intercection was meant to replace the other one but it wasn't closed.) Then suppose that you have a map which displays these two intercections as one and the same intercection. - -![Non-isomorphic categories](non_isomorphic_categories.svg) - -Would say that the map is complete? The answer comes down to what would you want to use the map for: if you want the map to accurately represents all the places that exist in the area, then it is not accurate. But if you want the map for practical purposes, if you only need it to make a route, then there is no reason to show two roads that are the same. - -Two categories are isomorphic if there exist an *invertable* functor between them. But they are equivalent if they are connected by two functors that are isomorphic. - -Everything is clear except the definition of functor isomorphism which we will look at in the next chapter. +However that does not mean that we have to cover all of them and think about them at all. It is like the concept of a derivative in calculus - the first derivative of a position of the object gives its *speed*, which is useful, the derivative of speed is also useful - it is **velocity**, but the derivative of velocity and those after it leave us indifferent. We can use the same tactict with our little journey in category theory - stick on the level that make sense for us and not be obsessed with forming picture of the whole thing Because there is no *whole thing* - category theory is an *abstract* theory. That is, it does not seek to represent an actual state of affairs, but to provide a language that you can use to express many different ideas, actual or purely imaginary. So view the category of categories not as a structure, but as a space, where all these concepts live. diff --git a/_chapters/06_functors/category_sets.svg b/_chapters/06_functors/category_sets.svg new file mode 100644 index 0000000..53685c8 --- /dev/null +++ b/_chapters/06_functors/category_sets.svg @@ -0,0 +1,948 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/06_functors/finite_categories.svg b/_chapters/06_functors/finite_categories.svg new file mode 100644 index 0000000..8ae21f4 --- /dev/null +++ b/_chapters/06_functors/finite_categories.svg @@ -0,0 +1,348 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/06_functors/finite_one.svg b/_chapters/06_functors/finite_one.svg new file mode 100644 index 0000000..3afd795 --- /dev/null +++ b/_chapters/06_functors/finite_one.svg @@ -0,0 +1,72 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + diff --git a/_chapters/06_functors/finite_three.svg b/_chapters/06_functors/finite_three.svg new file mode 100644 index 0000000..29dbb20 --- /dev/null +++ b/_chapters/06_functors/finite_three.svg @@ -0,0 +1,169 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/06_functors/finite_two.svg b/_chapters/06_functors/finite_two.svg new file mode 100644 index 0000000..86eed88 --- /dev/null +++ b/_chapters/06_functors/finite_two.svg @@ -0,0 +1,112 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/06_functors/finite_zero.svg b/_chapters/06_functors/finite_zero.svg new file mode 100644 index 0000000..aea5195 --- /dev/null +++ b/_chapters/06_functors/finite_zero.svg @@ -0,0 +1,51 @@ + + + + + + image/svg+xml + + + + + + + + diff --git a/_chapters/06_functors/preorder_map_functor.svg b/_chapters/06_functors/preorder_map_functor.svg new file mode 100644 index 0000000..be4a638 --- /dev/null +++ b/_chapters/06_functors/preorder_map_functor.svg @@ -0,0 +1,475 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/07_natural_transformations.md b/_chapters/07_natural_transformations.md index b964411..0918b36 100644 --- a/_chapters/07_natural_transformations.md +++ b/_chapters/07_natural_transformations.md @@ -1,12 +1,92 @@ Natural transformations and advanced concepts === -We will now continue +In this chapter, we will introduce the central concept of category theory. It is the concept of a morphism between functors or of *natural transformation*. Understanding natural transformations will enable us to define category equality and some other advanced concepts. -What are natural transformations +Natural transformations are really is the heart of category theory - As a matter of fact, category theory was invented with the purpose of studying natural transformations. The importance of natural transformations is not obvious at first, and so before introducing them I like to talk about the body of knowledge that this heart maintains (I am good with methaphors... in principle.) + +Objects are overrated === -Functors don't form a category, but they actually do. +>The world is the collection of facts, not of things. +Ludwig Wittgenstein + +Objects are all around us, both in mathematics and in real life - virtually everything that we see or imagine can be viewed as an object. Because of this, we might be inclined to think that the key to understanding the world is to understand what objects are. And this indeed is an idea shared between many people, you might even say that this is what set theory does. + +However there is another way to look at things. Because what is an object, when viewed by itself? Can we study just one object in isolation? And is there anything left to study about it, once it is detached from its environment? When we think hard about everyday objects we realize that each of them has a specific *function* or functions without which, it would be just a piece of junk, and in many ways it won't be an object at all. And this is even more so for mathematical objects which you cannot even recycle when they are no longer useful - functions, or relations are key. + +So instead of thinking about objects which just happen to have some morphisms between them, we might take the opposite view and say that objects are only interesting as domains and codomains of morphisms. + +This view is best expressed by category theory and specifically by the notion of universal properties (limits) - as we said in the previous chapter universal properties define an object *up to a unique isomorphism*. This means that if there are two or more objects that are isomorphic to one another and have exactly the same morphisms to all other objects in the category, then these objects are for all intends and purposes equivalent. + + +Equivalence of categories +=== + +Are you ready to hear about natural transformations? Actually it is my opinion that you are not, so I would like to continue with something else. Let's ask ourselves the same question that we were poundering at the beginning of the previous chapter - what does it mean for two categories to be equal. + +This question is even more interesting in the context of the category of categories. We said that categorical isomorphism is somewhat too rigid to accurately capture the concept of equality. And the paragraph above can serve as a good summary as to why this is the case: in isomorphic categories, isomorphic *objects* aren't considered equal, for example the following two categories are not isomorphic. + +![Simple non-isomorphic categories](simple_non_isomorphic_categories.svg) + +Being isomorphic means that two structures are completely the same. A map is isomorphic to an area only it represents the area completely, like if there is a arrow for each route and a point for each intersection. + +![Isomorphic categories](isomorphic_categories.svg) + +But that won't always be what we want. In category theory we specify most concepts by treating isomorphis objects as equal - this is valid for all definitions that are based on universal properties. Or to extend the map example, suppose, that there are two intersections that are positioned in such a way that for every road that goes to and from one of them, there is an identical road to the other one (maybe the one of these intercection was meant to replace the other one but it wasn't closed.) Then suppose that you have a map which displays these two intercections as one and the same intercection. + +![Non-isomorphic categories](non_isomorphic_categories.svg) + +Would say that the map is complete? The answer comes down to what would you want to use the map for: if you want the map to accurately represents all the *places* that exist in the area, then it is not accurate. But if you want the map for practical purposes, if you only need it to represents the *routes* in the area, then there is no reason to show two roads that are the same in terms of their input and output. So in other words, when we focus on objects, we would define two categories as equal if there exists an isomorphism between them. But when we focus on morphisms, then it is more apt to define equality with a concept that would only require for the objects to be equal *up to a unique isomorphism*. This concept is called **natural equivalence**. + +Consider these two non-isomorphic, but equivalent categories. + +![Equivalent categories](equivalent_categories.svg) + +There exist only one functor that connects the left one to the right one. + +![Equivalent categories, functor F](equivalent_categories_f.svg) + +There are two functors that connect the right one to the left one, which are equivalent, let's choose one of them. + +![Equivalent categories, functor G](equivalent_categories_g.svg) + +And then if we compose them in one direction we get the same object that we started with, same as if the categories were isomorphic. + +![Equivalent categories, functor G F](equivalent_categories_g_f.svg) + +And if we compose it in the other direction, we don't get the same object (which means that the categories are not isomorphic) but we do get an object that that is isomorphic to the one we started with. This makes the categories equivalent. + +![Equivalent categories, functor G F](equivalent_categories_g_f.svg) + +The definition betwen the two concepts is small but crucial: categories are isomorphic if there exist an *invertable* functor between them. They are equivalent if they are connected by two *isomorphic functors. + +**Task:** Verify that the categories in the previous example are also equivalent. + +We already understand when to categories are equivalent, but to have a proper formal definition of the concept we have to know about functor natural isomorphism, which is a kind of a natural transformation. + +Natural transformations +=== + +The progression that we made so far (morphisms -> functors -> natural transformations) might lure you into thinking that natural transformations are similar to morphisms and functors, they are actually not similar i.e. they are not "recursive". This is due to the fact that both normal morphisms and functors are morphisms between objects (or *1-morphisms*), while natural transformations are morphisms between morphisms (known as *2-morphisms*.) + +But enough talking, let's draw some diagrams. We know that natural transformations are morphisms between functors, so let's draw two functors (I am omitting the arrows between objects for brevity.) + +![Two functors](natural_functors_objects.svg) + +Note that the functors are similar have the same signature - both their input and output categories are the same - this is a necessary (but not sufficient) condition for them to be connected by a natural transformation. + +A functor is comprised of two components - object-morphism and function-morphism. So any kind of morphism of functors would have to take those two components into account. + +Let's first compose a morphism between the morphisms between objects. Because input of the object morphisms of the two functors is the same, we only need to specify a morphism in the output category. + +![Two functors](natural_transformation.svg) + + +![Two functors](natural_functors.svg) + + + Interlude: Naturality explained --- @@ -15,7 +95,6 @@ Isomorphism is not hard to construct - given two sets, containing three objects But most of these isomorphisms, are just random. In our studies we are only interested in structures that *make sense*. In category theory the abstract notion of making sense is captured by the naturality condition. - Limits and colimits ==== @@ -44,7 +123,6 @@ A Hom-functor can always be converted to any set-valued functor (Yoneda lemma). So a functor is representable when we can convert its values to values of the Hom functor - Yoneda Lemma === diff --git a/_chapters/07_natural_transformations/natural_functors.svg b/_chapters/07_natural_transformations/natural_functors.svg new file mode 100644 index 0000000..b699fb8 --- /dev/null +++ b/_chapters/07_natural_transformations/natural_functors.svg @@ -0,0 +1,297 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/07_natural_transformations/natural_functors_objects.svg b/_chapters/07_natural_transformations/natural_functors_objects.svg new file mode 100644 index 0000000..3e66e30 --- /dev/null +++ b/_chapters/07_natural_transformations/natural_functors_objects.svg @@ -0,0 +1,332 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/07_natural_transformations/natural_transformation.svg b/_chapters/07_natural_transformations/natural_transformation.svg new file mode 100644 index 0000000..111ef20 --- /dev/null +++ b/_chapters/07_natural_transformations/natural_transformation.svg @@ -0,0 +1,372 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +