diff --git a/.jekyll-metadata b/.jekyll-metadata new file mode 100644 index 0000000..9aec5ca Binary files /dev/null and b/.jekyll-metadata differ diff --git a/03_categories/text.md b/03_categories/text.md deleted file mode 100644 index be519c3..0000000 --- a/03_categories/text.md +++ /dev/null @@ -1,124 +0,0 @@ -Defining Categories -=== - -Every category theory guide (including mine) starts by talking about set theory. However, looking back, I really don't know why that is the case - surely most other books that focus around a specific subject don't start by introducing an entirely different subject. Perhaps the set-first approach is the best way to introduce people to categories. or perhaps using sets to introduce categories is just one of the things that people just do, simply because everyone else does it. But one thing is for sure - we don't need to study sets in order to understand categories. So in this chapter I would like to start over and talk about categories as a first concept. So pretend like it's a new book: - -Starting over with categories -=== - -So, a category is a collection of objects (things) where the "things" can be anything you want. Consider, for example, these ~~colourful~~ grey balls: - -![Balls](elements.svg) - -A category consists of a collection of objects as well as some arrows connecting some of them to one another, that we call (the arrows) morphisms. - -![A category](category.svg) - -Wait a minute - we said that all sets form a category, but at the same time any one set can be seen as a category on its own right (just one which has no morphisms). This is true and an example of a phenomenon that is very characteristic of category theory - one structure can be examined from many different angles and may play many different roles, often in a recursive fashion. - -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. - -![Two objects connected with multiple arrows](arrows.svg) - -Why is that is pretty obvious if we go back to set theory for a second (OK, maybe we really *have* to do this from time to time) - there are, for example, an infinite number of functions that go from number to boolean and the fact that they have the same input type and the same output type (or the same *type signature*, as we like to say) does not in any way make them equivalent to one another. - -![Two sets connected with multiple functions](set_arrows.svg) - -Composition ---- - -One of the few, or maybe even the only, requirement for a structure to be called a category is that two morphisms can make a third, or in other words that morphisms are *composable* - given two successive arrows with appropriate type signature, we can draw a third one that is equivalent to the consecutive application of the other two. - -![Composition of morphisms](composition.svg) - - -Formally, this requirement says that there should exist an operation (denoted with the symbol **•**) such that for each two functions **g: A → B** and **f: B → C**, there exists exactly one function **(f • g): A → C**. - -**NB:** Note that functional composition is written from right to left. e.g. applying **g** and then applying **f** is written **f • g** and not the other way around (you can think of it as a shortcut to **f(g(a))**). - -Again, note that this criteria is not met by just *any* morphism with this type signature. There is *exactly one* morphism that fits these criteria and there may be some which don't. - - -![Composition of morphisms in the context of additional morphism](composition_arrows.svg) - -Commuting diagrams ---- - -The diagram above, uses colors to illustrate the fact that the green morphism is equivalent to the other two (and not just some unrelated morphism), but in practice this notation is a little redundant - the only reason to draw diagrams with arrows in the first place is represent paths between objects that are equivalent to each other, all other paths just belong in different diagrams. For this reason, we can drop the colors from our diagrams. - -![Composition of morphisms - a commuting diagram](composition_commuting_diagram.svg) - -Diagrams that are like that (ones in which any two paths between two objects are equivalent to one another) are called *commutative diagrams* (or diagrams that *commute*). All diagrams that we have here (except the wrong ones) commute. - - -The law of associativity ---- - -Functional composition is special not only because you can take any two morphisms with appropriate signatures and make a third, but because you can do so indefinitely, i.e. given **n** successive arrows, each of which starts from the object that the other one finishes, we can draw one (exactly one) arrow that is equivalent to the consecutive application of all **n** arrows. - -![Composition of morphisms with many objects](composition_n_objects.svg) - -This approach for building stuff is often used in programming. To see some examples, you don't need to look further than the way the pipe operator in bash (`|`), that feeds the standard output of a program with the standard input of another program, is (ab)used (if you *want* to look further, note that there is a whole programming paradigm based on functional composition, called "concatenative programming"). - -But let's get back to the math. If we carefully review the definition above can see that it can be reduced to multiple applications of the following formula: given 4 objects and 3 morphisms between them **f** **g** **h**, combining **h** and **g** and then combining the end result with f** should be the same as combining **h** to the result of **g** and **f** (or simply **(h • g) • f = h • (g • f)**. - -**Task:** show how the definition can be reduced to the formula (the approach resembles mathematical induction). - -This formula is true if and only if this diagram commutes. - -![Composition of morphisms with many objects](composition_associativity.svg) - -Given that all our category-theoretic diagrams commute, we can say, in such cases, that the formula and the diagram are equivalent. - -This formula (and the diagram) is the definition of a property called **associativity**. Being associative is required for functional composition to really be called functional composition (and for a category to really be called category), if only because it is required for us to be able to draw diagrams of a category's objects and morphisms, as diagrams can only represent associative structures (if the diagram above does not commute it would be super weird). - -Associativity is not just about diagrams, for example when we express relations using formulas, associativity just means that brackets don't matter, in our formulas (as evidenced by the definition **(h • g) • f = h • (g • f)**). And it is not only about categories either, it is a property of many other operations on other types of objects as well e.g. if we look at numbers, we can see that the multiplication operation is associative e.g. **(1 . 2) . 3 = 1 . (2 . 3)**. While division is not **(1 / 2) / 3 = 1 / (2 / 3)**. - - -Identity ---- - -Ancient mathematicians invented the number zero that, although useless by itself, allowed them to define many useful numbers. In order to be able to define more stuff using morphisms in category theory, we too would want to define what we call the "identity morphism" for each object. In short, this is a morphism, that doesn't do anything. - -![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. - -**Question:** What is the identity morphism in the category of sets? - -Why do we need to define a morphism that does nothing? - -Isomorphisms ---- - -Once we have the concept of identity morphism defined we can have a category-theoretic definition of an isomoprhism (which is important, because the concept of an isomorphism is very important for cathegory theory): An isomorphism between two objects (**A** and **B**) consists of two morphisms - (**A → B**. and **B → A**) such that their compositions are equivalent to the identity functions of the respective objects. - -Here is how this looks when expressed using a formulas: - -Objects **A** and **B** are isomorphic -iff there exist mophisms -**f: A → B** -**g: B → A** -such that -**f • g = idB** -**g • f = idA** - -And here is the same thing expressed with a commuting diagram. - -![Isomorphism](isomorphism.svg) - -Like the example with the law of associativity, the diagram expresses the same (simple) fact as the formula, namely that going from the one of objects (**A** and **B**) to the other one and then back again is the same as applying the identity morphism i.e. doing nothing. - -A summary ---- - -For future reference, let's repeat what a category is. - -A category is a collection of **objects** (we can think of them as points) and **morphisms** (arrows) that go from one object to another, where: -1. There should be a way to compose two morphisms with an appropriate type signature into a third one in a way that is associative. -2. Each object has to have the identity mophism. - -This is it. - diff --git a/MellSans-Black.otf b/MellSans-Black.otf new file mode 100644 index 0000000..d39bd61 Binary files /dev/null and b/MellSans-Black.otf differ diff --git a/RubikMonoOne.ttf b/RubikMonoOne.ttf new file mode 100644 index 0000000..ee6af94 Binary files /dev/null and b/RubikMonoOne.ttf differ diff --git a/_chapters/00_about.md b/_chapters/00_about.md new file mode 100644 index 0000000..9be97f1 --- /dev/null +++ b/_chapters/00_about.md @@ -0,0 +1,13 @@ +--- +layout: default +title: About this book +--- + +About +=== + +This book is a product of my own endeavour of understanding category theory from a more non-mathematical viewpoint - it is just that as I am explaining something, I am understanding it better. + +It is aimed at programmers, as well as anyone else who is interested in this stuff. + +The main reason I am interested in Category Theory is that it allows us to formalise some common concepts that we use in our daily (intellectual) lives. Much of our language is based on intuition and rightfully so: relying on intuition is a very easy way to get your point across so it is understood by other human beings. However, that is part of the problem: sometimes intuition makes it too easy to communicate with someone. So easy that he might, in fact, understand things that you haven't actually said. For example, when I say that two things are equal, it would seem obvious to you what I mean, although it isn't obvious at all (how are they equal, at what context etc). That is the place when we might want to provide a more rigorous definition of what am I saying (even if I did not have one, to begin with). But providing such definition in natural language, which is designed to use intuition as a means of communication, is no easy task. It is in these situations that people often resort to diagrams to explain their thoughts. Diagrams are ubiquitous in science and mathematics because they are an understandable way to communicate a formal concept clearly. Category theory formalises the concept of a diagram and their components - arrows and objects and creates a language for presenting all kinds of ideas. Along the way, we would see all other kinds of mathematical objects, viewed under the primsm of categories. diff --git a/01_set/text.md b/_chapters/01_set.md similarity index 98% rename from 01_set/text.md rename to _chapters/01_set.md index c38b3ac..909daf7 100644 --- a/01_set/text.md +++ b/_chapters/01_set.md @@ -1,3 +1,8 @@ +--- +layout: default +title: Sets +--- + Sets === diff --git a/01_set/_boolean.svg b/_chapters/01_set/_boolean.svg similarity index 100% rename from 01_set/_boolean.svg rename to _chapters/01_set/_boolean.svg diff --git a/01_set/all.svg b/_chapters/01_set/all.svg similarity index 100% rename from 01_set/all.svg rename to _chapters/01_set/all.svg diff --git a/01_set/boolean.svg b/_chapters/01_set/boolean.svg similarity index 100% rename from 01_set/boolean.svg rename to _chapters/01_set/boolean.svg diff --git a/01_set/char.svg b/_chapters/01_set/char.svg similarity index 100% rename from 01_set/char.svg rename to _chapters/01_set/char.svg diff --git a/01_set/char_boolean.svg b/_chapters/01_set/char_boolean.svg similarity index 100% rename from 01_set/char_boolean.svg rename to _chapters/01_set/char_boolean.svg diff --git a/01_set/elements.svg b/_chapters/01_set/elements.svg similarity index 100% rename from 01_set/elements.svg rename to _chapters/01_set/elements.svg diff --git a/01_set/function_big_small.svg b/_chapters/01_set/function_big_small.svg similarity index 100% rename from 01_set/function_big_small.svg rename to _chapters/01_set/function_big_small.svg diff --git a/01_set/function_empty.svg b/_chapters/01_set/function_empty.svg similarity index 100% rename from 01_set/function_empty.svg rename to _chapters/01_set/function_empty.svg diff --git a/01_set/function_endo.svg b/_chapters/01_set/function_endo.svg similarity index 100% rename from 01_set/function_endo.svg rename to _chapters/01_set/function_endo.svg diff --git a/01_set/function_identity.svg b/_chapters/01_set/function_identity.svg similarity index 100% rename from 01_set/function_identity.svg rename to _chapters/01_set/function_identity.svg diff --git a/01_set/function_iso.svg b/_chapters/01_set/function_iso.svg similarity index 100% rename from 01_set/function_iso.svg rename to _chapters/01_set/function_iso.svg diff --git a/01_set/function_one_one.svg b/_chapters/01_set/function_one_one.svg similarity index 100% rename from 01_set/function_one_one.svg rename to _chapters/01_set/function_one_one.svg diff --git a/01_set/function_singleton.svg b/_chapters/01_set/function_singleton.svg similarity index 100% rename from 01_set/function_singleton.svg rename to _chapters/01_set/function_singleton.svg diff --git a/01_set/function_small_big.svg b/_chapters/01_set/function_small_big.svg similarity index 100% rename from 01_set/function_small_big.svg rename to _chapters/01_set/function_small_big.svg diff --git a/01_set/functions_compose.svg b/_chapters/01_set/functions_compose.svg similarity index 100% rename from 01_set/functions_compose.svg rename to _chapters/01_set/functions_compose.svg diff --git a/01_set/functions_compose_general.svg b/_chapters/01_set/functions_compose_general.svg similarity index 100% rename from 01_set/functions_compose_general.svg rename to _chapters/01_set/functions_compose_general.svg diff --git a/01_set/functions_compose_sets.svg b/_chapters/01_set/functions_compose_sets.svg similarity index 100% rename from 01_set/functions_compose_sets.svg rename to _chapters/01_set/functions_compose_sets.svg diff --git a/01_set/functions_matching.svg b/_chapters/01_set/functions_matching.svg similarity index 100% rename from 01_set/functions_matching.svg rename to _chapters/01_set/functions_matching.svg diff --git a/01_set/functions_one_after_another.svg b/_chapters/01_set/functions_one_after_another.svg similarity index 100% rename from 01_set/functions_one_after_another.svg rename to _chapters/01_set/functions_one_after_another.svg diff --git a/01_set/isomorphism_general.svg b/_chapters/01_set/isomorphism_general.svg similarity index 100% rename from 01_set/isomorphism_general.svg rename to _chapters/01_set/isomorphism_general.svg diff --git a/01_set/isomorphism_identity.svg b/_chapters/01_set/isomorphism_identity.svg similarity index 100% rename from 01_set/isomorphism_identity.svg rename to _chapters/01_set/isomorphism_identity.svg diff --git a/01_set/isomorphism_one_one.svg b/_chapters/01_set/isomorphism_one_one.svg similarity index 100% rename from 01_set/isomorphism_one_one.svg rename to _chapters/01_set/isomorphism_one_one.svg diff --git a/01_set/morphism_general.svg b/_chapters/01_set/morphism_general.svg similarity index 100% rename from 01_set/morphism_general.svg rename to _chapters/01_set/morphism_general.svg diff --git a/01_set/russells_paradox.svg b/_chapters/01_set/russells_paradox.svg similarity index 100% rename from 01_set/russells_paradox.svg rename to _chapters/01_set/russells_paradox.svg diff --git a/01_set/russells_paradox_2.svg b/_chapters/01_set/russells_paradox_2.svg similarity index 100% rename from 01_set/russells_paradox_2.svg rename to _chapters/01_set/russells_paradox_2.svg diff --git a/01_set/set_contains_itself.svg b/_chapters/01_set/set_contains_itself.svg similarity index 100% rename from 01_set/set_contains_itself.svg rename to _chapters/01_set/set_contains_itself.svg diff --git a/01_set/set_subset.svg b/_chapters/01_set/set_subset.svg similarity index 100% rename from 01_set/set_subset.svg rename to _chapters/01_set/set_subset.svg diff --git a/01_set/sets_dont_contain_themselves.svg b/_chapters/01_set/sets_dont_contain_themselves.svg similarity index 100% rename from 01_set/sets_dont_contain_themselves.svg rename to _chapters/01_set/sets_dont_contain_themselves.svg diff --git a/01_set/singleton.svg b/_chapters/01_set/singleton.svg similarity index 100% rename from 01_set/singleton.svg rename to _chapters/01_set/singleton.svg diff --git a/01_set/singleton_function.svg b/_chapters/01_set/singleton_function.svg similarity index 100% rename from 01_set/singleton_function.svg rename to _chapters/01_set/singleton_function.svg diff --git a/01_set/singleton_isomorphism.svg b/_chapters/01_set/singleton_isomorphism.svg similarity index 100% rename from 01_set/singleton_isomorphism.svg rename to _chapters/01_set/singleton_isomorphism.svg diff --git a/01_set/square.svg b/_chapters/01_set/square.svg similarity index 100% rename from 01_set/square.svg rename to _chapters/01_set/square.svg diff --git a/01_set/subset.svg b/_chapters/01_set/subset.svg similarity index 100% rename from 01_set/subset.svg rename to _chapters/01_set/subset.svg diff --git a/01_set/void.svg b/_chapters/01_set/void.svg similarity index 100% rename from 01_set/void.svg rename to _chapters/01_set/void.svg diff --git a/02_more_sets/text.md b/_chapters/02_category.md similarity index 61% rename from 02_more_sets/text.md rename to _chapters/02_category.md index d5e448a..08f91cf 100644 --- a/02_more_sets/text.md +++ b/_chapters/02_category.md @@ -1,197 +1,326 @@ -From Sets to Categories -=== - -In this chapter we will continue with set theory and at the same time we will start exploring categories, and talking about why they are important. - -Products -=== - -In the previous chapter, we needed a way to make a set that is a composite of other sets that we already have. For example when we discussed mathematical functions, we couldn't define **+** and **-** functions, because we only knew about functions that take one argument. When we talked about programming, we talked about the primitive types, `Char` and `Number`, and we mentioned that most of the types are composite types. So how do we construct those? - -The simplest composite type, of the sets **B**, which contains **b**'s and the set**Y**, which contains **y**'s is the the *product* or **B** and **Y**. - -![Product parts](product_parts.svg) - -It is the set of *pairs* of **b**'s and **y**'s. - -![Product](product.svg) - -The product is denoted **B x Y** and it comes equipped with two functions for retrieving the **b** and the **y** from each **(b, y)**. - -**Question**: Why is this called a product? Hint: How many elements does it have? - -Products as Objects ---- - -We established that in programming sets resemble types and functions resemble functions. Products, in this case, are like stripped-out *classes* (also called *records* or *structs*). The composite sets (the ones which form the product) are just the class's fields (also called *members*). The functions for accessing them are like what programmers call *getter methods*. - -For example the famous OOP example of `Person` class with `name` and `age` fields is nothing more than a product of the set of strings, and the sets of numbers (we still haven't defined strings and lists in terms of set theory but we will get to that). Objects with more than two values can be expressed as products the composites of which are themselves products. - -Using Products to Define Numeric Operations ---- - -Products can also be used for expressing functions which take more than one argument. For example, "plus" and "minus", are functions from the set of products of two numbers to the set of numbers. (so **+: R x R → R**). Of course, we cannot draw the function itself, even partly, because it has too much arrows and it would look messy. - -Joking, here it is. - -![The plus function](plus.svg) - -Note that there are languages where the *pair* datastructure (also called a *tuple*) is a first-level construct, and multi-argument functions are really implemented in this way. - -Defining products in Terms of Sets ---- - -Now we will define the abstract concept of a product of two sets sets in terms of sets themselves. It is not hard: the product of two sets **Y** and **B** is just the set of all possible *ordered pairs*, which contain one element of the set **Y** and one element of the set **B**. Or formally speaking **Y x B = { (y, b) }** where **y ∈ Y, b ∈ B** (**∈** means "is an element of"). - -![A pair](pair.svg) - -The real challenge is defining what a pair means in terms of sets. Note that the pair have to be *ordered*, so it cannot be just a set of the elements (formally speaking **A x B ≠ B x A for all A and B **). Some mathematical operations such as addition and multiplication don't care about order, but others, such as subtraction, do. And in programming we have the ability to assign names to each member of an object, which accomplishes the same purpose as ordering does for pairs. - -So the pair must be ordered, and sets aren't. Turns out that that hasn't stopped mathematicians from coming up with multiple ingenious ways to represent an ordered pair using sets. Let's see them, just for fun. Here is the first one, which was discovered by Norbert Wiener in 1914. The definition is notable for its smart use of the uniqueness of the empty set. - -![A pair, represented by sets](pair_as_set_2.svg) - -The next one was discovered in the same year by Felix Hausdorff. In order to use that one, we just have to define "1", and "2" first. - -![A pair, represented by sets](pair_as_set_3.svg) - -Discovered in 1921 Kazimierz Kuratowski, this one uses just the component of the pair. - -![A pair, represented by sets](pair_as_set_1.svg) - - -Defining products in Terms of Functions ---- - -In the previous chapter we provided a definition of a product by *zooming in* the individual elements of the sets and seeing what they can be made of. This gave us a *low-level* view of products. This time we will try to do the opposite - be as oblivious to the contents of our sets as possible. Instead of zooming in we will *zoom out*, and try define the product in terms of functions and functional composition. Effectively we will be working at a *higher level* of abstraction. - -So let's begin with an external diagram, showing the definition of the product. Disclaimer: I know that this is a somewhat weird notation, but don't worry, we will not be using it for very long. - -![Product, external diagram](product_external.svg) - -This diagram already contains the first piece of the puzzle: if we have a set **G** which is the product of sets **Y** and **B**, then we should also have functions which give us back the elements of the product, so **G → Y** and **G → B**. - -This definition is not complete, however, because the product of **G** and **B** is not the only set for which such functions can be defined. For example: - -- A set of triples of **Y x B x R** for any random element **R** also qualifies. - -- If there is a function from **G** to **B** then the set **G** itself meets our condition for being the product, because it is connected to **B** and to itself. - -Depending on our specific case there can be many other other such objects. - -![Product, external diagram](product_candidates.svg) - -So how do we set apart all those "imposter" products from the one true product? Simple - they all can be converted to it. This is true, because: -1. By definition, each "impostor" can be converted to both elements of the pair. -2. The pair is nothing more than the sum of its elements. - -More formally, in order for a set **I** to serve as an impostor for the product of **B** and **Y** and there should be two functions, which we will call **b: I → B** and **y: I → Y**. In order to prove that **I** is an impostor we need a function **I → B x Y**. That function is simply (programmers will understand this best) **(a) → b(a) x y(a)** for each **a:I**. - -![Product, external diagram](products_morphisms.svg) - -Notice that this definition does not rule out the sets which are isomorphic to the product - when we represents things using functions, an isomorphism is the same as equality. - -Sums -=== - -We will now study a construct that is pretty similar to the product but at the same time it is very different. Similar because, like the product, it is a relation between two sets which allows you to unite them into one without erasing their structure. Different because it encodes a different type of relation between them - a product encodes an **AND** relation between two sets, while the sum encodes an **OR** relation. For example, a parent is either a mother of a father of a child, so the set of parent's is a sum set of the sets of mothers and fathers. - -![Sum or coproduct](coproduct.svg) - -Notice that the when a given object is an element of both sets, then it appears in the sum twice. This is why this type of sum of two sets is also called a *disjoint union*. - -**Question:** Why is this called a sum? - -Defining Sums in Terms of Sets ---- - -Simply put, a sum of two sets is a set that contains all elements from the first set and all elements from the second one. But, as with the product, it is not so straightforward to represent sums in terms of sets. For example if two sets can have the same element as a member, their sum will have that element twice which is not permitted, because a set cannot contain the same element twice. - -As with the product, the solution is to put some extra structure. - -![A member of a coproduct](coproduct_member.svg) - -Like with the product, there is a low-level way to express a sum using sets alone. Incidentally, we can use pairs. - -![A member of a coproduct, examined](coproduct_member_set.svg) - -But again, this distinction is only rellevant only when the two sets have common elements. - - -Defining Sums in Terms of Functions ---- - -You might already suspect, the interesting part is expressing the sum of two sets using functions. To do that we have to go back to the conceptual part of the definition. We said that sums express an **OR** relation between two things. A simple property of every **OR** relation is that if something is an **A** that something is also an **A OR B** (and the same is valid if it is **B**). For example if I am *a man*, I am also *a man OR a woman*. This is what **OR** means, right? - -This relationship can be expressed as a function. Two functions actually - one for each set that takes part in the relation. - -![Coproduct, external diagram](coproduct_external.svg) - -Why can it be expressed as a function? Because it is a *many-to-one* relationship. - - -What are we saying with this, if we apply it to the example, is simply that if parents are either mothers or fathers, then there surely exist a functions **mothers → parents** and **fathers → parents**. - -You might already notice that this definition is pretty similar to the previous one, and the similarities don't end here - here again we have sets that can be thought as *impostor* sums - ones for which these functions exists, but which aren't real sums (where by "real sum" we mean a set which expresses the *OR* relation and contains no additional structure). - -![Coproduct, external diagram](coproduct_candidates.svg) - -All these sets are, express relationships which are more vague than the simple sum and therefore given any such set there would exist a function from the sum to it. - -For exaple, there exist a trivial function between the set **Y | B ** and the set **Y | B | R**. - -![Coproduct, external diagram](coproduct_morphisms.svg) - -This diagram captures the **OR** relation in the same way as the previous one captures the essence of **AND**. - -Duality -=== - -If we have to compare the concepts of sum or and product we will find out that they are related: - -- The *product* of two sets is related to an element of the first one *and* one element of the second one. -- A *sum* of two sets is related to an element of the first one *or* one element of the second one. - -Actually, the two concepts are captured by one and the same external diagram, just the arrows are flipped - many-to-one relationships become one-to-many and the other way around. - - -That's normal right? After all, **AND** *is* the opposite of **OR**. The connection between the two has always been there, evidenced, for example, by the De Morgan's law, citing that **NOT (A AND B) ↔ (NOT A) OR (NOT B)** (or to put it in everyday language, "If either A or B is false, then (and only then) A *and* B is also false). But only with category theory, this connection can be expressed in such a concise way: - -![Coproduct and product](coproduct_product_duality.svg) - -Otherwise, when in category theory two concepts are captured by the same diagram, only with reversed arrows, we can say that the two concepts are **dual** to each other. That means that the concepts of *product* and *sum* are dual (this is why sum is also known as *converse product*, or *coproduct* in short). - -Category Theory - brief definition -=== - -Maybe it is time to see what a category is. Well, a category consists of objects (an example of which are sets) and morphisms which go from one object to another (which can be viewed as functions) and which should be composable. We can say a lot more about categories, and even present a formal definition, but for now it is suffice for you to remember that sets are one example of a category and that categorical objects are like sets, except that we don't *see* their elements. This is why category-theoretic notions being captured by the external diagrams and strictly set-theoretic notions being captured by internal ones. - -What other categories, or applications of category theory are there, other than sets? We already discussed one - types in programming languages. Remember that we said that programming types (classes) are somewhat similar to sets and programming functions are somewhat similar to functions between sets? This is another example of a connection between two things that we can be defined using category theory: - - -| Category Theory | Set theory | Programming Languages | -| --- | --- | --- | -| Category | N/A | N/A | -| Objects and Morphisms | Sets and Functions | Classes and functions | -| N/A | Element | Object | - -This diagram illustrates how category theory allows us to see the big picture when it comes to sets and similar structures - when we are at the realm of sets we can view the set as a collection of individual elements. In category theory we don't have such notion, but we saw how taking this notion away allows us to define concepts such as the sum and product sets in a whole different and more general way. - -**NB: Do note how the world "Object" is used in both programming languages and in category theory, but for completely different things. The equivalent a categorical object is equivalent to a class in programming language.** - -Looking at the table I cannot help but notice the somehow weird, but otherwise completely logical symmetry (or perhaps "reverse symetry") between the the world as viewed through the lense of set theory, and the way it is viewed through the (inverted) lens of cathegory theory: - -| Category Theory | Set theory | -| --- | --- | -| Category | **N/A** | -| Objects and Morphisms | Sets and functions | -| **N/A** | Element | - -By switching to external diagrams, we lose sight of the particular (the elements of our sets), but we have gained the ability to see the whole universe that we have been previously trapped in. The whole realm of sets, can be thought as one category, a programming language can also be thought as a category. The concept of a category allows us to find and analyse similarities between these and other structures. - -![Category theory and set theory compared](set_category.svg) - -One remark before we go - the last paragraphs I sound as if I'm *comparing* categories and sets and rooting for categories. I don't want you to get the wrong impression that the two concepts are somehow competing with one another. - -Perhaps that notion would be somewhat correct if category and set theory were meant to describe *concrete* phenomena, in the way that the theory of relativity and the theory of quantum mechanics in physics. Concrete theories are conceived mainly as *descriptions* of the world, and as such it makes sense for them to be connected to one another in some sort of hierarchy. Abstract theories, like category theory and set theory, on the other hand, are more like languages for expressing such descriptions. They still can be connected, and are connected in more than one way, but there is no inherent hierarchy between the two and therefore arguing over which of the two is more basic, or more general, is just a chicken-and-egg problem, as you would see in the next chapter. - +--- +layout: default +title: From Sets to Categories +--- + +From Sets to Categories +=== + +In this chapter we will continue with set theory and at the same time we will start exploring categories, and talking about why they are important. + +Products +=== + +In the previous chapter, we needed a way to make a set that is a composite of other sets that we already have. For example when we discussed mathematical functions, we couldn't define **+** and **-** functions, because we only knew about functions that take one argument. When we talked about programming, we talked about the primitive types, `Char` and `Number`, and we mentioned that most of the types are composite types. So how do we construct those? + +The simplest composite type, of the sets **B**, which contains **b**'s and the set**Y**, which contains **y**'s is the the *product* or **B** and **Y**. + +![Product parts](product_parts.svg) + +It is the set of *pairs* of **b**'s and **y**'s. + +![Product](product.svg) + +The product is denoted **B x Y** and it comes equipped with two functions for retrieving the **b** and the **y** from each **(b, y)**. + +**Question**: Why is this called a product? Hint: How many elements does it have? + +Products as Objects +--- + +We established that in programming sets resemble types and functions resemble functions. Products, in this case, are like stripped-out *classes* (also called *records* or *structs*). The composite sets (the ones which form the product) are just the class's fields (also called *members*). The functions for accessing them are like what programmers call *getter methods*. + +For example the famous OOP example of `Person` class with `name` and `age` fields is nothing more than a product of the set of strings, and the sets of numbers (we still haven't defined strings and lists in terms of set theory but we will get to that). Objects with more than two values can be expressed as products the composites of which are themselves products. + +Using Products to Define Numeric Operations +--- + +Products can also be used for expressing functions which take more than one argument. For example, "plus" and "minus", are functions from the set of products of two numbers to the set of numbers. (so **+: R x R → R**). Of course, we cannot draw the function itself, even partly, because it has too much arrows and it would look messy. + +Joking, here it is. + +![The plus function](plus.svg) + +Note that there are languages where the *pair* datastructure (also called a *tuple*) is a first-level construct, and multi-argument functions are really implemented in this way. + +Defining products in Terms of Sets +--- + +Now we will define the abstract concept of a product of two sets sets in terms of sets themselves. It is not hard: the product of two sets **Y** and **B** is just the set of all possible *ordered pairs*, which contain one element of the set **Y** and one element of the set **B**. Or formally speaking **Y x B = { (y, b) }** where **y ∈ Y, b ∈ B** (**∈** means "is an element of"). + +![A pair](pair.svg) + +The real challenge is defining what a pair means in terms of sets. Note that the pair have to be *ordered*, so it cannot be just a set of the elements (formally speaking **A x B ≠ B x A for all A and B **). Some mathematical operations such as addition and multiplication don't care about order, but others, such as subtraction, do. And in programming we have the ability to assign names to each member of an object, which accomplishes the same purpose as ordering does for pairs. + +So the pair must be ordered, and sets aren't. Turns out that that hasn't stopped mathematicians from coming up with multiple ingenious ways to represent an ordered pair using sets. Let's see them, just for fun. Here is the first one, which was discovered by Norbert Wiener in 1914. The definition is notable for its smart use of the uniqueness of the empty set. + +![A pair, represented by sets](pair_as_set_2.svg) + +The next one was discovered in the same year by Felix Hausdorff. In order to use that one, we just have to define "1", and "2" first. + +![A pair, represented by sets](pair_as_set_3.svg) + +Discovered in 1921 Kazimierz Kuratowski, this one uses just the component of the pair. + +![A pair, represented by sets](pair_as_set_1.svg) + + +Defining products in Terms of Functions +--- + +In the previous chapter we provided a definition of a product by *zooming in* the individual elements of the sets and seeing what they can be made of. This gave us a *low-level* view of products. This time we will try to do the opposite - be as oblivious to the contents of our sets as possible. Instead of zooming in we will *zoom out*, and try define the product in terms of functions and functional composition. Effectively we will be working at a *higher level* of abstraction. + +So let's begin with an external diagram, showing the definition of the product. Disclaimer: I know that this is a somewhat weird notation, but don't worry, we will not be using it for very long. + +![Product, external diagram](product_external.svg) + +This diagram already contains the first piece of the puzzle: if we have a set **G** which is the product of sets **Y** and **B**, then we should also have functions which give us back the elements of the product, so **G → Y** and **G → B**. + +This definition is not complete, however, because the product of **G** and **B** is not the only set for which such functions can be defined. For example: + +- A set of triples of **Y x B x R** for any random element **R** also qualifies. + +- If there is a function from **G** to **B** then the set **G** itself meets our condition for being the product, because it is connected to **B** and to itself. + +Depending on our specific case there can be many other other such objects. + +![Product, external diagram](product_candidates.svg) + +So how do we set apart all those "imposter" products from the one true product? Simple - they all can be converted to it. This is true, because: +1. By definition, each "impostor" can be converted to both elements of the pair. +2. The pair is nothing more than the sum of its elements. + +More formally, in order for a set **I** to serve as an impostor for the product of **B** and **Y** and there should be two functions, which we will call **b: I → B** and **y: I → Y**. In order to prove that **I** is an impostor we need a function **I → B x Y**. That function is simply (programmers will understand this best) **(a) → b(a) x y(a)** for each **a:I**. + +![Product, external diagram](products_morphisms.svg) + +Notice that this definition does not rule out the sets which are isomorphic to the product - when we represents things using functions, an isomorphism is the same as equality. + +Sums +=== + +We will now study a construct that is pretty similar to the product but at the same time it is very different. Similar because, like the product, it is a relation between two sets which allows you to unite them into one without erasing their structure. Different because it encodes a different type of relation between them - a product encodes an **AND** relation between two sets, while the sum encodes an **OR** relation. For example, a parent is either a mother of a father of a child, so the set of parent's is a sum set of the sets of mothers and fathers. + +![Sum or coproduct](coproduct.svg) + +Notice that the when a given object is an element of both sets, then it appears in the sum twice. This is why this type of sum of two sets is also called a *disjoint union*. + +**Question:** Why is this called a sum? + +Defining Sums in Terms of Sets +--- + +Simply put, a sum of two sets is a set that contains all elements from the first set and all elements from the second one. But, as with the product, it is not so straightforward to represent sums in terms of sets. For example if two sets can have the same element as a member, their sum will have that element twice which is not permitted, because a set cannot contain the same element twice. + +As with the product, the solution is to put some extra structure. + +![A member of a coproduct](coproduct_member.svg) + +Like with the product, there is a low-level way to express a sum using sets alone. Incidentally, we can use pairs. + +![A member of a coproduct, examined](coproduct_member_set.svg) + +But again, this distinction is only rellevant only when the two sets have common elements. + + +Defining Sums in Terms of Functions +--- + +You might already suspect, the interesting part is expressing the sum of two sets using functions. To do that we have to go back to the conceptual part of the definition. We said that sums express an **OR** relation between two things. A simple property of every **OR** relation is that if something is an **A** that something is also an **A OR B** (and the same is valid if it is **B**). For example if I am *a man*, I am also *a man OR a woman*. This is what **OR** means, right? + +This relationship can be expressed as a function. Two functions actually - one for each set that takes part in the relation. + +![Coproduct, external diagram](coproduct_external.svg) + +Why can it be expressed as a function? Because it is a *many-to-one* relationship. + + +What are we saying with this, if we apply it to the example, is simply that if parents are either mothers or fathers, then there surely exist a functions **mothers → parents** and **fathers → parents**. + +You might already notice that this definition is pretty similar to the previous one, and the similarities don't end here - here again we have sets that can be thought as *impostor* sums - ones for which these functions exists, but which aren't real sums (where by "real sum" we mean a set which expresses the *OR* relation and contains no additional structure). + +![Coproduct, external diagram](coproduct_candidates.svg) + +All these sets are, express relationships which are more vague than the simple sum and therefore given any such set there would exist a function from the sum to it. + +For exaple, there exist a trivial function between the set **Y | B ** and the set **Y | B | R**. + +![Coproduct, external diagram](coproduct_morphisms.svg) + +This diagram captures the **OR** relation in the same way as the previous one captures the essence of **AND**. + +Duality +=== + +If we have to compare the concepts of sum or and product we will find out that they are related: + +- The *product* of two sets is related to an element of the first one *and* one element of the second one. +- A *sum* of two sets is related to an element of the first one *or* one element of the second one. + +Actually, the two concepts are captured by one and the same external diagram, just the arrows are flipped - many-to-one relationships become one-to-many and the other way around. + + +That's normal right? After all, **AND** *is* the opposite of **OR**. The connection between the two has always been there, evidenced, for example, by the De Morgan's law, citing that **NOT (A AND B) ↔ (NOT A) OR (NOT B)** (or to put it in everyday language, "If either A or B is false, then (and only then) A *and* B is also false). But only with category theory, this connection can be expressed in such a concise way: + +![Coproduct and product](coproduct_product_duality.svg) + +Otherwise, when in category theory two concepts are captured by the same diagram, only with reversed arrows, we can say that the two concepts are **dual** to each other. That means that the concepts of *product* and *sum* are dual (this is why sum is also known as *converse product*, or *coproduct* in short). + +Category Theory - brief definition +=== + +Maybe it is time to see what a category is. Well, a category consists of objects (an example of which are sets) and morphisms which go from one object to another (which can be viewed as functions) and which should be composable. We can say a lot more about categories, and even present a formal definition, but for now it is suffice for you to remember that sets are one example of a category and that categorical objects are like sets, except that we don't *see* their elements. This is why category-theoretic notions being captured by the external diagrams and strictly set-theoretic notions being captured by internal ones. + +What other categories, or applications of category theory are there, other than sets? We already discussed one - types in programming languages. Remember that we said that programming types (classes) are somewhat similar to sets and programming functions are somewhat similar to functions between sets? This is another example of a connection between two things that we can be defined using category theory: + + +| Category Theory | Set theory | Programming Languages | +| --- | --- | --- | +| Category | N/A | N/A | +| Objects and Morphisms | Sets and Functions | Classes and functions | +| N/A | Element | Object | + +This diagram illustrates how category theory allows us to see the big picture when it comes to sets and similar structures - when we are at the realm of sets we can view the set as a collection of individual elements. In category theory we don't have such notion, but we saw how taking this notion away allows us to define concepts such as the sum and product sets in a whole different and more general way. + +**NB: Do note how the world "Object" is used in both programming languages and in category theory, but for completely different things. The equivalent a categorical object is equivalent to a class in programming language.** + +Looking at the table I cannot help but notice the somehow weird, but otherwise completely logical symmetry (or perhaps "reverse symetry") between the the world as viewed through the lense of set theory, and the way it is viewed through the (inverted) lens of cathegory theory: + +| Category Theory | Set theory | +| --- | --- | +| Category | **N/A** | +| Objects and Morphisms | Sets and functions | +| **N/A** | Element | + +By switching to external diagrams, we lose sight of the particular (the elements of our sets), but we have gained the ability to see the whole universe that we have been previously trapped in. The whole realm of sets, can be thought as one category, a programming language can also be thought as a category. The concept of a category allows us to find and analyse similarities between these and other structures. + +![Category theory and set theory compared](set_category.svg) + +One remark before we go - the last paragraphs I sound as if I'm *comparing* categories and sets and rooting for categories. I don't want you to get the wrong impression that the two concepts are somehow competing with one another. + +Perhaps that notion would be somewhat correct if category and set theory were meant to describe *concrete* phenomena, in the way that the theory of relativity and the theory of quantum mechanics in physics. Concrete theories are conceived mainly as *descriptions* of the world, and as such it makes sense for them to be connected to one another in some sort of hierarchy. Abstract theories, like category theory and set theory, on the other hand, are more like languages for expressing such descriptions. They still can be connected, and are connected in more than one way, but there is no inherent hierarchy between the two and therefore arguing over which of the two is more basic, or more general, is just a chicken-and-egg problem, as you would see in the next chapter. + +Defining Categories +=== + +Every category theory guide (including mine) starts by talking about set theory. However, looking back, I really don't know why that is the case - surely most other books that focus around a specific subject don't start by introducing an entirely different subject. Perhaps the set-first approach is the best way to introduce people to categories. or perhaps using sets to introduce categories is just one of the things that people just do, simply because everyone else does it. But one thing is for sure - we don't need to study sets in order to understand categories. So in this chapter I would like to start over and talk about categories as a first concept. So pretend like it's a new book: + +Starting over with categories +=== + +So, a category is a collection of objects (things) where the "things" can be anything you want. Consider, for example, these ~~colourful~~ grey balls: + +![Balls](elements.svg) + +A category consists of a collection of objects as well as some arrows connecting some of them to one another, that we call (the arrows) morphisms. + +![A category](category.svg) + +Wait a minute - we said that all sets form a category, but at the same time any one set can be seen as a category on its own right (just one which has no morphisms). This is true and an example of a phenomenon that is very characteristic of category theory - one structure can be examined from many different angles and may play many different roles, often in a recursive fashion. + +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. + +![Two objects connected with multiple arrows](arrows.svg) + +Why is that is pretty obvious if we go back to set theory for a second (OK, maybe we really *have* to do this from time to time) - there are, for example, an infinite number of functions that go from number to boolean and the fact that they have the same input type and the same output type (or the same *type signature*, as we like to say) does not in any way make them equivalent to one another. + +![Two sets connected with multiple functions](set_arrows.svg) + +Composition +--- + +One of the few, or maybe even the only, requirement for a structure to be called a category is that two morphisms can make a third, or in other words that morphisms are *composable* - given two successive arrows with appropriate type signature, we can draw a third one that is equivalent to the consecutive application of the other two. + +![Composition of morphisms](composition.svg) + + +Formally, this requirement says that there should exist an operation (denoted with the symbol **•**) such that for each two functions **g: A → B** and **f: B → C**, there exists exactly one function **(f • g): A → C**. + +**NB:** Note that functional composition is written from right to left. e.g. applying **g** and then applying **f** is written **f • g** and not the other way around (you can think of it as a shortcut to **f(g(a))**). + +Again, note that this criteria is not met by just *any* morphism with this type signature. There is *exactly one* morphism that fits these criteria and there may be some which don't. + + +![Composition of morphisms in the context of additional morphism](composition_arrows.svg) + +Commuting diagrams +--- + +The diagram above, uses colors to illustrate the fact that the green morphism is equivalent to the other two (and not just some unrelated morphism), but in practice this notation is a little redundant - the only reason to draw diagrams with arrows in the first place is represent paths between objects that are equivalent to each other, all other paths just belong in different diagrams. For this reason, we can drop the colors from our diagrams. + +![Composition of morphisms - a commuting diagram](composition_commuting_diagram.svg) + +Diagrams that are like that (ones in which any two paths between two objects are equivalent to one another) are called *commutative diagrams* (or diagrams that *commute*). All diagrams that we have here (except the wrong ones) commute. + + +The law of associativity +--- + +Functional composition is special not only because you can take any two morphisms with appropriate signatures and make a third, but because you can do so indefinitely, i.e. given **n** successive arrows, each of which starts from the object that the other one finishes, we can draw one (exactly one) arrow that is equivalent to the consecutive application of all **n** arrows. + +![Composition of morphisms with many objects](composition_n_objects.svg) + +This approach for building stuff is often used in programming. To see some examples, you don't need to look further than the way the pipe operator in bash (`|`), that feeds the standard output of a program with the standard input of another program, is (ab)used (if you *want* to look further, note that there is a whole programming paradigm based on functional composition, called "concatenative programming"). + +But let's get back to the math. If we carefully review the definition above can see that it can be reduced to multiple applications of the following formula: given 4 objects and 3 morphisms between them **f** **g** **h**, combining **h** and **g** and then combining the end result with f** should be the same as combining **h** to the result of **g** and **f** (or simply **(h • g) • f = h • (g • f)**. + +**Task:** show how the definition can be reduced to the formula (the approach resembles mathematical induction). + +This formula is true if and only if this diagram commutes. + +![Composition of morphisms with many objects](composition_associativity.svg) + +Given that all our category-theoretic diagrams commute, we can say, in such cases, that the formula and the diagram are equivalent. + +This formula (and the diagram) is the definition of a property called **associativity**. Being associative is required for functional composition to really be called functional composition (and for a category to really be called category), if only because it is required for us to be able to draw diagrams of a category's objects and morphisms, as diagrams can only represent associative structures (if the diagram above does not commute it would be super weird). + +Associativity is not just about diagrams, for example when we express relations using formulas, associativity just means that brackets don't matter, in our formulas (as evidenced by the definition **(h • g) • f = h • (g • f)**). And it is not only about categories either, it is a property of many other operations on other types of objects as well e.g. if we look at numbers, we can see that the multiplication operation is associative e.g. **(1 . 2) . 3 = 1 . (2 . 3)**. While division is not **(1 / 2) / 3 = 1 / (2 / 3)**. + + +Identity +--- + +Ancient mathematicians invented the number zero that, although useless by itself, allowed them to define many useful numbers. In order to be able to define more stuff using morphisms in category theory, we too would want to define what we call the "identity morphism" for each object. In short, this is a morphism, that doesn't do anything. + +![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. + +**Question:** What is the identity morphism in the category of sets? + +Why do we need to define a morphism that does nothing? + +Isomorphisms +--- + +Once we have the concept of identity morphism defined we can have a category-theoretic definition of an isomoprhism (which is important, because the concept of an isomorphism is very important for cathegory theory): An isomorphism between two objects (**A** and **B**) consists of two morphisms - (**A → B**. and **B → A**) such that their compositions are equivalent to the identity functions of the respective objects. + +Here is how this looks when expressed using a formulas: + +Objects **A** and **B** are isomorphic +iff there exist mophisms +**f: A → B** +**g: B → A** +such that +**f • g = idB** +**g • f = idA** + +And here is the same thing expressed with a commuting diagram. + +![Isomorphism](isomorphism.svg) + +Like the example with the law of associativity, the diagram expresses the same (simple) fact as the formula, namely that going from the one of objects (**A** and **B**) to the other one and then back again is the same as applying the identity morphism i.e. doing nothing. + +A summary +--- + +For future reference, let's repeat what a category is. + +A category is a collection of **objects** (we can think of them as points) and **morphisms** (arrows) that go from one object to another, where: +1. There should be a way to compose two morphisms with an appropriate type signature into a third one in a way that is associative. +2. Each object has to have the identity mophism. + +This is it. + diff --git a/03_categories/arrows.svg b/_chapters/02_category/arrows.svg similarity index 100% rename from 03_categories/arrows.svg rename to _chapters/02_category/arrows.svg diff --git a/03_categories/category.svg b/_chapters/02_category/category.svg similarity index 100% rename from 03_categories/category.svg rename to _chapters/02_category/category.svg diff --git a/03_categories/composition.svg b/_chapters/02_category/composition.svg similarity index 100% rename from 03_categories/composition.svg rename to _chapters/02_category/composition.svg diff --git a/03_categories/composition_arrows.svg b/_chapters/02_category/composition_arrows.svg similarity index 100% rename from 03_categories/composition_arrows.svg rename to _chapters/02_category/composition_arrows.svg diff --git a/03_categories/composition_associativity.svg b/_chapters/02_category/composition_associativity.svg similarity index 100% rename from 03_categories/composition_associativity.svg rename to _chapters/02_category/composition_associativity.svg diff --git a/03_categories/composition_commuting_diagram.svg b/_chapters/02_category/composition_commuting_diagram.svg similarity index 100% rename from 03_categories/composition_commuting_diagram.svg rename to _chapters/02_category/composition_commuting_diagram.svg diff --git a/03_categories/composition_n_objects.svg b/_chapters/02_category/composition_n_objects.svg similarity index 100% rename from 03_categories/composition_n_objects.svg rename to _chapters/02_category/composition_n_objects.svg diff --git a/02_more_sets/coproduct.svg b/_chapters/02_category/coproduct.svg similarity index 100% rename from 02_more_sets/coproduct.svg rename to _chapters/02_category/coproduct.svg diff --git a/02_more_sets/coproduct_candidates.svg b/_chapters/02_category/coproduct_candidates.svg similarity index 100% rename from 02_more_sets/coproduct_candidates.svg rename to _chapters/02_category/coproduct_candidates.svg diff --git a/02_more_sets/coproduct_external.svg b/_chapters/02_category/coproduct_external.svg similarity index 100% rename from 02_more_sets/coproduct_external.svg rename to _chapters/02_category/coproduct_external.svg diff --git a/02_more_sets/coproduct_member.svg b/_chapters/02_category/coproduct_member.svg similarity index 100% rename from 02_more_sets/coproduct_member.svg rename to _chapters/02_category/coproduct_member.svg diff --git a/02_more_sets/coproduct_member_set.svg b/_chapters/02_category/coproduct_member_set.svg similarity index 100% rename from 02_more_sets/coproduct_member_set.svg rename to _chapters/02_category/coproduct_member_set.svg diff --git a/02_more_sets/coproduct_morphisms.svg b/_chapters/02_category/coproduct_morphisms.svg similarity index 100% rename from 02_more_sets/coproduct_morphisms.svg rename to _chapters/02_category/coproduct_morphisms.svg diff --git a/02_more_sets/coproduct_product_duality.svg b/_chapters/02_category/coproduct_product_duality.svg similarity index 100% rename from 02_more_sets/coproduct_product_duality.svg rename to _chapters/02_category/coproduct_product_duality.svg diff --git a/03_categories/elements.svg b/_chapters/02_category/elements.svg similarity index 100% rename from 03_categories/elements.svg rename to _chapters/02_category/elements.svg diff --git a/03_categories/identity.svg b/_chapters/02_category/identity.svg similarity index 100% rename from 03_categories/identity.svg rename to _chapters/02_category/identity.svg diff --git a/03_categories/isomorphism.svg b/_chapters/02_category/isomorphism.svg similarity index 100% rename from 03_categories/isomorphism.svg rename to _chapters/02_category/isomorphism.svg diff --git a/02_more_sets/pair.svg b/_chapters/02_category/pair.svg similarity index 100% rename from 02_more_sets/pair.svg rename to _chapters/02_category/pair.svg diff --git a/02_more_sets/pair_as_set_1.svg b/_chapters/02_category/pair_as_set_1.svg similarity index 100% rename from 02_more_sets/pair_as_set_1.svg rename to _chapters/02_category/pair_as_set_1.svg diff --git a/02_more_sets/pair_as_set_2.svg b/_chapters/02_category/pair_as_set_2.svg similarity index 100% rename from 02_more_sets/pair_as_set_2.svg rename to _chapters/02_category/pair_as_set_2.svg diff --git a/02_more_sets/pair_as_set_3.svg b/_chapters/02_category/pair_as_set_3.svg similarity index 100% rename from 02_more_sets/pair_as_set_3.svg rename to _chapters/02_category/pair_as_set_3.svg diff --git a/02_more_sets/plus.svg b/_chapters/02_category/plus.svg similarity index 100% rename from 02_more_sets/plus.svg rename to _chapters/02_category/plus.svg diff --git a/02_more_sets/product.svg b/_chapters/02_category/product.svg similarity index 100% rename from 02_more_sets/product.svg rename to _chapters/02_category/product.svg diff --git a/02_more_sets/product_candidates.svg b/_chapters/02_category/product_candidates.svg similarity index 100% rename from 02_more_sets/product_candidates.svg rename to _chapters/02_category/product_candidates.svg diff --git a/02_more_sets/product_external.svg b/_chapters/02_category/product_external.svg similarity index 100% rename from 02_more_sets/product_external.svg rename to _chapters/02_category/product_external.svg diff --git a/02_more_sets/product_parts.svg b/_chapters/02_category/product_parts.svg similarity index 100% rename from 02_more_sets/product_parts.svg rename to _chapters/02_category/product_parts.svg diff --git a/02_more_sets/products_morphisms.svg b/_chapters/02_category/products_morphisms.svg similarity index 100% rename from 02_more_sets/products_morphisms.svg rename to _chapters/02_category/products_morphisms.svg diff --git a/03_categories/set_arrows.svg b/_chapters/02_category/set_arrows.svg similarity index 100% rename from 03_categories/set_arrows.svg rename to _chapters/02_category/set_arrows.svg diff --git a/02_more_sets/set_category.svg b/_chapters/02_category/set_category.svg similarity index 100% rename from 02_more_sets/set_category.svg rename to _chapters/02_category/set_category.svg diff --git a/04_monoids/text.md b/_chapters/03_monoid.md similarity index 89% rename from 04_monoids/text.md rename to _chapters/03_monoid.md index 86d57e9..29f99c3 100644 --- a/04_monoids/text.md +++ b/_chapters/03_monoid.md @@ -1,5 +1,9 @@ -Monoids etc. +--- +layout: default +title: Monoids etc +--- +Monoids etc === Since we are done with categories, let's look at some other structures that are also interesting - monoids. Like categories, monoids/groups are also abstract systems consisting of objects and rules for manipulating these objects. @@ -11,13 +15,13 @@ Monoids are simpler than categories. A monoid is defined by a collection (set) o Let's take our familiar colourful balls. -[Balls](balls.svg) +![Balls](balls.svg) In this case a monoid would be a rule (operation) for "combining" two balls into one. An example of such rule would be blending the colors of the balls, as if we are mixing paint. -[A rule for combining balls](balls_rule.svg) +![A rule for combining balls](balls_rule.svg) You can probably think of other ways to define such a rule. This will help you realize that there can be many ways to create a monoid from a given set of items. The monoid is not the set itself, it is the set *together with the rule*. @@ -26,18 +30,18 @@ Associativity The monoid rule should, like functional composition, be "associative" i.e. applying it on the same number of elements in a different order should make no difference. -[Associativity in the color mixing operation](balls_associativity.svg) +![Associativity in the color mixing operation](balls_associativity.svg) When a rule is associative, this means we can use all kinds of algebraic operations to any sequence of terms (or in other words to apply equation reasoning), like for example we can add or remove a term that is present at both sides of an equation and retaining the equality of the existing terms: -[Associativity in the color mixing operation](balls_arithmetic.svg) +![Associativity in the color mixing operation](balls_arithmetic.svg) The identity element --- Actually, not any (associative) rule for combining elements makes the balls form a monoid (it makes them form a "semigroup", which is also a thing, but that's a separate topic). In order to be a monoid, a set must feature what is called an "identity element" of a given rule (or a *zero* element, if you prefer) - one that, when combined with any other element gives back that same element not the identity but the other one. Or simply **x • i = x and i • x = x for any x**. In the case of our color-mixing monoid the identity element is the color white, represented by the white ball: -[The identity element of the color-mixing monoid](balls_identity.svg) +![The identity element of the color-mixing monoid](balls_identity.svg) As you probably remember from the last chapter, functional composition is also associative and it also contains an identity element, so you might start suspecting that it forms a monoid in some way. And it is really the case with one little caveat. @@ -52,13 +56,13 @@ Monoids from numbers Mathematics is not all about numbers, however numbers do tend to pop up in most of its areas and monoids are no exception. The set of natural numbers *N* form a monoid when combined with the all too familiar operation of addition (or to use the official terminology *N* *form* a monoid *under* addition). -[The monoid of numbers under addition](numbers_addition.svg) +![The monoid of numbers under addition](numbers_addition.svg) -(if you see a **1 + 1 = 2** in your texbook you know you are working on math foundations(or you are in kindergarden)). +(if you see a **1 + 1 = 2** in your texbook you know you are working on math foundations (or you are in kindergarden)). The natural numbers also form a monoid under multiplication as well: -[The monoid of numbers under multiplication](numbers_multiplication.svg) +![The monoid of numbers under multiplication](numbers_multiplication.svg) **Task:** Which are the identity elements of those monoids? @@ -72,13 +76,17 @@ Thinking about other operations that we covered (operation being a function whic We can prove that **AND** is associative by expanding the formula **(A AND B) AND C = A AND (B AND C)** in all possible ways: **(TRUE AND FALSE) AND TRUE = TRUE AND (FALSE AND TRUE)** + **(TRUE AND FALSE) AND FALSE = TRUE AND (FALSE AND FALSE)** + **(FALSE AND FALSE) AND TRUE = FALSE AND (FALSE AND TRUE)** + ... And we can prove that **TRUE** is the identity element by expanding the other formulas that state that for all elements **A** **I AND A = A** **FALSE AND TRUE = FALSE** + **TRUE AND TRUE = TRUE** ...and then do the same for **A AND I = A**. @@ -102,13 +110,13 @@ Commutative monoids Looking at the monoid laws and the examples we gave so far, we observe that all of them obey one more rule (law) which we didn't specify, namely that the order in which the operations are applied is irrelevant to the end result. -[Commutative monoid operation](monoid_commutative.svg) +![Commutative monoid operation](monoid_commutative.svg) Such operations (ones for which combining a given set of objects yields the same result no matter which one is first and which one is second) are called *commutative* operations. Monoids with operations that are commutative are called *commutative monoids*. As we said, addition is commutative as well - it does not matter whether if I have given you 1 apple and then 2 more, or if I have given you 2 first and then 1 more i.e. **x + y = y + x**. -[Commutative monoid operation](addition_commutative.svg) +![Commutative monoid operation](addition_commutative.svg) All monoids that we examined so far are also *commutative*, and we will see some non-commutative ones later. @@ -132,37 +140,3 @@ Here are the algebraic structures that we have seen so far and the laws that the |Associativity| X | X | X | |Identity| | X | X | |Invertability | | | X | - -Symmetry groups -=== - -An interesting set of groups/monoids of *symmetries* of some object - -Group of rotations ---- - -Group of reflections ---- - -Cancellation law ---- - - - -Categories -=== - -Some more advanced examples -=== - -The trivial monoid ---- -Peano arithmetic - - -Monoids as categories -=== - -The free monoid. -=== - diff --git a/04_monoids/addition_commutative.svg b/_chapters/03_monoid/addition_commutative.svg similarity index 100% rename from 04_monoids/addition_commutative.svg rename to _chapters/03_monoid/addition_commutative.svg diff --git a/04_monoids/balls.svg b/_chapters/03_monoid/balls.svg similarity index 100% rename from 04_monoids/balls.svg rename to _chapters/03_monoid/balls.svg diff --git a/04_monoids/balls_arithmetic.svg b/_chapters/03_monoid/balls_arithmetic.svg similarity index 100% rename from 04_monoids/balls_arithmetic.svg rename to _chapters/03_monoid/balls_arithmetic.svg diff --git a/04_monoids/balls_associativity.svg b/_chapters/03_monoid/balls_associativity.svg similarity index 100% rename from 04_monoids/balls_associativity.svg rename to _chapters/03_monoid/balls_associativity.svg diff --git a/04_monoids/balls_identity.svg b/_chapters/03_monoid/balls_identity.svg similarity index 100% rename from 04_monoids/balls_identity.svg rename to _chapters/03_monoid/balls_identity.svg diff --git a/04_monoids/balls_rule.svg b/_chapters/03_monoid/balls_rule.svg similarity index 100% rename from 04_monoids/balls_rule.svg rename to _chapters/03_monoid/balls_rule.svg diff --git a/04_monoids/monoid_commutative.svg b/_chapters/03_monoid/monoid_commutative.svg similarity index 100% rename from 04_monoids/monoid_commutative.svg rename to _chapters/03_monoid/monoid_commutative.svg diff --git a/04_monoids/numbers_addition.svg b/_chapters/03_monoid/numbers_addition.svg similarity index 100% rename from 04_monoids/numbers_addition.svg rename to _chapters/03_monoid/numbers_addition.svg diff --git a/04_monoids/numbers_multiplication.svg b/_chapters/03_monoid/numbers_multiplication.svg similarity index 100% rename from 04_monoids/numbers_multiplication.svg rename to _chapters/03_monoid/numbers_multiplication.svg diff --git a/05_functors/text.md b/_chapters/05_functors/text.md similarity index 100% rename from 05_functors/text.md rename to _chapters/05_functors/text.md diff --git a/_config.yml b/_config.yml index 5dfb065..8f2885e 100644 --- a/_config.yml +++ b/_config.yml @@ -1,76 +1,56 @@ -# -# This file contains configuration flags to customize your site -# - -# Name of your site (displayed in the header) -name: Category theory illustrated - -# Short bio or description (displayed in the header) -description: Sets, categories, logic and other stuffs, represented visually - -# URL of your avatar or profile pic (you could use your GitHub profile pic) -avatar: https://raw.githubusercontent.com/barryclark/jekyll-now/master/images/jekyll-logo.png - -# -# Flags below are optional -# - -# Includes an icon in the footer for each username you enter -footer-links: - dribbble: - email: - facebook: - flickr: - github: barryclark/jekyll-now - instagram: - linkedin: - pinterest: - rss: # just type anything here for a working RSS icon, make sure you set the "url" above! - twitter: jekyllrb - stackoverflow: # your stackoverflow profile, e.g. "users/50476/bart-kiers" - youtube: # channel/ or user/ - -# Enter your Disqus shortname (not your username) to enable commenting on posts -# You can find your shortname on the Settings page of your Disqus account -disqus: - -# Enter your Google Analytics web tracking code (e.g. UA-2110908-2) to activate tracking -google_analytics: - -# Your website URL (e.g. http://barryclark.github.io or http://www.barryclark.co) -# Used for Sitemap.xml and your RSS feed -url: - -excerpt_separator: # you can specify your own separator, of course. - -# If you're hosting your site at a Project repository on GitHub pages -# (http://yourusername.github.io/repository-name) -# and NOT your User repository (http://yourusername.github.io) -# then add in the baseurl here, like this: "/repository-name" -#baseurl: "/funktion" - -# -# !! You don't need to change any of the configuration flags below !! -# - -highlighter: rouge -permalink: /:title/ - -# The release of Jekyll Now that you're using -version: v1.1.0 - -# Set the Sass partials directory, as we're using @imports -sass: - style: :expanded # You might prefer to minify using :compressed - -# Use the following plug-ins -gems: - - jekyll-sitemap # Create a sitemap using the official Jekyll sitemap gem - - jekyll-feed - -# Exclude these files from your production _site -exclude: - - Gemfile - - Gemfile.lock - - LICENSE - - README.md +# +# This file contains configuration flags to customize your site +# + +# Name of your site (displayed in the header) +name: Category Theory Illustrated + +# Short bio or description (displayed in the header) +description: A book about category theory + +# +# Flags below are optional +# + +# Enter your Google Analytics web tracking code (e.g. UA-2110908-2) to activate tracking +google_analytics: + +# Your website URL (e.g. http://barryclark.github.io or http://www.barryclark.co) +# Used for Sitemap.xml and your RSS feed +url: boris-marinov.github.io/category-theory-illustrated + +excerpt_separator: # you can specify your own separator, of course. + +# If you're hosting your site at a Project repository on GitHub pages +# (http://yourusername.github.io/repository-name) +# and NOT your User repository (http://yourusername.github.io) +# then add in the baseurl here, like this: "/repository-name" +baseurl: "/category-theory-illustrated" + +collections: + chapters: + output: true + permalink: /:path/ + + +# +# !! You don't need to change any of the configuration flags below !! +# + +highlighter: rouge +permalink: /:title/ + +# The release of Jekyll Now that you're using +version: v1.1.0 + +# Use the following plug-ins +gems: + - jekyll-sitemap # Create a sitemap using the official Jekyll sitemap gem + - jekyll-feed + +# Exclude these files from your production _site +exclude: + - Gemfile + - Gemfile.lock + - LICENSE + - README.md diff --git a/_layouts/default.html b/_layouts/default.html new file mode 100644 index 0000000..0b39a7a --- /dev/null +++ b/_layouts/default.html @@ -0,0 +1,43 @@ + + + + {{site.name}} - {{ page.title }} + + + + + +
+
+ +
+
+
+ + {{ content }} +
+ {% if page.previous.url %} + + {% endif %} + {% if page.next.url %} + + {% endif %} +
+
+
+
+

Contents

+ {% for chapter in site.chapters %} +

{{chapter.title}}

+ {% endfor %} + +
+
+ + + + diff --git a/_site/00_about/index.html b/_site/00_about/index.html new file mode 100644 index 0000000..b41995a --- /dev/null +++ b/_site/00_about/index.html @@ -0,0 +1,54 @@ + + + + Category Theory Illustrated - About this book + + + + + +
+
+ +
+
+
+ +

About

+ +

This book is a product of my own endeavour of understanding category theory from a more non-mathematical viewpoint - it is just that as I am explaining something, I am understanding it better.

+ +

It is aimed at programmers, as well as anyone else who is interested in this stuff.

+ +

The main reason I am interested in Category Theory is that it allows us to formalise some common concepts that we use in our daily (intellectual) lives. Much of our language is based on intuition and rightfully so: relying on intuition is a very easy way to get your point across so it is understood by other human beings. However, that is part of the problem: sometimes intuition makes it too easy to communicate with someone. So easy that he might, in fact, understand things that you haven’t actually said. For example, when I say that two things are equal, it would seem obvious to you what I mean, although it isn’t obvious at all (how are they equal, at what context etc). That is the place when we might want to provide a more rigorous definition of what am I saying (even if I did not have one, to begin with). But providing such definition in natural language, which is designed to use intuition as a means of communication, is no easy task. It is in these situations that people often resort to diagrams to explain their thoughts. Diagrams are ubiquitous in science and mathematics because they are an understandable way to communicate a formal concept clearly. Category theory formalises the concept of a diagram and their components - arrows and objects and creates a language for presenting all kinds of ideas. Along the way, we would see all other kinds of mathematical objects, viewed under the primsm of categories.

+ +
+ + + + +
+
+
+
+

Contents

+ +

About this book

+ +

Sets

+ +

From Sets to Categories

+ +

Monoids etc

+ + +
+
+ + + + diff --git a/_site/01_set/all.svg b/_site/01_set/all.svg new file mode 100644 index 0000000..9dfe552 --- /dev/null +++ b/_site/01_set/all.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/boolean.svg b/_site/01_set/boolean.svg new file mode 100644 index 0000000..db0ad4a --- /dev/null +++ b/_site/01_set/boolean.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/char.svg b/_site/01_set/char.svg new file mode 100644 index 0000000..dc0d5d6 --- /dev/null +++ b/_site/01_set/char.svg @@ -0,0 +1 @@ +A \ No newline at end of file diff --git a/_site/01_set/char_boolean.svg b/_site/01_set/char_boolean.svg new file mode 100644 index 0000000..d11340e --- /dev/null +++ b/_site/01_set/char_boolean.svg @@ -0,0 +1 @@ +A \ No newline at end of file diff --git a/_site/01_set/elements.svg b/_site/01_set/elements.svg new file mode 100644 index 0000000..f3edce9 --- /dev/null +++ b/_site/01_set/elements.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_big_small.svg b/_site/01_set/function_big_small.svg new file mode 100644 index 0000000..b01cf83 --- /dev/null +++ b/_site/01_set/function_big_small.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_empty.svg b/_site/01_set/function_empty.svg new file mode 100644 index 0000000..30104ce --- /dev/null +++ b/_site/01_set/function_empty.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_endo.svg b/_site/01_set/function_endo.svg new file mode 100644 index 0000000..260093b --- /dev/null +++ b/_site/01_set/function_endo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_identity.svg b/_site/01_set/function_identity.svg new file mode 100644 index 0000000..258a106 --- /dev/null +++ b/_site/01_set/function_identity.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_iso.svg b/_site/01_set/function_iso.svg new file mode 100644 index 0000000..2b95bc0 --- /dev/null +++ b/_site/01_set/function_iso.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_one_one.svg b/_site/01_set/function_one_one.svg new file mode 100644 index 0000000..260093b --- /dev/null +++ b/_site/01_set/function_one_one.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_singleton.svg b/_site/01_set/function_singleton.svg new file mode 100644 index 0000000..15b9a32 --- /dev/null +++ b/_site/01_set/function_singleton.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/function_small_big.svg b/_site/01_set/function_small_big.svg new file mode 100644 index 0000000..c4b1396 --- /dev/null +++ b/_site/01_set/function_small_big.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/functions_compose.svg b/_site/01_set/functions_compose.svg new file mode 100644 index 0000000..6cef4a0 --- /dev/null +++ b/_site/01_set/functions_compose.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/functions_compose_general.svg b/_site/01_set/functions_compose_general.svg new file mode 100644 index 0000000..ca04f0e --- /dev/null +++ b/_site/01_set/functions_compose_general.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/functions_compose_sets.svg b/_site/01_set/functions_compose_sets.svg new file mode 100644 index 0000000..7711a19 --- /dev/null +++ b/_site/01_set/functions_compose_sets.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/functions_matching.svg b/_site/01_set/functions_matching.svg new file mode 100644 index 0000000..7394d29 --- /dev/null +++ b/_site/01_set/functions_matching.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/functions_one_after_another.svg b/_site/01_set/functions_one_after_another.svg new file mode 100644 index 0000000..a299f02 --- /dev/null +++ b/_site/01_set/functions_one_after_another.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/index.html b/_site/01_set/index.html new file mode 100644 index 0000000..f5af938 --- /dev/null +++ b/_site/01_set/index.html @@ -0,0 +1,376 @@ + + + + Category Theory Illustrated - 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.

+ +

Preface: 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. +Bertrand Russell, from Introduction to Mathematical Philosophy

+
+ +

Most scientific and mathematical theories have a specific domain, to which they are related, and in which they are valid. They are created with this domain in mind and are not intended to be used outside of it. For example, Darwin’s theory of evolution is created so it explains how different biological species came to be. And quantum mechanics is a description of what particles are at the low scale. Even the work of most mathematicians, although it is not bound to a specific domain, is strongly related to it, as differential equations are linked to the description of events that change over time.

+ +

Set theory and category theory are different. They are not created for to provide a rigorous explanation of how a particular phenonium works, but to try to provide a more general framework for explaining all kinds of phenomena. Theories that are like that are called abstract theories. All theories use abstraction, else they would be pretty useless (without it Darwin would have to speak about specific animal species or even individual animals) but few are inherently abstract, so some of their core concepts are left unspecified. Or in other words, all theories are applicable outside of their domains, but set theory and category theory do not have a domain, to begin with.

+ +

People have tried to be precise and at the same time down to Earth for centuries, and only recently discovered that “precise and down to Earth” is an oxymoron. Let’s take Euclidian geometry as an example. Yes, Euclidian geometry is precise, because it is valid for all sets of objects, called (“point” “line” “angle” and “circle” etc.), which have relationships, as defined by the five famous axioms. Yes, geometry does, in many instances, describe the natural world, because there are many sets of objects which have these relations. However, its “precise” part and it’s “down to Earth” part have nothing to do with each other. We can, for example, define a point as any stain on the floor of your room and that a line as a piece of duct tape, put on the same floor - that will be a completely valid application of the Euclidian laws, albeit not very useful one. Or we can try to use geometry to reason about points on the surface of the Earth, which is a very useful application, of geometry, however not of Euclidian geometry, because Euclidian geometry only describes points on a flat plane, and the Earth is not flat. You can argue that these are actually two separate theories there, which just happen to be perceived as one. You have the axioms, or the postulates on one hand, which are not useful for anything on their own, and you have applications in science and engineering which are somewhat based on them, but not quite.

+ +

Sets

+ +

Everything in set theory is defined in terms of sets. A set is a collection of things where the “things” can be anything you want. Consider, for example, these balls:

+ +

Balls

+ +

For example, let’s construct a set, call it G (as grey), consisting of all of them. This is how we can mark it:

+ +

The set of all balls

+ +

The example may look childish but in fact, this set is just as valid as any other set.

+ +

The things that are contained in the set are called its elements. A set is like a summary of its elements. It has no other structure, for example, there is not order, no ball goes before or after another, there are no members which are “special” with respect to their membership in the set. Two sets that contain the same elements are also the same.

+ +

The key insight about what a set it is that it enables you to reason about several things as if they were one.

+ +

Subsets

+ +

Let’s construct one more set. The set of all balls that are warm colour. I will call it Y, because in the diagram is coloured in yellow.

+ +

Y - the set of all balls of warm colours

+ +

Notice that Y contains just elements that are also present in G. That is, every element of the set of Y is also an element in the set G. When two sets have this relation, we may say that Y is a subset of G (or Y ⊆ G).

+ +

Y and G together

+ +

Singleton Sets

+ +

The set of all red balls contains just one ball.

+ +

The singleton set of red balls

+ +

Like we said above, sets are all about for summarising several elements into one. Still, sets that contain just one element are perfectly valid. Simply, there are things which are one of a kind. Furthermore, if I have a function which expects a set of given items, here shouldn’t be any issue if the “items” are just one item. Or to take a real-life example, the set of queens of England is a singleton set. The set of books written by the American writer Harper Lee and published during her lifetime is a singleton set - she has published just one novel.

+ +

The Empty set

+ +

Of course if one is a valid answer, so can be zero. If we want a set of all black balls B or all the white balls, W, the answer to all these questions is the same - the empty set. Or in other words.

+ +

The empty set

+ +

Note that a set is defined only by the items it contains, which means that there is no difference between the set that contains zero balls and the set that contains zero numbers, for instance. In other words, the empty set is unique set, which makes it a very special one. Formally, the empty set is marked with the symbol ∅ (so B = W = ∅).

+ + + + + + + + +
The empty set is a special one, for example, it is a subset of every other set (mathematically speaking, **∀ AA ⊆ ∅**)
+ +

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.

+ +
+

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)

+ +

Opposite colors

+ +

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).

+ +

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).

+ +

For example, a function can express a relationship in which several elements from the domain relate to the same element of the codomain.

+ +

Function from a bigger set to a smaller one

+ +

It can also express relationships in which some elements from the codomain do not play a part.

+ +

Function from a smaller set to a bigger one

+ +

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.

+ +

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

+ +

Question: Some people might say that the codomain 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. +Question: What is the codomain 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.

+ +

Question: Do all functions that we drew at the beginning express something? Do you think that a function should express something in order to be valid?

+ +

The Identity Function

+ +

For every set G, no matter what it represents, we can define the function that does nothing, or in other words, a function which maps every element G to itself. It is called the the identity function of G or idG: G → G.

+ +

The identity function

+ +

You can think of idG as a function which represents the set G in the realm of functions. Its existence allows us to prove many theorems, that we “know” by intuition, formally.

+ +

Functions and Subsets

+

For each set and subset, no matter what they represent, we can define the function that maps each element of the subset to itself:

+ +

Function from a smaller set to a bigger one

+ +

Every set is a subset of itself, in which case this function is the same as the identity.

+ +

Functions and the Empty Set

+ +

There is a unique function from the empty set to any other set.

+ +

Function with empty set

+ +

Question: Is this really valid? Why? Check the definition.

+ +

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?

+ +

Functions and Singleton Sets

+ +

There is a unique function from any set to any singleton set.

+ +

Function with a singleton set

+ +

Question: Is this really the only way to connect any set to a singleton set in a valid way?

+ +

Question: Again, what about the other way around?

+ +

Sets and Functions

+ +

Many things can be expressed as sets and functions, let’s examine some of them.

+ +

Sets and Functions in Numbers

+ +

All mathematical operations can be expressed as functions, acting on the set of numbers. Actually there are several such sets, such the set of positive whole numbers, (also called “natural” numbers), N := {1, 2, 3… ∞}, the set of both positive and negative whole numbers Z := {-∞… -3 -2, -1, 0, 1, 2, 3… ∞}. And the set of “Real” numbers which include all numbers that I know of.

+ +

For example, squaring a number is a function from the set of real numbers to the set of real positive numbers (because both sets are infinite, we cannot draw them in their entirety, however we can draw a part of them).

+ +

The square function

+ +

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.

    +
    • +
  • 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.
    • +
+ +

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:

+ +
+

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

+
+ +

Note that most mathematical operations, such as addition, multiplication etc. require two numbers in order to produce a result. This does not mean that they are not functions, it means that they are just a little more fancy ones. Depending on what we need, we may present those operations as functions from the sets of tuples of numbers to the set of numbers, or we may say that they take a number and return a function. More on that later.

+ +

Sets and Functions in Programming

+ +

Sets are used extensively in programming, especially in their incarnation as types (or also classes). All sets of numbers that we discussed earlier also exist in most languages as types, and there are also some non-mathematical types that play a huge role in programming.

+ +

The simplest type, Boolean is nothing more than a set of two values - true and false:

+ +

Set of boolean values

+ +

Another very basic set in programming is the set of keyboard characters, or Char:

+ +

Set of characters

+ +

Characters are actually used rarely by themselves and mostly as parts of sequences.

+ +

Most of the types of programming are composite types - they are a combination of the primitive types that are listed here. Again, we will cover these later.

+ +

Question: What is the type equivalent of subsets in programming?

+ +

Question: Do you recognise some of the basic functions we defined in programming languages you know?

+ +

Some functions in programming (also called methods, subroutines, etc.) kinda resemble mathematical functions - they sometimes take one value of a given type (or in other words, an element that belongs to a given set) and always return exactly one element which belongs to another type (or set). For example here is a function which that takes an argument of type Char and returns a Boolean, depending on whether the character is a letter.

+ +

A function from Char to Boolean

+ +

However functions in programming can also be quite different from mathematical functions - they can perform various operations that have nothing to do with returning a value, called side effects. This is because most common programming languages and paradigms which are in use today were created at times when the computer resources were much more limited than today, and programming - much more cumbersome, so people had bigger problems than the fact that their functions were not mathematically sound.

+ +

One type of functions used in programming which strongly resembles mathematical ones are those which convert a value from one type to another, for example, the function which converts a floating-point number to an Integer. That is probably the reason why most functional languages are strongly-typed.

+ +

Sets and Types

+ +

The concepts of types and sets are related. The concept of sets is simpler - in set theory you have only one kind of object that is (you guessed it) - set and a set can contain anything, including other sets. In type theory, you have two concepts - types and values. Types are like sets, in fact every type can be represented as a set of its values, but not every set is a type. Usually, the proper way to think about type is as a collection of values that share common characteristics. The definitions tend to vary between different type theories (of which there are a lot), but mostly go along the lines of:

+ +
    +
  • A type cannot contain other types, just values.
    • +
  • value can be a member of only one type (there exist the concept of are subtypes, just as there are subsets, but again things are more strict).
    • +
+ +

Russell’s Paradox

+ +

The first type theory was developed by Bertrand Russell in response to a paradox in the original set theory, arising due to the fact that, unlike types (which can only contain values), sets can contain other sets.

+ +

In particular, a set can contain itself.

+ +

A set that contains itself

+ +

Unlike the set above, most sets that we discussed (like the empty set and singleton sets) do not contain themselves.

+ +

Sets that don't contains themselves

+ +

In order to understand Russell’s paradox we will try to visualise the set all sets that do not contain themselves. In the original set notation we can define this set as Let R = { x => x ∉ x } (let R be such that it contains all sets x such that x is not a member of x).

+ +

Russel's paradox - option one

+ +

If we look at the definition, we recognise that the set that we just defined - R does not contain itself and therefore it belongs there as well.

+ +

Russel's paradox - option one

+ +

Hm, something is not quite right with this diagram as well - Because of the new adjustments that we made R contains itself. And removing it from the set would just bring us back to the previous situation. This is Russell’s paradox. There are, of couse, multiple theories that it does not apply to.

+ +

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.

+ +

Matching functions

+ +

If we apply the first function g to some element from set Y, we will get an element of the set P. Then, if we apply the second function f to that element, we will get an element from type G.

+ +

Applying one function after another

+ +

We can define a new function, that is the equivalent to performing the operation described above. Let us call it h: Y → G. We may say that h is the composition of g and f, or h = f ∘ g (notice that the first function is on the right, so it’s similar to b = f(g(a)).

+ +

Functional composition

+ +

Composition is the essence of all things categorical. The key insight is that the sum of two parts is no more complex than the parts themselves.

+ +

Question: The definition of functional composition (presented in the second paragraph) relies on the fact that functions are many-to-one relationships between sets. How could functional composition work for many-to-many relationships? Can it work at all?

+ +

Representing Composition with Commutative Diagrams

+ +

In the last diagram, the equivalence between f ∘ g and the new function h is expressed by the fact that if you follow the arrow h for any element of set Y you will get to the same element of the set G as the one you will get if you follow the g and then follow f. Diagrams that express such equivalence between sequences of function application are called commutative diagrams.

+ +

Functional composition

+ +

If we “zoom-out” the last diagram so it does not show the individual set elements, we get a more general view of functional composition.

+ +

Functional composition for sets

+ +

In fact, because this diagram commutes (that is, all arrows, starting from a given set element ultimately lead to the same corresponding element from the resulting set), enumerating the elements is redundant. Having this insight allows us to redefine functional composition in the following, more visual, way:

+ +

The composition of two functions f and g is a third function h defined in such a way that this diagram commutes.

+ +

Functional composition - general definition

+ +

This is called an external diagram, by the way (and the ones that we saw before are internal).

+ +

The Power of Composition

+ +

To understand how powerful composition is, consider the following: one set being connected to another means that each function from the second set can be transferred to a corresponding function from the first one.

+ +

If we have a function g: P → Y ** from set **P to set Y, then for every function f from the set Y to any other set, there is a corresponding function f ∘ g from the set P to the same set. In other words, every time you define a new function from Y to some other set, you gain one function from P to that same set for free.

+ +

Functional composition connect

+ +

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.

+ +

Isomorphisms

+ +

Let’s go back to the function that demonstrated a one-to-one relationship.

+ +

Opposite colors

+ +

Notice that the function is invertible, that is if you flip its arrows you get another valid function:

+ +

Opposite colors

+ +

Invertible functions are called isomorphisms. When there is an invertible function between two sets we can say that the sets are isomorphic. For example, the temperature measured in Celcius is isomorphic to the temperature, measured in Fahrenheit.

+ +

More formally, two sets R and G are isomorphic, or R ≅ G if there exist functions f: G → R and its reverse g R → G, such that f ∘ g = idR and g ∘ f = idG (notice how the identity function comes in handy).

+ +

Isomorphism and equality

+ +

In category theory, the concept of an isomorphism is strongly related to the concept of equality (that is why it is denoted with ≅, which is almost the same as =). This is also related to programming, where if we have a function that convert our object of type A to an object of type B and the other way around we pretty much regard A and B as two formats of the same object.

+ +

For example, we all know that everything is equal to itself. Well, if you look closely you would see that the identity function is reversible (its reverse is itself), so each set is also isomorphic to itself.

+ +

The identity function

+ +

Note that an isomorphism between two sets does not imply that their elements are similar to one another, as some of the examples might suggest. It rather implies that they have similar structure, in other words, a function that involves one of the sets, can easily be converted to a function involving the other set.

+ +

The architecture of isomorphism

+ +

For example, if you have a function “is the husband of” that goes from the set of all married men to the set of all married women, and the corresponding function, “is the wife of”, that would make the sets of married men and married woman isomorphic (ignoring some exceptions). That is not to say that you are the same person as your significant other, but rather that every statement about you, or every relation you have to some other person or object is also a relation between him/her and the same person or object, and vice versa.

+ +

Isomorphisms Between Singleton Sets

+ +

Between any two singleton sets, we may define the only possible function.

+ +

The only possible function between sungletons

+ +

The function is invertible, which means that all singleton sets are isomorphic to one another.

+ +

Isomorphic singletons

+ +

Following the logic from the last paragraph, each statement about something that is one of a kind can be transferred to a statement about another thing that is one of a kind.

+ +

Question: Try to come up with a good example that shows how a statement that demonstrates the isomorphism between singleton sets (I obviously couldn’t). Consider that all of people and objects are sharing one and the same universe.

+ +

Task: Think of two singleton sets, and try to pinpoint the relation that they have.

+ + +
+ + + + + + +
+
+
+
+

Contents

+ +

About this book

+ +

Sets

+ +

From Sets to Categories

+ +

Monoids etc

+ + +
+
+ + + + diff --git a/_site/01_set/isomorphism_general.svg b/_site/01_set/isomorphism_general.svg new file mode 100644 index 0000000..b79f76f --- /dev/null +++ b/_site/01_set/isomorphism_general.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/isomorphism_identity.svg b/_site/01_set/isomorphism_identity.svg new file mode 100644 index 0000000..80963ce --- /dev/null +++ b/_site/01_set/isomorphism_identity.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/isomorphism_one_one.svg b/_site/01_set/isomorphism_one_one.svg new file mode 100644 index 0000000..c795be6 --- /dev/null +++ b/_site/01_set/isomorphism_one_one.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/morphism_general.svg b/_site/01_set/morphism_general.svg new file mode 100644 index 0000000..adab430 --- /dev/null +++ b/_site/01_set/morphism_general.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/russells_paradox.svg b/_site/01_set/russells_paradox.svg new file mode 100644 index 0000000..f59098d --- /dev/null +++ b/_site/01_set/russells_paradox.svg @@ -0,0 +1,754 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/01_set/russells_paradox_2.svg b/_site/01_set/russells_paradox_2.svg new file mode 100644 index 0000000..1e976f5 --- /dev/null +++ b/_site/01_set/russells_paradox_2.svg @@ -0,0 +1,2184 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/01_set/set_contains_itself.svg b/_site/01_set/set_contains_itself.svg new file mode 100644 index 0000000..fadfd66 --- /dev/null +++ b/_site/01_set/set_contains_itself.svg @@ -0,0 +1,260 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/01_set/set_subset.svg b/_site/01_set/set_subset.svg new file mode 100644 index 0000000..f8056a7 --- /dev/null +++ b/_site/01_set/set_subset.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/sets_dont_contain_themselves.svg b/_site/01_set/sets_dont_contain_themselves.svg new file mode 100644 index 0000000..4352bf0 --- /dev/null +++ b/_site/01_set/sets_dont_contain_themselves.svg @@ -0,0 +1,741 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/01_set/singleton.svg b/_site/01_set/singleton.svg new file mode 100644 index 0000000..1a744d8 --- /dev/null +++ b/_site/01_set/singleton.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/singleton_function.svg b/_site/01_set/singleton_function.svg new file mode 100644 index 0000000..243e97c --- /dev/null +++ b/_site/01_set/singleton_function.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/singleton_isomorphism.svg b/_site/01_set/singleton_isomorphism.svg new file mode 100644 index 0000000..e050038 --- /dev/null +++ b/_site/01_set/singleton_isomorphism.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/square.svg b/_site/01_set/square.svg new file mode 100644 index 0000000..50effd0 --- /dev/null +++ b/_site/01_set/square.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/subset.svg b/_site/01_set/subset.svg new file mode 100644 index 0000000..44d8929 --- /dev/null +++ b/_site/01_set/subset.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/01_set/void.svg b/_site/01_set/void.svg new file mode 100644 index 0000000..2d09c16 --- /dev/null +++ b/_site/01_set/void.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/arrows.svg b/_site/02_category/arrows.svg new file mode 100644 index 0000000..2f3f667 --- /dev/null +++ b/_site/02_category/arrows.svg @@ -0,0 +1,120 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + diff --git a/_site/02_category/category.svg b/_site/02_category/category.svg new file mode 100644 index 0000000..f20b45b --- /dev/null +++ b/_site/02_category/category.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/composition.svg b/_site/02_category/composition.svg new file mode 100644 index 0000000..89da52c --- /dev/null +++ b/_site/02_category/composition.svg @@ -0,0 +1 @@ + diff --git a/_site/02_category/composition_arrows.svg b/_site/02_category/composition_arrows.svg new file mode 100644 index 0000000..835cff4 --- /dev/null +++ b/_site/02_category/composition_arrows.svg @@ -0,0 +1 @@ + diff --git a/_site/02_category/composition_associativity.svg b/_site/02_category/composition_associativity.svg new file mode 100644 index 0000000..c09dda0 --- /dev/null +++ b/_site/02_category/composition_associativity.svg @@ -0,0 +1,310 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + f + g + h + + + + + + + h • g + g • f + h • g • f + diff --git a/_site/02_category/composition_commuting_diagram.svg b/_site/02_category/composition_commuting_diagram.svg new file mode 100644 index 0000000..5b8bf55 --- /dev/null +++ b/_site/02_category/composition_commuting_diagram.svg @@ -0,0 +1 @@ + diff --git a/_site/02_category/composition_n_objects.svg b/_site/02_category/composition_n_objects.svg new file mode 100644 index 0000000..d582f4e --- /dev/null +++ b/_site/02_category/composition_n_objects.svg @@ -0,0 +1,228 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/02_category/coproduct.svg b/_site/02_category/coproduct.svg new file mode 100644 index 0000000..e68e3b8 --- /dev/null +++ b/_site/02_category/coproduct.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_candidates.svg b/_site/02_category/coproduct_candidates.svg new file mode 100644 index 0000000..7bae2a1 --- /dev/null +++ b/_site/02_category/coproduct_candidates.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_external.svg b/_site/02_category/coproduct_external.svg new file mode 100644 index 0000000..8179f31 --- /dev/null +++ b/_site/02_category/coproduct_external.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_member.svg b/_site/02_category/coproduct_member.svg new file mode 100644 index 0000000..6caa3de --- /dev/null +++ b/_site/02_category/coproduct_member.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_member_set.svg b/_site/02_category/coproduct_member_set.svg new file mode 100644 index 0000000..546db16 --- /dev/null +++ b/_site/02_category/coproduct_member_set.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_morphisms.svg b/_site/02_category/coproduct_morphisms.svg new file mode 100644 index 0000000..4096925 --- /dev/null +++ b/_site/02_category/coproduct_morphisms.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/coproduct_product_duality.svg b/_site/02_category/coproduct_product_duality.svg new file mode 100644 index 0000000..33606c0 --- /dev/null +++ b/_site/02_category/coproduct_product_duality.svg @@ -0,0 +1 @@ +ANDOR \ No newline at end of file diff --git a/_site/02_category/elements.svg b/_site/02_category/elements.svg new file mode 100644 index 0000000..ed6549b --- /dev/null +++ b/_site/02_category/elements.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/identity.svg b/_site/02_category/identity.svg new file mode 100644 index 0000000..d1472b4 --- /dev/null +++ b/_site/02_category/identity.svg @@ -0,0 +1 @@ +ID diff --git a/_site/02_category/index.html b/_site/02_category/index.html new file mode 100644 index 0000000..2c813b7 --- /dev/null +++ b/_site/02_category/index.html @@ -0,0 +1,400 @@ + + + + Category Theory Illustrated - From Sets to Categories + + + + + +
+
+ +
+
+
+ +

From Sets to Categories

+ +

In this chapter we will continue with set theory and at the same time we will start exploring categories, and talking about why they are important.

+ +

Products

+ +

In the previous chapter, we needed a way to make a set that is a composite of other sets that we already have. For example when we discussed mathematical functions, we couldn’t define + and - functions, because we only knew about functions that take one argument. When we talked about programming, we talked about the primitive types, Char and Number, and we mentioned that most of the types are composite types. So how do we construct those?

+ +

The simplest composite type, of the sets B, which contains b’s and the setY, which contains y’s is the the product or B and Y.

+ +

Product parts

+ +

It is the set of pairs of b’s and y’s.

+ +

Product

+ +

The product is denoted B x Y and it comes equipped with two functions for retrieving the b and the y from each (b, y).

+ +

Question: Why is this called a product? Hint: How many elements does it have?

+ +

Products as Objects

+ +

We established that in programming sets resemble types and functions resemble functions. Products, in this case, are like stripped-out classes (also called records or structs). The composite sets (the ones which form the product) are just the class’s fields (also called members). The functions for accessing them are like what programmers call getter methods.

+ +

For example the famous OOP example of Person class with name and age fields is nothing more than a product of the set of strings, and the sets of numbers (we still haven’t defined strings and lists in terms of set theory but we will get to that). Objects with more than two values can be expressed as products the composites of which are themselves products.

+ +

Using Products to Define Numeric Operations

+ +

Products can also be used for expressing functions which take more than one argument. For example, “plus” and “minus”, are functions from the set of products of two numbers to the set of numbers. (so +: R x R → R). Of course, we cannot draw the function itself, even partly, because it has too much arrows and it would look messy.

+ +

Joking, here it is.

+ +

The plus function

+ +

Note that there are languages where the pair datastructure (also called a tuple) is a first-level construct, and multi-argument functions are really implemented in this way.

+ +

Defining products in Terms of Sets

+ +

Now we will define the abstract concept of a product of two sets sets in terms of sets themselves. It is not hard: the product of two sets Y and B is just the set of all possible ordered pairs, which contain one element of the set Y and one element of the set B. Or formally speaking Y x B = { (y, b) } where y ∈ Y, b ∈ B (∈ means “is an element of”).

+ +

A pair

+ +

The real challenge is defining what a pair means in terms of sets. Note that the pair have to be ordered, so it cannot be just a set of the elements (formally speaking **A x B ≠ B x A for all A and B **). Some mathematical operations such as addition and multiplication don’t care about order, but others, such as subtraction, do. And in programming we have the ability to assign names to each member of an object, which accomplishes the same purpose as ordering does for pairs.

+ +

So the pair must be ordered, and sets aren’t. Turns out that that hasn’t stopped mathematicians from coming up with multiple ingenious ways to represent an ordered pair using sets. Let’s see them, just for fun. Here is the first one, which was discovered by Norbert Wiener in 1914. The definition is notable for its smart use of the uniqueness of the empty set.

+ +

A pair, represented by sets

+ +

The next one was discovered in the same year by Felix Hausdorff. In order to use that one, we just have to define “1”, and “2” first.

+ +

A pair, represented by sets

+ +

Discovered in 1921 Kazimierz Kuratowski, this one uses just the component of the pair.

+ +

A pair, represented by sets

+ +

Defining products in Terms of Functions

+ +

In the previous chapter we provided a definition of a product by zooming in the individual elements of the sets and seeing what they can be made of. This gave us a low-level view of products. This time we will try to do the opposite - be as oblivious to the contents of our sets as possible. Instead of zooming in we will zoom out, and try define the product in terms of functions and functional composition. Effectively we will be working at a higher level of abstraction.

+ +

So let’s begin with an external diagram, showing the definition of the product. Disclaimer: I know that this is a somewhat weird notation, but don’t worry, we will not be using it for very long.

+ +

Product, external diagram

+ +

This diagram already contains the first piece of the puzzle: if we have a set G which is the product of sets Y and B, then we should also have functions which give us back the elements of the product, so G → Y and G → B.

+ +

This definition is not complete, however, because the product of G and B is not the only set for which such functions can be defined. For example:

+ +
    +
  • +

    A set of triples of Y x B x R for any random element R also qualifies.

    +
    • +
  • +

    If there is a function from G to B then the set G itself meets our condition for being the product, because it is connected to B and to itself.

    +
    • +
+ +

Depending on our specific case there can be many other other such objects.

+ +

Product, external diagram

+ +

So how do we set apart all those “imposter” products from the one true product? Simple - they all can be converted to it. This is true, because:

+
    +
  1. By definition, each “impostor” can be converted to both elements of the pair.
    2. +
  2. The pair is nothing more than the sum of its elements.
    3. +
+ +

More formally, in order for a set I to serve as an impostor for the product of B and Y and there should be two functions, which we will call b: I → B and y: I → Y. In order to prove that I is an impostor we need a function I → B x Y. That function is simply (programmers will understand this best) (a) → b(a) x y(a) for each a:I.

+ +

Product, external diagram

+ +

Notice that this definition does not rule out the sets which are isomorphic to the product - when we represents things using functions, an isomorphism is the same as equality.

+ +

Sums

+ +

We will now study a construct that is pretty similar to the product but at the same time it is very different. Similar because, like the product, it is a relation between two sets which allows you to unite them into one without erasing their structure. Different because it encodes a different type of relation between them - a product encodes an AND relation between two sets, while the sum encodes an OR relation. For example, a parent is either a mother of a father of a child, so the set of parent’s is a sum set of the sets of mothers and fathers.

+ +

Sum or coproduct

+ +

Notice that the when a given object is an element of both sets, then it appears in the sum twice. This is why this type of sum of two sets is also called a disjoint union.

+ +

Question: Why is this called a sum?

+ +

Defining Sums in Terms of Sets

+ +

Simply put, a sum of two sets is a set that contains all elements from the first set and all elements from the second one. But, as with the product, it is not so straightforward to represent sums in terms of sets. For example if two sets can have the same element as a member, their sum will have that element twice which is not permitted, because a set cannot contain the same element twice.

+ +

As with the product, the solution is to put some extra structure.

+ +

A member of a coproduct

+ +

Like with the product, there is a low-level way to express a sum using sets alone. Incidentally, we can use pairs.

+ +

A member of a coproduct, examined

+ +

But again, this distinction is only rellevant only when the two sets have common elements.

+ +

Defining Sums in Terms of Functions

+ +

You might already suspect, the interesting part is expressing the sum of two sets using functions. To do that we have to go back to the conceptual part of the definition. We said that sums express an OR relation between two things. A simple property of every OR relation is that if something is an A that something is also an A OR B (and the same is valid if it is B). For example if I am a man, I am also a man OR a woman. This is what OR means, right?

+ +

This relationship can be expressed as a function. Two functions actually - one for each set that takes part in the relation.

+ +

Coproduct, external diagram

+ +

Why can it be expressed as a function? Because it is a many-to-one relationship.

+ +

What are we saying with this, if we apply it to the example, is simply that if parents are either mothers or fathers, then there surely exist a functions mothers → parents and fathers → parents.

+ +

You might already notice that this definition is pretty similar to the previous one, and the similarities don’t end here - here again we have sets that can be thought as impostor sums - ones for which these functions exists, but which aren’t real sums (where by “real sum” we mean a set which expresses the OR relation and contains no additional structure).

+ +

Coproduct, external diagram

+ +

All these sets are, express relationships which are more vague than the simple sum and therefore given any such set there would exist a function from the sum to it.

+ + + + + + + + + + +
For exaple, there exist a trivial function between the set **YB ** and the set **YBR**.
+ +

Coproduct, external diagram

+ +

This diagram captures the OR relation in the same way as the previous one captures the essence of AND.

+ +

Duality

+ +

If we have to compare the concepts of sum or and product we will find out that they are related:

+ +
    +
  • The product of two sets is related to an element of the first one and one element of the second one.
    • +
  • A sum of two sets is related to an element of the first one or one element of the second one.
    • +
+ +

Actually, the two concepts are captured by one and the same external diagram, just the arrows are flipped - many-to-one relationships become one-to-many and the other way around.

+ +

That’s normal right? After all, AND is the opposite of OR. The connection between the two has always been there, evidenced, for example, by the De Morgan’s law, citing that NOT (A AND B) ↔ (NOT A) OR (NOT B) (or to put it in everyday language, “If either A or B is false, then (and only then) A and B is also false). But only with category theory, this connection can be expressed in such a concise way:

+ +

Coproduct and product

+ +

Otherwise, when in category theory two concepts are captured by the same diagram, only with reversed arrows, we can say that the two concepts are dual to each other. That means that the concepts of product and sum are dual (this is why sum is also known as converse product, or coproduct in short).

+ +

Category Theory - brief definition

+ +

Maybe it is time to see what a category is. Well, a category consists of objects (an example of which are sets) and morphisms which go from one object to another (which can be viewed as functions) and which should be composable. We can say a lot more about categories, and even present a formal definition, but for now it is suffice for you to remember that sets are one example of a category and that categorical objects are like sets, except that we don’t see their elements. This is why category-theoretic notions being captured by the external diagrams and strictly set-theoretic notions being captured by internal ones.

+ +

What other categories, or applications of category theory are there, other than sets? We already discussed one - types in programming languages. Remember that we said that programming types (classes) are somewhat similar to sets and programming functions are somewhat similar to functions between sets? This is another example of a connection between two things that we can be defined using category theory:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Category TheorySet theoryProgramming Languages
CategoryN/AN/A
Objects and MorphismsSets and FunctionsClasses and functions
N/AElementObject
+ +

This diagram illustrates how category theory allows us to see the big picture when it comes to sets and similar structures - when we are at the realm of sets we can view the set as a collection of individual elements. In category theory we don’t have such notion, but we saw how taking this notion away allows us to define concepts such as the sum and product sets in a whole different and more general way.

+ +

NB: Do note how the world “Object” is used in both programming languages and in category theory, but for completely different things. The equivalent a categorical object is equivalent to a class in programming language.

+ +

Looking at the table I cannot help but notice the somehow weird, but otherwise completely logical symmetry (or perhaps “reverse symetry”) between the the world as viewed through the lense of set theory, and the way it is viewed through the (inverted) lens of cathegory theory:

+ + + + + + + + + + + + + + + + + + + + + + +
Category TheorySet theory
CategoryN/A
Objects and MorphismsSets and functions
N/AElement
+ +

By switching to external diagrams, we lose sight of the particular (the elements of our sets), but we have gained the ability to see the whole universe that we have been previously trapped in. The whole realm of sets, can be thought as one category, a programming language can also be thought as a category. The concept of a category allows us to find and analyse similarities between these and other structures.

+ +

Category theory and set theory compared

+ +

One remark before we go - the last paragraphs I sound as if I’m comparing categories and sets and rooting for categories. I don’t want you to get the wrong impression that the two concepts are somehow competing with one another.

+ +

Perhaps that notion would be somewhat correct if category and set theory were meant to describe concrete phenomena, in the way that the theory of relativity and the theory of quantum mechanics in physics. Concrete theories are conceived mainly as descriptions of the world, and as such it makes sense for them to be connected to one another in some sort of hierarchy. Abstract theories, like category theory and set theory, on the other hand, are more like languages for expressing such descriptions. They still can be connected, and are connected in more than one way, but there is no inherent hierarchy between the two and therefore arguing over which of the two is more basic, or more general, is just a chicken-and-egg problem, as you would see in the next chapter.

+ +

Defining Categories

+ +

Every category theory guide (including mine) starts by talking about set theory. However, looking back, I really don’t know why that is the case - surely most other books that focus around a specific subject don’t start by introducing an entirely different subject. Perhaps the set-first approach is the best way to introduce people to categories. or perhaps using sets to introduce categories is just one of the things that people just do, simply because everyone else does it. But one thing is for sure - we don’t need to study sets in order to understand categories. So in this chapter I would like to start over and talk about categories as a first concept. So pretend like it’s a new book:

+ +

Starting over with categories

+ +

So, a category is a collection of objects (things) where the “things” can be anything you want. Consider, for example, these colourful grey balls:

+ +

Balls

+ +

A category consists of a collection of objects as well as some arrows connecting some of them to one another, that we call (the arrows) morphisms.

+ +

A category

+ +

Wait a minute - we said that all sets form a category, but at the same time any one set can be seen as a category on its own right (just one which has no morphisms). This is true and an example of a phenomenon that is very characteristic of category theory - one structure can be examined from many different angles and may play many different roles, often in a recursive fashion.

+ +

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.

+ +

Two objects connected with multiple arrows

+ +

Why is that is pretty obvious if we go back to set theory for a second (OK, maybe we really have to do this from time to time) - there are, for example, an infinite number of functions that go from number to boolean and the fact that they have the same input type and the same output type (or the same type signature, as we like to say) does not in any way make them equivalent to one another.

+ +

Two sets connected with multiple functions

+ +

Composition

+ +

One of the few, or maybe even the only, requirement for a structure to be called a category is that two morphisms can make a third, or in other words that morphisms are composable - given two successive arrows with appropriate type signature, we can draw a third one that is equivalent to the consecutive application of the other two.

+ +

Composition of morphisms

+ +

Formally, this requirement says that there should exist an operation (denoted with the symbol •) such that for each two functions g: A → B and f: B → C, there exists exactly one function (f • g): A → C.

+ +

NB: Note that functional composition is written from right to left. e.g. applying g and then applying f is written f • g and not the other way around (you can think of it as a shortcut to f(g(a))).

+ +

Again, note that this criteria is not met by just any morphism with this type signature. There is exactly one morphism that fits these criteria and there may be some which don’t.

+ +

Composition of morphisms in the context of additional morphism

+ +

Commuting diagrams

+ +

The diagram above, uses colors to illustrate the fact that the green morphism is equivalent to the other two (and not just some unrelated morphism), but in practice this notation is a little redundant - the only reason to draw diagrams with arrows in the first place is represent paths between objects that are equivalent to each other, all other paths just belong in different diagrams. For this reason, we can drop the colors from our diagrams.

+ +

Composition of morphisms - a commuting diagram

+ +

Diagrams that are like that (ones in which any two paths between two objects are equivalent to one another) are called commutative diagrams (or diagrams that commute). All diagrams that we have here (except the wrong ones) commute.

+ +

The law of associativity

+ +

Functional composition is special not only because you can take any two morphisms with appropriate signatures and make a third, but because you can do so indefinitely, i.e. given n successive arrows, each of which starts from the object that the other one finishes, we can draw one (exactly one) arrow that is equivalent to the consecutive application of all n arrows.

+ +

Composition of morphisms with many objects

+ +

This approach for building stuff is often used in programming. To see some examples, you don’t need to look further than the way the pipe operator in bash (|), that feeds the standard output of a program with the standard input of another program, is (ab)used (if you want to look further, note that there is a whole programming paradigm based on functional composition, called “concatenative programming”).

+ +

But let’s get back to the math. If we carefully review the definition above can see that it can be reduced to multiple applications of the following formula: given 4 objects and 3 morphisms between them f g h, combining h and g and then combining the end result with f** should be the same as combining h to the result of g and f (or simply (h • g) • f = h • (g • f).

+ +

Task: show how the definition can be reduced to the formula (the approach resembles mathematical induction).

+ +

This formula is true if and only if this diagram commutes.

+ +

Composition of morphisms with many objects

+ +

Given that all our category-theoretic diagrams commute, we can say, in such cases, that the formula and the diagram are equivalent.

+ +

This formula (and the diagram) is the definition of a property called associativity. Being associative is required for functional composition to really be called functional composition (and for a category to really be called category), if only because it is required for us to be able to draw diagrams of a category’s objects and morphisms, as diagrams can only represent associative structures (if the diagram above does not commute it would be super weird).

+ +

Associativity is not just about diagrams, for example when we express relations using formulas, associativity just means that brackets don’t matter, in our formulas (as evidenced by the definition (h • g) • f = h • (g • f)). And it is not only about categories either, it is a property of many other operations on other types of objects as well e.g. if we look at numbers, we can see that the multiplication operation is associative e.g. (1 . 2) . 3 = 1 . (2 . 3). While division is not (1 / 2) / 3 = 1 / (2 / 3).

+ +

Identity

+ +

Ancient mathematicians invented the number zero that, although useless by itself, allowed them to define many useful numbers. In order to be able to define more stuff using morphisms in category theory, we too would want to define what we call the “identity morphism” for each object. In short, this is a morphism, that doesn’t do anything.

+ +

The identity morphism (but can also be any other 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 domain and codomain, 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?

+ +

Why do we need to define a morphism that does nothing?

+ +

Isomorphisms

+ +

Once we have the concept of identity morphism defined we can have a category-theoretic definition of an isomoprhism (which is important, because the concept of an isomorphism is very important for cathegory theory): An isomorphism between two objects (A and B) consists of two morphisms - (A → B. and B → A) such that their compositions are equivalent to the identity functions of the respective objects.

+ +

Here is how this looks when expressed using a formulas:

+ +

Objects A and B are isomorphic +iff there exist mophisms +f: A → B +g: B → A +such that
+f • g = idB +g • f = idA

+ +

And here is the same thing expressed with a commuting diagram.

+ +

Isomorphism

+ +

Like the example with the law of associativity, the diagram expresses the same (simple) fact as the formula, namely that going from the one of objects (A and B) to the other one and then back again is the same as applying the identity morphism i.e. doing nothing.

+ +

A summary

+ +

For future reference, let’s repeat what a category is.

+ +

A category is a collection of objects (we can think of them as points) and morphisms (arrows) that go from one object to another, where:

+
    +
  1. There should be a way to compose two morphisms with an appropriate type signature into a third one in a way that is associative.
    2. +
  2. Each object has to have the identity mophism.
    3. +
+ +

This is it.

+ + +
+ + + + + + +
+
+
+
+

Contents

+ +

About this book

+ +

Sets

+ +

From Sets to Categories

+ +

Monoids etc

+ + +
+
+ + + + diff --git a/_site/02_category/isomorphism.svg b/_site/02_category/isomorphism.svg new file mode 100644 index 0000000..9335e67 --- /dev/null +++ b/_site/02_category/isomorphism.svg @@ -0,0 +1 @@ +IDID \ No newline at end of file diff --git a/_site/02_category/pair.svg b/_site/02_category/pair.svg new file mode 100644 index 0000000..2380cce --- /dev/null +++ b/_site/02_category/pair.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/pair_as_set_1.svg b/_site/02_category/pair_as_set_1.svg new file mode 100644 index 0000000..1ca79d1 --- /dev/null +++ b/_site/02_category/pair_as_set_1.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/pair_as_set_2.svg b/_site/02_category/pair_as_set_2.svg new file mode 100644 index 0000000..2898509 --- /dev/null +++ b/_site/02_category/pair_as_set_2.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/pair_as_set_3.svg b/_site/02_category/pair_as_set_3.svg new file mode 100644 index 0000000..bd3d199 --- /dev/null +++ b/_site/02_category/pair_as_set_3.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/plus.svg b/_site/02_category/plus.svg new file mode 100644 index 0000000..0a5d7d8 --- /dev/null +++ b/_site/02_category/plus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/product.svg b/_site/02_category/product.svg new file mode 100644 index 0000000..693ce5c --- /dev/null +++ b/_site/02_category/product.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/product_candidates.svg b/_site/02_category/product_candidates.svg new file mode 100644 index 0000000..10253e0 --- /dev/null +++ b/_site/02_category/product_candidates.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/product_external.svg b/_site/02_category/product_external.svg new file mode 100644 index 0000000..af3420f --- /dev/null +++ b/_site/02_category/product_external.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/product_parts.svg b/_site/02_category/product_parts.svg new file mode 100644 index 0000000..926acdd --- /dev/null +++ b/_site/02_category/product_parts.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/products_morphisms.svg b/_site/02_category/products_morphisms.svg new file mode 100644 index 0000000..cca420b --- /dev/null +++ b/_site/02_category/products_morphisms.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/02_category/set_arrows.svg b/_site/02_category/set_arrows.svg new file mode 100644 index 0000000..ea530b1 --- /dev/null +++ b/_site/02_category/set_arrows.svg @@ -0,0 +1,205 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + isEven + isOdd + isPrime + >0 + + number + boolean + + + diff --git a/_site/02_category/set_category.svg b/_site/02_category/set_category.svg new file mode 100644 index 0000000..700011e --- /dev/null +++ b/_site/02_category/set_category.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_site/03_monoid/addition_commutative.svg b/_site/03_monoid/addition_commutative.svg new file mode 100644 index 0000000..5ba418d --- /dev/null +++ b/_site/03_monoid/addition_commutative.svg @@ -0,0 +1,201 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + x + x + + = + + + + y + + y + + + + x + x + + + y + + y + + + diff --git a/_site/03_monoid/balls.svg b/_site/03_monoid/balls.svg new file mode 100644 index 0000000..cf2e738 --- /dev/null +++ b/_site/03_monoid/balls.svg @@ -0,0 +1,132 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/balls_arithmetic.svg b/_site/03_monoid/balls_arithmetic.svg new file mode 100644 index 0000000..512d28b --- /dev/null +++ b/_site/03_monoid/balls_arithmetic.svg @@ -0,0 +1,238 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/balls_associativity.svg b/_site/03_monoid/balls_associativity.svg new file mode 100644 index 0000000..3c7b76b --- /dev/null +++ b/_site/03_monoid/balls_associativity.svg @@ -0,0 +1,251 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/balls_identity.svg b/_site/03_monoid/balls_identity.svg new file mode 100644 index 0000000..5c59d8a --- /dev/null +++ b/_site/03_monoid/balls_identity.svg @@ -0,0 +1,115 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/balls_rule.svg b/_site/03_monoid/balls_rule.svg new file mode 100644 index 0000000..f854dcb --- /dev/null +++ b/_site/03_monoid/balls_rule.svg @@ -0,0 +1,115 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/index.html b/_site/03_monoid/index.html new file mode 100644 index 0000000..1b2d186 --- /dev/null +++ b/_site/03_monoid/index.html @@ -0,0 +1,196 @@ + + + + Category Theory Illustrated - Monoids etc + + + + + +
+
+ +
+
+
+ +

Monoids etc

+ +

Since we are done with categories, let’s look at some other structures that are also interesting - monoids. Like categories, monoids/groups are also abstract systems consisting of objects and rules for manipulating these objects.

+ +

What are monoids

+ +

Monoids are simpler than categories. A monoid is defined by a collection (set) of elements and an operation that allows us to combine two element and produce a third one of the same kind.

+ +

Let’s take our familiar colourful balls.

+ +

Balls

+ +

In this case a monoid would be a rule (operation) for “combining” two balls into one.

+ +

An example of such rule would be blending the colors of the balls, as if we are mixing paint.

+ +

A rule for combining balls

+ +

You can probably think of other ways to define such a rule. This will help you realize that there can be many ways to create a monoid from a given set of items. The monoid is not the set itself, it is the set together with the rule.

+ +

Associativity

+ +

The monoid rule should, like functional composition, be “associative” i.e. applying it on the same number of elements in a different order should make no difference.

+ +

Associativity in the color mixing operation

+ +

When a rule is associative, this means we can use all kinds of algebraic operations to any sequence of terms (or in other words to apply equation reasoning), like for example we can add or remove a term that is present at both sides of an equation and retaining the equality of the existing terms:

+ +

Associativity in the color mixing operation

+ +

The identity element

+ +

Actually, not any (associative) rule for combining elements makes the balls form a monoid (it makes them form a “semigroup”, which is also a thing, but that’s a separate topic). In order to be a monoid, a set must feature what is called an “identity element” of a given rule (or a zero element, if you prefer) - one that, when combined with any other element gives back that same element not the identity but the other one. Or simply x • i = x and i • x = x for any x. In the case of our color-mixing monoid the identity element is the color white, represented by the white ball:

+ +

The identity element of the color-mixing monoid

+ +

As you probably remember from the last chapter, functional composition is also associative and it also contains an identity element, so you might start suspecting that it forms a monoid in some way. And it is really the case with one little caveat.

+ +

To keep the suspense alive, let’s see some simpler monoids before we dwelve into that:

+ +

Basic monoids

+ +

Monoids from numbers

+ +

Mathematics is not all about numbers, however numbers do tend to pop up in most of its areas and monoids are no exception. The set of natural numbers N form a monoid when combined with the all too familiar operation of addition (or to use the official terminology N form a monoid under addition).

+ +

The monoid of numbers under addition

+ +

(if you see a 1 + 1 = 2 in your texbook you know you are working on math foundations (or you are in kindergarden)).

+ +

The natural numbers also form a monoid under multiplication as well:

+ +

The monoid of numbers under multiplication

+ +

Task: Which are the identity elements of those monoids?

+ +

Task: Go through other mathematical operations and figure out why don’t they are not monoidal.

+ +

Monoids from boolean operations

+ +

Thinking about other operations that we covered (operation being a function which takes a pair of element of a given type and returns one element of the same type), we may remember the boolean operations AND and OR. which operate on the set, consisting of just two values { True, False }. Those operations form monoids too. Proving that they do is easy enough by just ennumerating all cases.

+ +

We can prove that AND is associative by expanding the formula (A AND B) AND C = A AND (B AND C) in all possible ways:

+ +

(TRUE AND FALSE) AND TRUE = TRUE AND (FALSE AND TRUE)

+ +

(TRUE AND FALSE) AND FALSE = TRUE AND (FALSE AND FALSE)

+ +

(FALSE AND FALSE) AND TRUE = FALSE AND (FALSE AND TRUE)

+ +

…

+ +

And we can prove that TRUE is the identity element by expanding the other formulas that state that for all elements A I AND A = A

+ +

FALSE AND TRUE = FALSE

+ +

TRUE AND TRUE = TRUE

+ +

…and then do the same for A AND I = A.

+ +

Intuitions

+ +

In order to form the correct intuition about monoids, try to avoid thinking of the elements in the set as objects, but instead think of them as actions. For example, when thinking about numbers don’t think of them as quantities (as in two apples, two oranges etc.), but as operations, (e.g. as the action of addding one to a given quantity). In other words, don’t think of the element by itself, but only think of it together with the operation (in this case addition).

+ +

This touches a programming concept which is very popular in category-theory inspired languages - currying - that is based on the idea that a function that accepts two arguments together with one of those arguments already supplied can be viewed as a function which takes one argument. e.g. the function add(number, number) together with the element 2 is equivalent to the addTwo(number) function.

+ +

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 solemnly 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 in the actions (and objects) can be anything, from mixing colors in paint, or adding a quantities to a given set of things etc.

+ +

Other monoid-like objects

+ +

Monoid operations obey only one law - they are associative (two, if you count the existence of the identity element). In some cases we come across operations that also obey other rules that are also interesting. Imposing more (or less) rules to the way in which actions are combinded results in the definition of other monoid-like structures.

+ +

Commutative monoids

+ +

Looking at the monoid laws and the examples we gave so far, we observe that all of them obey one more rule (law) which we didn’t specify, namely that the order in which the operations are applied is irrelevant to the end result.

+ +

Commutative monoid operation

+ +

Such operations (ones for which combining a given set of objects yields the same result no matter which one is first and which one is second) are called commutative operations. Monoids with operations that are commutative are called commutative monoids.

+ +

As we said, addition is commutative as well - it does not matter whether if I have given you 1 apple and then 2 more, or if I have given you 2 first and then 1 more i.e. x + y = y + x.

+ +

Commutative monoid operation

+ +

All monoids that we examined so far are also commutative, and we will see some non-commutative ones later.

+ +

Groups

+ +

A group is just a monoid in which each element has what is called an “inverse” element where the element and its inverse cancel each other out when applied one after the other, in other words , forall x, there must exist x’ such that x • x’ = i ( where i is the identity element).

+ +

If we view monoids as a means of modelling the effect of applying a set of (associative) actions, we use groups to model the eeffects of actions are also reversible.

+ +

An nice example of a group can be found in the realm of numbers (really, numbers are a nice example of almost all properties) - it is the set of integers under addition, where the inverse of each number is its opposite number. The above formula, then, becomes x + (-x) = 0

+ +

The study of groups is a field that is much bigger than the theory of monoids (and perhaps bigger than category theory itself). And it all started with the what are now called the “symmetry groups” which we will look into with more details.

+ +

Summary

+

Here are the algebraic structures that we have seen so far and the laws that they obey.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 SemigroupsMonoidsGroups
AssociativityXXX
Identity XX
Invertability  X
+ +
+ + + + +
+
+
+
+

Contents

+ +

About this book

+ +

Sets

+ +

From Sets to Categories

+ +

Monoids etc

+ + +
+
+ + + + diff --git a/_site/03_monoid/monoid_commutative.svg b/_site/03_monoid/monoid_commutative.svg new file mode 100644 index 0000000..e7e6933 --- /dev/null +++ b/_site/03_monoid/monoid_commutative.svg @@ -0,0 +1,172 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/03_monoid/numbers_addition.svg b/_site/03_monoid/numbers_addition.svg new file mode 100644 index 0000000..e75d1b3 --- /dev/null +++ b/_site/03_monoid/numbers_addition.svg @@ -0,0 +1,152 @@ + + + + + + image/svg+xml + + + + + + + + + + + 1 + 1 + 2 + + + + 1 + 1 + 2 + = + diff --git a/_site/03_monoid/numbers_multiplication.svg b/_site/03_monoid/numbers_multiplication.svg new file mode 100644 index 0000000..2d878b2 --- /dev/null +++ b/_site/03_monoid/numbers_multiplication.svg @@ -0,0 +1,152 @@ + + + + + + image/svg+xml + + + + + + + + + + + 1 + 1 + 2 + + x + 1 + 1 + 2 + = + diff --git a/_site/05_functors/text.md b/_site/05_functors/text.md new file mode 100644 index 0000000..7c36a89 --- /dev/null +++ b/_site/05_functors/text.md @@ -0,0 +1,9 @@ +Functors +=== + + +Isomorphism +=== + +We say that isomorphisms are equality + diff --git a/_site/MellSans-Black.otf b/_site/MellSans-Black.otf new file mode 100644 index 0000000..d39bd61 Binary files /dev/null and b/_site/MellSans-Black.otf differ diff --git a/_site/RubikMonoOne.ttf b/_site/RubikMonoOne.ttf new file mode 100644 index 0000000..ee6af94 Binary files /dev/null and b/_site/RubikMonoOne.ttf differ diff --git a/_site/cover.svg b/_site/cover.svg new file mode 100644 index 0000000..14996bb --- /dev/null +++ b/_site/cover.svg @@ -0,0 +1,380 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/custom-style.css b/_site/custom-style.css new file mode 100644 index 0000000..21814e9 --- /dev/null +++ b/_site/custom-style.css @@ -0,0 +1,32 @@ +img { + width: 100%; +} + +body { + font-size: 25px; + font-family: Arial, sans-serif; +} + + +@font-face { + font-family: 'mell'; + src: url('RubikMonoOne.ttf') format('truetype'); + font-weight: bold; + font-style: normal; +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'mell', cursive; +} + +.page-index img { + border: 2px solid #ccc; +} + +.header { + background-color: #39bcedff; +} + +.footer { + background-color: #8967acff; +} diff --git a/_site/feed.xml b/_site/feed.xml new file mode 100644 index 0000000..99125d0 --- /dev/null +++ b/_site/feed.xml @@ -0,0 +1 @@ +Jekyll2020-12-28T20:52:12+02:00http://localhost:4000/category-theory-illustrated/feed.xmlCategory Theory IllustratedA book about category theory \ No newline at end of file diff --git a/_site/index.html b/_site/index.html new file mode 100644 index 0000000..b915893 --- /dev/null +++ b/_site/index.html @@ -0,0 +1,46 @@ + + + + Category Theory Illustrated - index + + + + + +
+
+ +
+
+
+ +

cover

+ +
+ + +
+
+
+
+

Contents

+ +

About this book

+ +

Sets

+ +

From Sets to Categories

+ +

Monoids etc

+ + +
+
+ + + + diff --git a/_site/limit.md b/_site/limit.md new file mode 100644 index 0000000..9932298 --- /dev/null +++ b/_site/limit.md @@ -0,0 +1,20 @@ +Limits +=== + +Products are one example of what is known in category theory as *limits*. A limit is an object that summarizes a structure (also called a diagram) consisting of other objects and morphisms in a way that allows us to later retrieve some of it. + +A limit also has to be unique in the sense that you cannot have two limit objects for the same structure. + +The notion of a limit is strongly related with the notion of a commuting diagrams. This is not obvious when we are examining products because the diagram of products does not have several routes reaching to the same point. + +Limits can be defined formally, just like everything else that we examine, but we won't bother to do that here. + +Products are Limits +--- + +OK, we said that limits summarize a structure. What is the structure that a product is summarizing? It is a structure that consists of two objects (sets) that are have no connections between them. + +![External diagram](product_part_external.svg) + +Why is the product unique when it comes to representing the two objects? Because any other object that also represents them is connected to the product through a morphism (this is known as the *universal property* of limits). + diff --git a/_site/logo.svg b/_site/logo.svg new file mode 100644 index 0000000..2aee97b --- /dev/null +++ b/_site/logo.svg @@ -0,0 +1,181 @@ + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_site/readme.md b/_site/readme.md new file mode 100644 index 0000000..57611be --- /dev/null +++ b/_site/readme.md @@ -0,0 +1,8 @@ +Category Theory Illustrated +=== + +This is a book about Category Theory that I started writing. Read it at + +http://boris-marinov.github.io/category-theory-illustrated/ +== + diff --git a/_site/robots.txt b/_site/robots.txt new file mode 100644 index 0000000..a3404a6 --- /dev/null +++ b/_site/robots.txt @@ -0,0 +1 @@ +Sitemap: http://localhost:4000/category-theory-illustrated/sitemap.xml diff --git a/_site/sitemap.xml b/_site/sitemap.xml new file mode 100644 index 0000000..de688f6 --- /dev/null +++ b/_site/sitemap.xml @@ -0,0 +1,22 @@ + + + +http://localhost:4000/category-theory-illustrated/00_about/ +2020-12-28T20:52:12+02:00 + + +http://localhost:4000/category-theory-illustrated/01_set/ +2020-12-28T20:52:12+02:00 + + +http://localhost:4000/category-theory-illustrated/02_category/ +2020-12-28T20:52:12+02:00 + + +http://localhost:4000/category-theory-illustrated/03_monoid/ +2020-12-28T20:52:12+02:00 + + +http://localhost:4000/category-theory-illustrated/ + + diff --git a/_site/style.css b/_site/style.css new file mode 100644 index 0000000..13d9f01 --- /dev/null +++ b/_site/style.css @@ -0,0 +1,84 @@ +body { + line-height: 1.5; + margin: 0; + font-size: 20px; +} + +.header { + color:white; + background-color: gray; + width: 100%; + text-align: center; +} + +.container { + max-width: 1000px; + margin: auto; + padding: 20px; +} + +.footer { + color:white; + background-color: gray; + width: 100%; +} +.header a { + color: white; + text-decoration: none; +} +.footer a { + color: white; +} + + +pre { + background-color: gray; + color:#fff; + padding: 7px 7px 7px 10px; + box-shadow: 3px 3px rgba(0,0,0,0.1); + margin: 20px 0 20px 0; + font-family: 'Source Code Pro', monospace; + white-space: pre-wrap; +} + + +@font-face { + font-family: 'mell'; + src: url('RubikMonoOne.ttf') format('truetype'); + font-weight: bold; + font-style: normal; +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'mell', cursive; +} + + +h1 { + font-size: 40px; +} + +h2 { + font-size: 25px; +} + +h3 { + font-size: 15px; +} + +h4 { + font-size: 10px; + color: gray; +} + + +a { + color: gray; + cursor: pointer; +} + +blockquote { + border-left: 4px dotted #666; + padding: 0 10px; + color: #666; +} diff --git a/cover.svg b/cover.svg new file mode 100644 index 0000000..14996bb --- /dev/null +++ b/cover.svg @@ -0,0 +1,380 @@ + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/custom-style.css b/custom-style.css new file mode 100644 index 0000000..21814e9 --- /dev/null +++ b/custom-style.css @@ -0,0 +1,32 @@ +img { + width: 100%; +} + +body { + font-size: 25px; + font-family: Arial, sans-serif; +} + + +@font-face { + font-family: 'mell'; + src: url('RubikMonoOne.ttf') format('truetype'); + font-weight: bold; + font-style: normal; +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'mell', cursive; +} + +.page-index img { + border: 2px solid #ccc; +} + +.header { + background-color: #39bcedff; +} + +.footer { + background-color: #8967acff; +} diff --git a/index.md b/index.md index bbf1c91..4fb587e 100644 --- a/index.md +++ b/index.md @@ -1,12 +1,5 @@ -## About -This book is a product of my own endeavour of understanding category theory from a more non-mathematical viewpoint - it is just that as I am explaining something, I am understanding it better. - -It is aimed at programmers, as well as anyone else who is interested in this stuff. I am writing it as I learn. - -The main reason I am interested in Category Theory is that it allows us to formalise some common concepts that we use in our daily (intellectual) lives. Much of our language is based on intuition and rightfully so: relying on intuition is a very easy way to get your point across so it is understood by other human beings. However, that is part of the problem: sometimes intuition makes it too easy to communicate with someone. So easy that he might, in fact, understand things that you haven't actually said. For example, when I say that two things are equal, it would seem obvious to you what I mean, although it isn't obvious at all (how are they equal, at what context etc). That is the place when we might want to provide a more rigorous definition of what am I saying (even if I did not have one, to begin with). But providing such definition in natural language, which is designed to use intuition as a means of communication, is no easy task. It is in these situations that people often resort to diagrams to explain their thoughts. Diagrams are ubiquitous in science and mathematics because they are an understandable way to communicate a formal concept clearly. Category theory formalises the concept of a diagram and their components - arrows and objects and creates a language for presenting all kinds of ideas. - -## Contents - -* [01 - Sets. What is an Abstract Theory](/01_set/text.md) -* [02 - From Sets to Categories](/02_more_sets/text.md) -* [03 - Some Other Categories](/03_categories/text.md) +--- +layout: default +title: index +--- +![cover](cover.svg) diff --git a/logo.svg b/logo.svg new file mode 100644 index 0000000..2aee97b --- /dev/null +++ b/logo.svg @@ -0,0 +1,181 @@ + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/style.css b/style.css new file mode 100644 index 0000000..13d9f01 --- /dev/null +++ b/style.css @@ -0,0 +1,84 @@ +body { + line-height: 1.5; + margin: 0; + font-size: 20px; +} + +.header { + color:white; + background-color: gray; + width: 100%; + text-align: center; +} + +.container { + max-width: 1000px; + margin: auto; + padding: 20px; +} + +.footer { + color:white; + background-color: gray; + width: 100%; +} +.header a { + color: white; + text-decoration: none; +} +.footer a { + color: white; +} + + +pre { + background-color: gray; + color:#fff; + padding: 7px 7px 7px 10px; + box-shadow: 3px 3px rgba(0,0,0,0.1); + margin: 20px 0 20px 0; + font-family: 'Source Code Pro', monospace; + white-space: pre-wrap; +} + + +@font-face { + font-family: 'mell'; + src: url('RubikMonoOne.ttf') format('truetype'); + font-weight: bold; + font-style: normal; +} + +h1, h2, h3, h4, h5, h6 { + font-family: 'mell', cursive; +} + + +h1 { + font-size: 40px; +} + +h2 { + font-size: 25px; +} + +h3 { + font-size: 15px; +} + +h4 { + font-size: 10px; + color: gray; +} + + +a { + color: gray; + cursor: pointer; +} + +blockquote { + border-left: 4px dotted #666; + padding: 0 10px; + color: #666; +} diff --git a/summary.md b/summary.md deleted file mode 100644 index c319b8e..0000000 --- a/summary.md +++ /dev/null @@ -1,8 +0,0 @@ -## Summary - -* [Sets](/01_set/text.md) -* [From Sets to Categories](/02_more_sets/text.md) -* [Defining Categories](/03_logic/text.md) - - -