From ae171446c7fd2bf0c77afbf11ffb5320cb13858e Mon Sep 17 00:00:00 2001 From: Boris Marinov Date: Wed, 24 Feb 2021 18:39:55 +0200 Subject: [PATCH] Orders as categories --- _chapters/01_set.md | 2 +- _chapters/02_category/set_arrows.svg | 150 +++++----- _chapters/03_monoid.md | 7 +- _chapters/04_order.md | 68 +++-- _chapters/04_order/arrows_one_arrow.svg | 108 +++++++ _chapters/04_order/coproduct_morphisms.svg | 276 ++++++++++++++++++ _chapters/04_order/order_category.svg | 245 ++++++++++++++++ _chapters/04_order/set_arrows.svg | 207 +++++++++++++ .../04_order/transitivity_composition.svg | 152 ++++++++++ 9 files changed, 1124 insertions(+), 91 deletions(-) create mode 100644 _chapters/04_order/arrows_one_arrow.svg create mode 100644 _chapters/04_order/coproduct_morphisms.svg create mode 100644 _chapters/04_order/order_category.svg create mode 100644 _chapters/04_order/set_arrows.svg create mode 100644 _chapters/04_order/transitivity_composition.svg diff --git a/_chapters/01_set.md b/_chapters/01_set.md index 9c7483e..4ebffdf 100644 --- a/_chapters/01_set.md +++ b/_chapters/01_set.md @@ -259,7 +259,7 @@ We can define a new function, that is the equivalent to performing the operation 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? +**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 --- diff --git a/_chapters/02_category/set_arrows.svg b/_chapters/02_category/set_arrows.svg index ea530b1..994a755 100644 --- a/_chapters/02_category/set_arrows.svg +++ b/_chapters/02_category/set_arrows.svg @@ -1,6 +1,6 @@ image/svg+xml + @@ -40,166 +41,173 @@ inkscape:window-height="818" id="namedview2852" showgrid="false" - inkscape:zoom="2.3349572" - inkscape:cx="297.64999" + inkscape:zoom="0.82553204" + inkscape:cx="-57.326316" inkscape:cy="100" inkscape:window-x="0" inkscape:window-y="27" inkscape:window-maximized="0" - inkscape:current-layer="g2846" /> + inkscape:current-layer="g2846" + inkscape:document-rotation="0" /> + style="opacity:0.13;stroke:#000000;stroke-width:13.5026;stroke-miterlimit:10" /> + style="opacity:0.13;stroke:#000000;stroke-width:13.5026;stroke-miterlimit:10" /> isEven + x="225.62718" + y="239.03592" + id="tspan2820" + style="stroke-width:0.66389">isEven isOdd + x="224.71373" + y="261.5994" + id="tspan2824" + style="stroke-width:0.66389">isOdd isPrime + x="232.00917" + y="287.25305" + id="tspan2828" + style="stroke-width:0.66389">isPrime >0 + x="272.09683" + y="299.49792" + id="tspan2832" + style="stroke-width:0.66389">>0 number + id="tspan2838" + style="stroke-width:0.501133">number boolean + id="tspan2842" + style="stroke-width:0.501133">boolean diff --git a/_chapters/03_monoid.md b/_chapters/03_monoid.md index 647bae0..d701d48 100644 --- a/_chapters/03_monoid.md +++ b/_chapters/03_monoid.md @@ -99,6 +99,11 @@ This touches a programming concept which is very popular in category-theory insp In general, we use monoids and related structures as a way to model how a set of (associative) actions that are performed on a given object (or objects) alter it's state. We can do that, provided that the object's state is determined solely by the actions that are performed on it, this allows us to leave the object out of the equation and concentrate on how the actions are combined. And as per usual, the actions (and elements) can be anything, from mixing colors in paint, or adding a quantities to a given set of things etc. + + Other monoid-like objects === @@ -275,8 +280,6 @@ Those two operations and their composite results in a group called **Dih3** that **Question:** Besides having two main actions, what is the defining factor that makes this and any other group non-abelian? - - Monoids as Categories === diff --git a/_chapters/04_order.md b/_chapters/04_order.md index acd46bc..73cbd76 100644 --- a/_chapters/04_order.md +++ b/_chapters/04_order.md @@ -159,9 +159,7 @@ Give two elements, the smallest element that is bigger than both of them (i.e. t ![Join](join.svg) -In a totally ordered set, the *join* of any subset of elements is just their the *maximum* element. - -And, like with the maxumum element, if two elements have several upper bounds that are equally big, then none of them is a *join* (a join must be unique). +Given any two elements in which one is bigger than the other (e.g. **A ≤ B**), the join is the bigger element (in this case **B**). In a totally ordered set, the *join* of any subset of elements is just their the *maximum* element. And, like with the maxumum element, if two elements have several upper bounds that are equally big, then none of them is a *join* (a join must be unique). ![A non-join diagram](non_join.svg) @@ -196,42 +194,78 @@ This allows us to compare any two points by just seeing which one is above the o Preorder === -In the last chapter, we saw how removing the law of totality from the laws of *(linear) order* produces a different (and somewhat more interesting) structure, called *partial order*. Now let's see what will happen if we remove another one of the laws, namely the *antisymmetry* law. If you recall, the antisymmetry law mandated that you cannot have an object that is at the same time smaller and bigger than another one. (or that **a ≤ b ⟺ b ≰ a**) and removing it leaves us with just one law - transitivity - **a ≤ b and b ≤ c ➞ a ≤ c** (two, if we count reflexivity). +In the last chapter, we saw how removing the law of totality from the laws of *(linear) order* produces a different (and somewhat more interesting) structure, called *partial order*. Now let's see what will happen if we remove another one of the laws, namely the *antisymmetry* law. If you recall, the antisymmetry law mandated that you cannot have an object that is at the same time smaller and bigger than another one. (or that **a ≤ b ⟺ b ≰ a**). -| **Total order** | reflexive | transitive | antisymmetric | total | -| **Partial order** | reflexive | transitive | antisymmetric | ~~total~~ | -| **Preorder** | reflexive | transitive | ~~antisymmetric~~ | ~~total~~ | +| **Total order** | reflexive | transitive | antisymmetric | total | Either **a ≤ b** or **b ≤ a** +| **Partial order** | reflexive | transitive | antisymmetric | ~~total~~ | Either **a ≤ b** or **b ≤ a** or they are unrelated. +| **Preorder** | reflexive | transitive | ~~antisymmetric~~ | ~~total~~ | Both **a ≤ b** and **b ≤ a** are possible. -This results in something called a preorder which is not exactly an order, as it can have arrows coming from any point to any other. If a partial order can be used to model who is better at who in soccer, then a preorder can be used to model who has beaten who, either directly (by playing him) or indirectly +This results in something called a preorder which is not exactly an order, as it can have arrows coming from any point to any other: if a partial order can be used to model who is better at who in soccer, then a preorder can be used to model who has beaten who, either directly (by playing him) or indirectly. ![preorder](preorder.svg) -An interesting consequence of the reflexivity property is that all indirect wins (ones that are wins not against the player directly, but against someone who had beat them) are added as a direct result of its application, as seen here (we show indirect wins in lighter tone). +Preorders have just one law - transitivity **a ≤ b and b ≤ c ➞ a ≤ c** (two, if we count reflexivity). The part about the indirect wins is a result of this law. Due to it, all indirect wins (ones that are wins not against the player directly, but against someone who had beat them) are added as a direct result of its application, as seen here (we show indirect wins in lighter tone). ![preorder in sport](preorder_sports.svg) - Also, notice that all "circle" relationships (e.g. where you have a weaker player beating a stronger one) result in just a bunch of objects that are all connected to one another, due to which, we can convert the preorder into partial order, by grouping all objects that have arrows to one another in sets and then create an order from those sets. +And as a result of that, all "circle" relationships (e.g. where you have a weaker player beating a stronger one) result in just a bunch of objects that are all connected to one another, due to which, we can convert the preorder into partial order, by grouping all objects that have arrows to one another in sets and then create an order from those sets (they are called *equivalence classes*, by the way). ![preorder](preorder_equivalence.svg) -Those sets are called *equivalence classes*. +All of that structure arizes naturally from the simple law of transitivity. + +![Transitivity](transitivity.svg) + Orders as categories === +Now let's look at transitivity law again, but from a different perspective. What it tells us that if we have two pairs of relationship **a ≤ b** and **b ≤ c**, then we automatically have a third one **a ≤ c**. In other words, it tells us that the **≤** relationship composes i.e. if we view the "bigger than" relationship as a morphism we would see that it fits the categorical definition of composition. + +![Transitivity as functional composition](transitivity_composition.svg) + +(we have to also verify that the relation is associative, but that's easy) + +What about that other law that was required in order to be a category - the identity law? We have it too, under the name *reflexivity*. + +![Reflexivity](reflexivity.svg) + +So it's official - preoders are categories. And since partial orders and total orders are preorders too (as they obey those two laws), they are categories as well. + +Starting to compare the categories of preorders, and partial and linear orders to other categories, like the (quintessential) category of sets, immediately sets them apart. In other categories there can be *many different morphisms (arrows)* between two objects and in orders can have *at most one morphism*. That is, for two objects **a** **b** we either we have **a ≤ b** or we do not. + +![Orders compared to other categories](arrows_one_arrow.svg) + +That is in the contrast with the category of sets where there are potentially inifinite amount of functions from, say, the set of integers and the set of boolean values, as well as a lot of functions that go the other way around, and the existence of either of these functions does not imply that one set is "bigger" than the other one. + +![Orders compared to other categories](order_category.svg) + +Products and sums +--- + +While we are rehashing diagrams from the previous chapters, let's look at the diagram defining the *sum* of two objects in a category + +![Joins as coproduct](coproduct_morphisms.svg) + + +The set inclusion order +=== + +Do some sets form some kind of order as established by the functions between them? + + Let's revisit our color-mixing monoid and create a color-mixing poset ![A color mixing poset](color_mixing_poset.svg) -Orders as powersets -=== - Lattices -=== - -Order as powersets --- +The poset N+ under the divisibility ordering is a lattice! +Indeed, it turns out that the meet operation corresponds +to greatest common divisor and the join operation corresponds to least common multiple. + + Logic === diff --git a/_chapters/04_order/arrows_one_arrow.svg b/_chapters/04_order/arrows_one_arrow.svg new file mode 100644 index 0000000..00ea05d --- /dev/null +++ b/_chapters/04_order/arrows_one_arrow.svg @@ -0,0 +1,108 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + diff --git a/_chapters/04_order/coproduct_morphisms.svg b/_chapters/04_order/coproduct_morphisms.svg new file mode 100644 index 0000000..e0369bc --- /dev/null +++ b/_chapters/04_order/coproduct_morphisms.svg @@ -0,0 +1,276 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_chapters/04_order/order_category.svg b/_chapters/04_order/order_category.svg new file mode 100644 index 0000000..0ffd709 --- /dev/null +++ b/_chapters/04_order/order_category.svg @@ -0,0 +1,245 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + isEven + isOdd + isPrime + >0 + number + toBit + + boolean + + + + + + + diff --git a/_chapters/04_order/set_arrows.svg b/_chapters/04_order/set_arrows.svg new file mode 100644 index 0000000..8aacb7b --- /dev/null +++ b/_chapters/04_order/set_arrows.svg @@ -0,0 +1,207 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + isEven + isOdd + isPrime + >0 + + number + boolean + + + diff --git a/_chapters/04_order/transitivity_composition.svg b/_chapters/04_order/transitivity_composition.svg new file mode 100644 index 0000000..29ef038 --- /dev/null +++ b/_chapters/04_order/transitivity_composition.svg @@ -0,0 +1,152 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + +