new layout

This commit is contained in:
Boris Marinov 2020-12-28 20:52:31 +02:00
parent 8b5fad7e67
commit 3424bd6a1d
177 changed files with 9338 additions and 462 deletions

BIN
.jekyll-metadata Normal file

Binary file not shown.

View File

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

BIN
MellSans-Black.otf Normal file

Binary file not shown.

BIN
RubikMonoOne.ttf Normal file

Binary file not shown.

13
_chapters/00_about.md Normal file
View File

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

View File

@ -1,3 +1,8 @@
---
layout: default
title: Sets
---
Sets
===

View File

Before

Width:  |  Height:  |  Size: 295 KiB

After

Width:  |  Height:  |  Size: 295 KiB

View File

Before

Width:  |  Height:  |  Size: 758 B

After

Width:  |  Height:  |  Size: 758 B

View File

Before

Width:  |  Height:  |  Size: 2.8 KiB

After

Width:  |  Height:  |  Size: 2.8 KiB

View File

Before

Width:  |  Height:  |  Size: 8.4 KiB

After

Width:  |  Height:  |  Size: 8.4 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

Before

Width:  |  Height:  |  Size: 869 B

After

Width:  |  Height:  |  Size: 869 B

View File

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.6 KiB

View File

Before

Width:  |  Height:  |  Size: 748 B

After

Width:  |  Height:  |  Size: 748 B

View File

Before

Width:  |  Height:  |  Size: 5.2 KiB

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

Before

Width:  |  Height:  |  Size: 2.2 KiB

After

Width:  |  Height:  |  Size: 2.2 KiB

View File

Before

Width:  |  Height:  |  Size: 5.3 KiB

After

Width:  |  Height:  |  Size: 5.3 KiB

View File

Before

Width:  |  Height:  |  Size: 5.2 KiB

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

Before

Width:  |  Height:  |  Size: 4.6 KiB

After

Width:  |  Height:  |  Size: 4.6 KiB

View File

Before

Width:  |  Height:  |  Size: 2.7 KiB

After

Width:  |  Height:  |  Size: 2.7 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 3.5 KiB

After

Width:  |  Height:  |  Size: 3.5 KiB

View File

Before

Width:  |  Height:  |  Size: 2.0 KiB

After

Width:  |  Height:  |  Size: 2.0 KiB

View File

Before

Width:  |  Height:  |  Size: 5.6 KiB

After

Width:  |  Height:  |  Size: 5.6 KiB

View File

Before

Width:  |  Height:  |  Size: 5.3 KiB

After

Width:  |  Height:  |  Size: 5.3 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 2.4 KiB

After

Width:  |  Height:  |  Size: 2.4 KiB

View File

Before

Width:  |  Height:  |  Size: 1.5 KiB

After

Width:  |  Height:  |  Size: 1.5 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

View File

Before

Width:  |  Height:  |  Size: 82 KiB

After

Width:  |  Height:  |  Size: 82 KiB

View File

Before

Width:  |  Height:  |  Size: 7.7 KiB

After

Width:  |  Height:  |  Size: 7.7 KiB

View File

Before

Width:  |  Height:  |  Size: 827 B

After

Width:  |  Height:  |  Size: 827 B

View File

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

View File

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

View File

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

View File

Before

Width:  |  Height:  |  Size: 6.4 KiB

After

Width:  |  Height:  |  Size: 6.4 KiB

View File

Before

Width:  |  Height:  |  Size: 8.1 KiB

After

Width:  |  Height:  |  Size: 8.1 KiB

View File

Before

Width:  |  Height:  |  Size: 756 B

After

Width:  |  Height:  |  Size: 756 B

View File

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

View File

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

View File

Before

Width:  |  Height:  |  Size: 5.7 KiB

After

Width:  |  Height:  |  Size: 5.7 KiB

View File

Before

Width:  |  Height:  |  Size: 4.2 KiB

After

Width:  |  Height:  |  Size: 4.2 KiB

View File

Before

Width:  |  Height:  |  Size: 2.2 KiB

After

Width:  |  Height:  |  Size: 2.2 KiB

View File

Before

Width:  |  Height:  |  Size: 3.0 KiB

After

Width:  |  Height:  |  Size: 3.0 KiB

View File

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

Before

Width:  |  Height:  |  Size: 2.1 KiB

After

Width:  |  Height:  |  Size: 2.1 KiB

View File

Before

Width:  |  Height:  |  Size: 8.6 KiB

After

Width:  |  Height:  |  Size: 8.6 KiB

View File

Before

Width:  |  Height:  |  Size: 5.4 KiB

After

Width:  |  Height:  |  Size: 5.4 KiB

View File

Before

Width:  |  Height:  |  Size: 7.6 KiB

After

Width:  |  Height:  |  Size: 7.6 KiB

View File

Before

Width:  |  Height:  |  Size: 2.4 KiB

After

Width:  |  Height:  |  Size: 2.4 KiB

View File

Before

Width:  |  Height:  |  Size: 352 B

After

Width:  |  Height:  |  Size: 352 B

View File

Before

Width:  |  Height:  |  Size: 606 B

After

Width:  |  Height:  |  Size: 606 B

View File

Before

Width:  |  Height:  |  Size: 9.3 KiB

After

Width:  |  Height:  |  Size: 9.3 KiB

View File

Before

Width:  |  Height:  |  Size: 5.6 KiB

After

Width:  |  Height:  |  Size: 5.6 KiB

View File

Before

Width:  |  Height:  |  Size: 1.3 KiB

After

Width:  |  Height:  |  Size: 1.3 KiB

View File

Before

Width:  |  Height:  |  Size: 1.3 KiB

After

Width:  |  Height:  |  Size: 1.3 KiB

View File

Before

Width:  |  Height:  |  Size: 3.2 KiB

After

Width:  |  Height:  |  Size: 3.2 KiB

View File

Before

Width:  |  Height:  |  Size: 439 B

After

Width:  |  Height:  |  Size: 439 B

View File

Before

Width:  |  Height:  |  Size: 649 B

After

Width:  |  Height:  |  Size: 649 B

View File

Before

Width:  |  Height:  |  Size: 792 B

After

Width:  |  Height:  |  Size: 792 B

View File

Before

Width:  |  Height:  |  Size: 1.4 KiB

After

Width:  |  Height:  |  Size: 1.4 KiB

View File

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

View File

Before

Width:  |  Height:  |  Size: 9.9 KiB

After

Width:  |  Height:  |  Size: 9.9 KiB

View File

Before

Width:  |  Height:  |  Size: 6.6 KiB

After

Width:  |  Height:  |  Size: 6.6 KiB

View File

Before

Width:  |  Height:  |  Size: 1.9 KiB

After

Width:  |  Height:  |  Size: 1.9 KiB

View File

Before

Width:  |  Height:  |  Size: 770 B

After

Width:  |  Height:  |  Size: 770 B

View File

Before

Width:  |  Height:  |  Size: 7.1 KiB

After

Width:  |  Height:  |  Size: 7.1 KiB

View File

Before

Width:  |  Height:  |  Size: 9.0 KiB

After

Width:  |  Height:  |  Size: 9.0 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

View File

@ -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.
===

View File

Before

Width:  |  Height:  |  Size: 8.3 KiB

After

Width:  |  Height:  |  Size: 8.3 KiB

View File

Before

Width:  |  Height:  |  Size: 3.4 KiB

After

Width:  |  Height:  |  Size: 3.4 KiB

View File

Before

Width:  |  Height:  |  Size: 6.9 KiB

After

Width:  |  Height:  |  Size: 6.9 KiB

View File

Before

Width:  |  Height:  |  Size: 7.8 KiB

After

Width:  |  Height:  |  Size: 7.8 KiB

View File

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.6 KiB

View File

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.6 KiB

View File

Before

Width:  |  Height:  |  Size: 5.4 KiB

After

Width:  |  Height:  |  Size: 5.4 KiB

View File

Before

Width:  |  Height:  |  Size: 6.3 KiB

After

Width:  |  Height:  |  Size: 6.3 KiB

View File

Before

Width:  |  Height:  |  Size: 6.3 KiB

After

Width:  |  Height:  |  Size: 6.3 KiB

View File

@ -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/<your_long_string> or user/<user-name>
# 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: <!--more--> # 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: <!--more--> # 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

43
_layouts/default.html Normal file
View File

@ -0,0 +1,43 @@
<!DOCTYPE html>
<html>
<head>
<title> {{site.name}} - {{ page.title }}</title>
<link rel="stylesheet" type="text/css" href="{{site.baseurl}}/style.css">
<link rel="stylesheet" type="text/css" href="{{site.baseurl}}/custom-style.css">
</head>
<body>
<div class="header">
<div class="container">
<img src="{{site.baseurl}}/logo.svg" class="logo">
</div>
</div>
<div class="container page-{{page.title}}">
<!--<h1>{{page.title}}</h1> -->
{{ content }}
<div class="prev-next">
{% if page.previous.url %}
<a class="prev" href="{{site.baseurl}}{{page.previous.url}}">&laquo;prev</a>
{% endif %}
{% if page.next.url %}
<a class="next" href="{{site.baseurl}}{{page.next.url}}">next&raquo;</a>
{% endif %}
</div>
</div>
<div class="footer">
<div class="container">
<h1>Contents</h1>
{% for chapter in site.chapters %}
<p><a href="{{chapter.url | prepend:site.baseurl}}">{{chapter.title}}</a></p>
{% endfor %}
<!--
<h1>Download</h1>
<p><a href="{{site.baseurl}}{{site.baseurl}}.epub">as epub</a></p>
<p><a href="{{site.baseurl}}{{site.baseurl}}.txt">as txt</a></p>
-->
</div>
</div>
</body>

54
_site/00_about/index.html Normal file
View File

@ -0,0 +1,54 @@
<!DOCTYPE html>
<html>
<head>
<title> Category Theory Illustrated - About this book</title>
<link rel="stylesheet" type="text/css" href="/category-theory-illustrated/style.css">
<link rel="stylesheet" type="text/css" href="/category-theory-illustrated/custom-style.css">
</head>
<body>
<div class="header">
<div class="container">
<img src="/category-theory-illustrated/logo.svg" class="logo">
</div>
</div>
<div class="container page-About this book">
<!--<h1>About this book</h1> -->
<h1 id="about">About</h1>
<p>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.</p>
<p>It is aimed at programmers, as well as anyone else who is interested in this stuff.</p>
<p>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 havent actually said. For example, when I say that two things are equal, it would seem obvious to you what I mean, although it isnt 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.</p>
<div class="prev-next">
<a class="next" href="/category-theory-illustrated/01_set/">next&raquo;</a>
</div>
</div>
<div class="footer">
<div class="container">
<h1>Contents</h1>
<p><a href="/category-theory-illustrated/00_about/">About this book</a></p>
<p><a href="/category-theory-illustrated/01_set/">Sets</a></p>
<p><a href="/category-theory-illustrated/02_category/">From Sets to Categories</a></p>
<p><a href="/category-theory-illustrated/03_monoid/">Monoids etc</a></p>
<!--
<h1>Download</h1>
<p><a href="/category-theory-illustrated/category-theory-illustrated.epub">as epub</a></p>
<p><a href="/category-theory-illustrated/category-theory-illustrated.txt">as txt</a></p>
-->
</div>
</div>
</body>

1
_site/01_set/all.svg Normal file
View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 359"><switch><g><g stroke-width="6" stroke-miterlimit="10"><circle opacity=".14" stroke="#000" cx="320.5" cy="189.3" r="154.3"/><circle fill="#E6E7E8" stroke="#808285" cx="305.3" cy="179.5" r="154.3"/></g><g stroke-width="6" stroke-miterlimit="10"><circle fill="#FCE600" stroke="#FD0" cx="261.2" cy="257.4" r="24.6"/><circle fill="#39BCED" stroke="#008DD2" cx="269.4" cy="74.4" r="24.6"/><circle fill="#D71920" stroke="#BE1E2D" cx="207.4" cy="140.1" r="24.6"/><circle fill="#F58235" stroke="#E76524" cx="390.1" cy="208.1" r="24.6"/><circle fill="#8967AC" stroke="#651C5F" cx="294.1" cy="169.5" r="24.6"/><circle fill="#54B948" stroke="#00873A" cx="365.4" cy="103.1" r="24.6"/></g></g></switch></svg>

After

Width:  |  Height:  |  Size: 758 B

1
_site/01_set/boolean.svg Normal file
View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 284.7"><switch><g><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="311.8" cy="147" r="114.9"/><circle fill="#E6E7E8" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="301.1" cy="134" r="114.9"/><circle fill="#FFF" stroke="#939598" stroke-width="6" stroke-miterlimit="10" cx="272" cy="188.2" r="41.3"/><g fill="#808285"><path d="M246.8 193.5c.8 0 1.8-.2 2.9-.6v4.4c-.8.3-1.6.6-2.3.7-.7.1-1.6.2-2.6.2-2 0-3.5-.5-4.3-1.5-.9-1-1.3-2.5-1.3-4.5V185h-2.1v-2.4l2.7-1.9 1.5-3.6h3.9v3.5h4.2v4.5h-4.2v6.7c0 1.1.5 1.7 1.6 1.7zM263.2 180.3c.5 0 1 0 1.5.1l.3.1-.5 5.6c-.5-.1-1.2-.2-2-.2-1.3 0-2.3.3-2.8.9-.6.6-.9 1.5-.9 2.6v8.5h-6v-17.3h4.4l.9 2.8h.3c.5-.9 1.2-1.7 2.1-2.2.9-.7 1.8-.9 2.7-.9zM279.7 197.9l-.7-2.2h-.4c-.5.8-1.2 1.4-2.1 1.8-.9.4-1.9.6-3.1.6-1.9 0-3.4-.6-4.4-1.7-1.1-1.1-1.6-2.7-1.6-4.7v-11.3h6v9.5c0 1.1.2 2 .5 2.6.3.6.8.9 1.6.9 1 0 1.8-.4 2.2-1.2.4-.8.7-2.2.7-4.1v-7.6h6v17.3h-4.7zM296.7 198.2c-2.9 0-5.1-.8-6.7-2.3-1.6-1.5-2.4-3.7-2.4-6.5 0-2.9.7-5.2 2.2-6.7 1.5-1.6 3.6-2.3 6.3-2.3 2.6 0 4.6.7 6 2 1.4 1.4 2.1 3.3 2.1 5.9v2.7h-10.7c0 1 .4 1.7 1.1 2.3s1.6.8 2.7.8c1 0 2-.1 2.9-.3.9-.2 1.8-.5 2.9-1v4.3c-.9.5-1.9.8-2.9 1-.9 0-2.1.1-3.5.1zm-.3-13.9c-.7 0-1.3.2-1.8.7-.5.4-.8 1.1-.8 2.1h5.1c0-.8-.3-1.5-.7-2-.5-.5-1.1-.8-1.8-.8z"/></g><g><circle fill="#FFF" stroke="#939598" stroke-width="6" stroke-miterlimit="10" cx="325" cy="95.4" r="41.3"/><g fill="#808285"><path d="M300.5 92.4h-3.3v11.4h-5.3V92.4h-2v-2.6l2.2-1.3v-.3c0-2 .4-3.5 1.2-4.4.8-.9 2.2-1.3 4-1.3.7 0 1.4.1 2 .2.6.1 1.4.3 2.2.6l-1.1 3.4c-.7-.2-1.3-.3-1.9-.3-.4 0-.7.1-.9.4s-.3.7-.3 1.2v.4h3.3v4zM312.7 103.8l-1-2h-.1c-.7.9-1.4 1.5-2.2 1.8-.7.3-1.7.5-2.9.5-1.5 0-2.6-.4-3.4-1.3s-1.3-2.1-1.3-3.7.6-2.9 1.7-3.7c1.1-.8 2.8-1.3 5-1.4h2.5v-.2c0-1.3-.6-1.9-1.9-1.9-1.1 0-2.6.4-4.3 1.1l-1.5-3.5c1.8-.9 4.1-1.4 6.8-1.4 2 0 3.5.5 4.6 1.5 1.1 1 1.6 2.4 1.6 4.1v10.1h-3.6zm-4-3.5c.6 0 1.2-.2 1.7-.6s.7-.9.7-1.6v-1.2l-1.2.1c-1.8.1-2.6.7-2.6 1.9-.1 1 .4 1.4 1.4 1.4zM325.3 103.8H320V82.6h5.3v21.2zM340.9 99.1c0 1.7-.6 2.9-1.7 3.7-1.1.8-2.7 1.3-4.9 1.3-1.1 0-2.1-.1-3-.2-.8-.1-1.7-.3-2.6-.7V99c.8.4 1.7.7 2.7.9 1 .2 1.9.4 2.6.4 1.2 0 1.7-.3 1.7-.8 0-.3-.2-.5-.5-.7s-1.3-.6-2.8-1.2c-1.4-.6-2.4-1.2-3-2-.6-.7-.8-1.7-.8-2.8 0-1.4.6-2.6 1.7-3.4 1.1-.8 2.7-1.2 4.7-1.2 1 0 2 .1 2.9.3.9.2 1.8.5 2.8 1l-1.4 3.4c-.7-.3-1.5-.6-2.2-.8s-1.4-.3-1.9-.3c-.9 0-1.3.2-1.3.6 0 .3.2.5.5.7s1.2.6 2.6 1.1c1.1.4 1.9.9 2.4 1.3s.9.9 1.2 1.5c.2.5.3 1.2.3 2.1zM351.3 104.1c-2.6 0-4.6-.7-6-2.1-1.4-1.4-2.1-3.3-2.1-5.8 0-2.6.7-4.6 2-6 1.3-1.4 3.2-2.1 5.6-2.1 2.3 0 4.1.6 5.4 1.8 1.3 1.2 1.9 3 1.9 5.2v2.4h-9.5c0 .9.4 1.5.9 2 .6.5 1.4.7 2.4.7.9 0 1.8-.1 2.6-.3.8-.2 1.6-.5 2.6-.9v3.8c-.8.4-1.7.7-2.6.9s-1.9.4-3.2.4zm-.3-12.4c-.6 0-1.2.2-1.6.6-.4.4-.7 1-.7 1.9h4.6c0-.7-.2-1.3-.6-1.8-.5-.4-1-.7-1.7-.7z"/></g></g></g></switch></svg>

After

Width:  |  Height:  |  Size: 2.8 KiB

1
_site/01_set/char.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 8.4 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 18 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 177"><switch><g><g opacity=".13" stroke="#000" stroke-width="6" stroke-miterlimit="10"><circle cx="83.4" cy="59.8" r="24.6"/><circle cx="271.8" cy="72.1" r="24.6"/><circle cx="179.8" cy="121.4" r="24.6"/><circle cx="483.8" cy="80.4" r="24.6"/><circle cx="539.7" cy="133.7" r="24.6"/><circle cx="373.8" cy="121.4" r="24.6"/></g><g stroke-width="6" stroke-miterlimit="10"><circle fill="#FCE600" stroke="#FD0" cx="78.6" cy="51.6" r="24.6"/><circle fill="#39BCED" stroke="#008DD2" cx="267" cy="63.9" r="24.6"/><circle fill="#D71920" stroke="#BE1E2D" cx="175" cy="113.1" r="24.6"/><circle fill="#F58235" stroke="#E76524" cx="479" cy="72.1" r="24.6"/><circle fill="#8967AC" stroke="#651C5F" cx="534.9" cy="125.4" r="24.6"/><circle fill="#54B948" stroke="#00873A" cx="369" cy="113.1" r="24.6"/></g></g></switch></svg>

After

Width:  |  Height:  |  Size: 869 B

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 359"><switch><g><g stroke-width="6" stroke-miterlimit="10"><circle opacity=".14" stroke="#000" cx="163" cy="163.6" r="134.8"/><circle fill="#E6E7E8" stroke="#808285" cx="149.7" cy="155.1" r="134.8"/><circle opacity=".14" stroke="#000" cx="435" cy="170" r="88.1"/><circle fill="#E6E7E8" stroke="#808285" cx="426.3" cy="164.4" r="88.1"/></g><circle fill="#8967AC" stroke="#651C5F" stroke-width="6" stroke-miterlimit="10" cx="425.1" cy="123.6" r="21.5"/><path fill="#6D6E71" d="M219.5 100s.6-.5 1.7-1.3c.6-.4 1.3-1 2.1-1.6.8-.6 1.8-1.4 2.9-2.1 4.3-3.1 10.6-7.3 18.6-11.7 8-4.3 17.8-8.6 28.7-11.7 5.4-1.6 11.2-2.8 17.1-3.7 5.9-.9 11.9-1.2 18-1.3 6.1 0 12.1.6 18 1.5 2.9.6 5.8 1.1 8.6 1.8 1.4.4 2.8.7 4.2 1.1 1.4.4 2.7.9 4.1 1.3 10.7 3.6 20.1 8.8 27.5 13.9 1.9 1.2 3.6 2.6 5.2 3.8.8.6 1.6 1.2 2.4 1.9.7.6 1.5 1.3 2.2 1.9 2.9 2.3 5.1 4.6 7 6.5.4.4.7.6.9.8l.2.2-8.2 8.1c7.9 1.8 16 4.6 24 8.2-1-8.7-2.6-17.6-5.3-26.7l-8.2 8.1-.2-.2-.9-.9c-2-1.9-4.3-4.2-7.2-6.6-.7-.6-1.5-1.3-2.2-1.9-.8-.6-1.6-1.2-2.4-1.9-1.7-1.3-3.4-2.7-5.4-4-7.7-5.3-17.3-10.6-28.3-14.3-1.4-.4-2.8-.9-4.2-1.3-1.4-.5-2.9-.8-4.3-1.2-2.9-.8-5.9-1.3-8.9-1.9-6-.9-12.2-1.5-18.5-1.6-6.2 0-12.4.4-18.5 1.3-6 .9-11.9 2.1-17.5 3.8-11.2 3.1-21.2 7.6-29.3 12-8.2 4.4-14.6 8.7-19 11.9-1.1.8-2.1 1.5-2.9 2.1-.8.6-1.5 1.2-2.1 1.6-1.1.9-1.8 1.4-1.8 1.4l1.9 2.7z"/><path fill="#6D6E71" d="M142.5 59.4s.9-.8 2.6-2.2c1.7-1.4 4.3-3.5 7.7-5.9 6.8-4.8 17.2-10.9 30.7-16.1 6.7-2.6 14.2-5 22.2-7s16.6-3.6 25.5-4.8c17.9-2.2 37.2-2.5 56.4-.2 19.1 2.2 37.9 6.8 54.6 13.5 16.7 6.6 31.3 15.3 42.5 24.3 11.3 9 19.2 18 24.2 24.7.7.9 1.1 1.4 1.1 1.4l-9.3 6.9c7.6 2.9 15.2 6.8 22.5 11.6.5-8.7.1-17.9-1.3-27.2l-9.3 6.9s-.4-.5-1.1-1.5c-5.1-6.8-13.3-16.1-24.8-25.3-11.4-9.2-26.3-18-43.3-24.7-17-6.8-36.1-11.5-55.5-13.7-19.4-2.2-39-2-57.1.2-9.1 1.2-17.8 2.8-25.9 4.8-8.1 2-15.7 4.5-22.5 7.1-13.7 5.3-24.4 11.5-31.4 16.5-3.5 2.5-6.1 4.6-7.9 6.1-1.7 1.5-2.7 2.3-2.7 2.3l2.1 2.3z"/><circle fill="#F58235" stroke="#E76524" stroke-width="6" stroke-miterlimit="10" cx="435" cy="203.4" r="21.5"/><path fill="#6D6E71" d="M228.5 201s2.2 2 5.9 5.6c1.9 1.7 4.3 3.8 7.1 6.2 2.9 2.2 6 4.9 9.7 7.4 7.3 5.2 16.2 10.7 26.5 15.3 10.2 4.6 21.9 7.9 33.8 9.5 6 .7 12 .9 17.9.8 5.9-.3 11.7-.9 17.2-1.9 11-2.1 21-5.5 29.2-9.1 8.2-3.7 14.7-7.4 19.1-10.2.4-.3.8-.5 1-.6.1-.1.2-.1.2-.1l6.2 9.7c4.6-8.1 8.3-16.4 11.2-24.6-8.6 1.6-17.2 2.4-25.4 2.5l6.2 9.7s-.1 0-.2.1c-.2.1-.6.4-1 .6-4.3 2.7-10.7 6.4-18.7 10-8 3.6-17.7 6.9-28.5 8.9-5.4 1-11 1.6-16.7 1.9-5.7.2-11.6-.1-17.4-.8-11.6-1.5-22.9-4.7-32.9-9.2-10-4.4-18.8-9.8-25.9-15-3.6-2.5-6.7-5.1-9.5-7.3-2.7-2.3-5.1-4.4-7-6.1-3.7-3.5-5.9-5.5-5.9-5.5l-2.1 2.2z"/><path fill="#6D6E71" d="M115.2 242.3s.9 1 2.6 2.8c1.7 1.8 4.3 4.4 7.6 7.6 6.8 6.4 16.9 15 30.6 23.2 13.6 8.2 30.9 15.7 50.3 20.3 19.4 4.6 40.8 6.2 61.9 4.8 21.2-1.4 42.1-5.8 60.9-11.9 18.9-6.2 35.8-14.1 49.5-22.2 13.7-8.1 24.2-16.3 31.1-22.6.4-.3.7-.6 1-.9l.2-.2.2-.2 7.9 8.5c1.5-4.4 2.8-8.9 3.9-13.3 1-4.5 1.8-8.9 2.2-13.3-4 1.8-8 3.3-12 4.5-4 1.2-8.1 2.1-12.1 2.9l7.9 8.5-.2.2-.2.2c-.3.3-.6.5-1 .9-6.7 6.2-17 14.2-30.6 22.2-13.5 8-30.2 15.8-48.8 21.9-18.6 6.1-39.3 10.4-60.2 11.8-20.9 1.4-41.9-.2-61-4.8-19.1-4.5-36-11.9-49.4-19.9-13.4-8-23.4-16.6-30.1-22.8-3.3-3.2-5.8-5.7-7.5-7.5-1.7-1.8-2.6-2.7-2.6-2.7l-2.1 2z"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="223.3" cy="185.4" r="21.5"/><g stroke-width="6" stroke-miterlimit="10"><circle fill="#FCE600" stroke="#FD0" cx="116.9" cy="234.9" r="21.5"/><circle fill="#39BCED" stroke="#008DD2" cx="124.1" cy="75.2" r="21.5"/><circle fill="#54B948" stroke="#00873A" cx="208" cy="100.2" r="21.5"/></g></g></switch></svg>

After

Width:  |  Height:  |  Size: 3.6 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 307"><switch><g><g stroke-width="6" stroke-miterlimit="10"><circle opacity=".14" stroke="#000" cx="429.9" cy="171.9" r="114.5"/><circle fill="#E6E7E8" stroke="#808285" cx="418.6" cy="164.6" r="114.5"/></g><g stroke-width="6" stroke-miterlimit="10"><circle fill="#D71920" stroke="#BE1E2D" cx="346" cy="135.4" r="18.3"/><circle fill="#F58235" stroke="#E76524" cx="481.5" cy="185.9" r="18.3"/><circle fill="#8967AC" stroke="#651C5F" cx="410.3" cy="157.2" r="18.3"/><circle fill="#54B948" stroke="#00873A" cx="463.2" cy="108" r="18.3"/><circle opacity=".14" stroke="#000" cx="155.4" cy="159.3" r="65"/><circle fill="#E6E7E8" stroke="#808285" cx="149" cy="155.2" r="65"/></g></g></switch></svg>

After

Width:  |  Height:  |  Size: 748 B

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 271.3"><switch><g><g stroke-width="6" stroke-miterlimit="10"><circle opacity=".14" stroke="#000" cx="155.1" cy="133.7" r="90"/><circle fill="#E6E7E8" stroke="#808285" cx="146.3" cy="128" r="90"/><circle opacity=".14" stroke="#000" cx="392.7" cy="153.9" r="90"/><circle fill="#E6E7E8" stroke="#808285" cx="383.9" cy="148.1" r="90"/></g><circle fill="#39BCED" stroke="#008DD2" stroke-width="6" stroke-miterlimit="10" cx="414.3" cy="117.9" r="21.6"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="359.9" cy="175.4" r="21.6"/><path fill="#6D6E71" d="M177 97.6s.7-.5 2-1.4c1.3-.9 3.2-2.2 5.8-3.7 5.1-3.1 12.7-7.1 22.3-10.6 9.6-3.5 21.2-6.4 33.9-8.1 12.7-1.6 26.4-2 40.1-.9 13.7.9 27.2 3.3 39.7 6.2 12.5 3 23.9 6.7 33.6 10.3 9.6 3.6 17.4 7.1 22.8 9.8.9.4 1.4.7 1.4.7l-5.1 10.4c8.4-.7 17-1.1 25.8-1-4.3-7.6-9.1-15.2-14.3-22.6L380.1 97s-.5-.2-1.4-.7c-5.5-2.6-13.4-6.2-23.1-9.9-9.7-3.7-21.3-7.4-33.9-10.4-12.7-3-26.4-5.3-40.2-6.3-13.8-1.1-27.8-.7-40.7 1-12.9 1.7-24.8 4.7-34.6 8.3-9.8 3.6-17.6 7.7-22.8 10.8-2.7 1.5-4.6 2.9-6 3.8-1.4.9-2.1 1.4-2.1 1.4l1.7 2.6z"/><circle fill="#39BCED" stroke="#008DD2" stroke-width="6" stroke-miterlimit="10" cx="169.3" cy="100.6" r="21.6"/><path fill="#6D6E71" d="M123 165.6s.6.7 1.6 2.1c.5.7 1.2 1.6 2 2.6.7 1 1.7 2.1 2.8 3.4 4.2 5.1 10.7 11.9 19.5 18.9 8.8 7 20 13.9 32.8 19.7 1.6.7 3.2 1.4 4.9 2 1.6.7 3.3 1.4 5 1.9l5.1 1.8c1.7.6 3.5 1.1 5.3 1.6.9.3 1.8.5 2.6.8l2.7.7c1.8.4 3.6.9 5.4 1.3 3.7.7 7.3 1.6 11 2.1 14.8 2.4 29.8 2.6 43.8 1.2 13.9-1.6 26.7-4.8 37.3-8.7 10.6-3.8 18.8-8.3 24.5-11.6.9-.5 1.4-.9 1.4-.9l6 9.9c1.2-2 2.3-4.1 3.4-6 1.1-2 2.1-4.1 3.1-6.2l1.4-3c.4-1 .9-2.1 1.3-3.1.8-2.1 1.6-4.1 2.4-6.1-2.2.4-4.4.7-6.5 1-1.1.1-2.1.3-3.2.4l-3.2.3c-2.1.2-4.2.3-6.3.4h-6.2l6 9.9s-.5.3-1.3.8c-5.6 3.2-13.6 7.6-24 11.3-10.3 3.8-22.8 7-36.5 8.5-13.7 1.4-28.5 1.2-43-1.1-3.6-.5-7.2-1.3-10.8-2-1.8-.4-3.5-.9-5.3-1.3l-2.6-.7-2.6-.8c-1.7-.5-3.5-1-5.2-1.6-1.7-.6-3.4-1.2-5-1.8-1.7-.6-3.3-1.2-4.9-1.9-1.6-.7-3.2-1.3-4.8-2-12.5-5.6-23.5-12.4-32.1-19.3-8.6-6.8-15-13.5-19-18.4-1.1-1.2-2-2.3-2.7-3.3-.8-1-1.4-1.8-1.9-2.5-1-1.4-1.6-2.1-1.6-2.1l-2.6 1.8z"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="114.9" cy="158.1" r="21.6"/></g></switch></svg>

After

Width:  |  Height:  |  Size: 2.2 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 5.3 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 307"><switch><g><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="460.4" cy="159.3" r="65"/><circle fill="#E6E7E8" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="454" cy="155.2" r="65"/><circle fill="#39BCED" stroke="#008DD2" stroke-width="6" stroke-miterlimit="10" cx="453" cy="145.9" r="17.6"/><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="197.3" cy="180.3" r="114.5"/><circle fill="#E6E7E8" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="186" cy="173.1" r="114.5"/><path fill="#6D6E71" d="M266 208.2s.6.3 1.7.9c.6.3 1.3.7 2.1 1.1.8.5 1.7 1 2.8 1.5 4.3 2.2 10.6 4.9 18.4 7.3 7.8 2.4 17.3 4.4 27.5 5 1.3.1 2.6.1 3.9.2 1.3.1 2.6 0 3.9.1 2.6.1 5.3-.1 8-.2 1.3-.1 2.7-.2 4-.3l2-.2c.7-.1 1.3-.2 2-.3 1.3-.2 2.7-.3 4.1-.5l4-.7c.7-.1 1.3-.2 2-.4l2-.4c1.3-.3 2.7-.6 4-.9 2.6-.7 5.3-1.4 7.8-2.2 5.1-1.6 10.1-3.6 14.7-5.6 9.3-4.2 17.5-9.3 24.1-14.1 6.6-4.9 11.5-9.6 14.9-13 .6-.7 1-1 1-1l8.3 8c2.7-9.1 4.2-18.2 4.7-26.9-7.8 4-15.8 6.8-23.7 8.7l8.3 8s-.3.4-1 1c-3.3 3.3-8.1 7.9-14.6 12.6-6.4 4.8-14.4 9.7-23.5 13.8-4.6 2-9.4 3.9-14.4 5.5-2.5.8-5.1 1.5-7.6 2.2l-3.9.9-1.9.4c-.7.1-1.3.2-2 .4l-3.9.7c-1.3.2-2.6.3-4 .5-.7.1-1.3.2-2 .2l-2 .2-3.9.3c-2.6.1-5.2.3-7.8.2-1.3 0-2.6 0-3.8-.1-1.3-.1-2.5-.1-3.8-.2-10-.6-19.1-2.6-26.8-4.9-7.6-2.3-13.8-5-17.9-7.1-1.1-.5-2-1-2.8-1.4-.8-.4-1.5-.8-2-1.1-1.1-.6-1.7-.9-1.7-.9l-1.2 2.7zM243 103.7s.6-.3 1.9-.9c1.2-.6 3-1.5 5.3-2.5 4.6-2.1 11.3-4.7 19.8-6.8 8.4-2.1 18.4-3.8 29.3-4.4 1.4-.1 2.7-.1 4.1-.2 1.4-.1 2.8 0 4.2-.1 2.8-.1 5.6.1 8.5.1 1.4.1 2.9.2 4.3.3 1.4.1 2.9.2 4.3.3 1.4.1 2.9.3 4.3.4l4.3.6c1.4.2 2.9.4 4.3.7 1.4.2 2.9.5 4.3.7 2.8.6 5.7 1.1 8.4 1.8 1.4.3 2.8.7 4.1 1 1.4.4 2.7.8 4.1 1.1.7.2 1.3.4 2 .6.7.2 1.3.4 2 .6l3.9 1.2c10.3 3.5 19.6 7.6 27.3 11.7 7.7 4.1 13.8 7.9 18 10.8.8.5 1.2.8 1.2.8l-6.6 9.5c8.3.4 16.7 1.6 25.3 3.4-2.7-8.3-6.1-16.7-10.3-25l-6.6 9.5s-.4-.3-1.2-.8c-4.2-3-10.5-6.9-18.3-11-7.8-4.1-17.3-8.4-27.7-11.9-1.3-.4-2.6-.8-4-1.3-.7-.2-1.3-.4-2-.6-.7-.2-1.4-.4-2-.6-1.4-.4-2.7-.8-4.1-1.2-1.4-.3-2.8-.7-4.2-1-2.8-.7-5.7-1.2-8.6-1.9-1.4-.3-2.9-.5-4.3-.8-1.4-.3-2.9-.5-4.4-.7l-4.4-.6c-1.5-.1-2.9-.3-4.4-.4-1.5-.2-2.9-.3-4.4-.4-1.5-.1-2.9-.2-4.4-.3-2.9-.1-5.8-.2-8.6-.2-1.4 0-2.8 0-4.2.1-1.4.1-2.8.1-4.2.2-11.1.6-21.3 2.3-29.9 4.5-8.6 2.2-15.5 4.9-20.3 7-2.4 1-4.2 2-5.4 2.6-1.2.6-1.9 1-1.9 1l1.2 3.1z"/><path fill="#6D6E71" d="M184.7 184.2s.8 1.1 2.3 3.1c.4.5.8 1.1 1.3 1.7.5.6 1 1.3 1.6 2 .6.7 1.2 1.5 1.9 2.3.7.8 1.4 1.7 2.2 2.6 6.2 7.2 15.7 17.1 28.6 27.1 12.9 10 29.1 20.1 47.9 28.2 18.7 8.1 39.8 14.1 61.4 16.4 10.8 1.2 21.7 1.4 32.4.5 10.7-.9 21.1-2.9 30.9-6 9.8-3.1 18.8-7.4 26.7-12.6 3.9-2.6 7.6-5.4 10.9-8.3 3.3-3 6.4-6 9-9.1 5.4-6.2 9.5-12.6 12.6-18.5 3.1-5.9 5.2-11.4 6.7-15.9.1-.3.2-.6.3-.8V196.6c0-.1 0-.1.1-.2 0-.1.1-.2.1-.3 0-.2.1-.2.1-.2l11 3.5c-1.6-9.4-4.4-18.1-7.7-26.2-5.3 7-11.2 13.2-17.4 18.3l11 3.5s0 .1-.1.2c0 .1-.1.2-.1.3 0 .1 0 .1-.1.2V196c-.1.3-.2.5-.3.8-1.5 4.4-3.5 9.7-6.5 15.4-3 5.7-7 11.9-12.2 17.9-2.6 3-5.5 5.9-8.7 8.8-3.2 2.8-6.8 5.5-10.6 8-7.6 5-16.4 9.2-25.9 12.2-9.5 3.1-19.7 5-30.2 5.8-10.5.8-21.2.6-31.8-.5-21.3-2.3-42.1-8.2-60.5-16.2-18.5-7.9-34.5-17.9-47.2-27.7-12.7-9.9-22-19.5-28.1-26.6-.8-.9-1.5-1.7-2.2-2.5-.7-.8-1.3-1.6-1.8-2.3-.6-.7-1.1-1.4-1.6-2-.5-.6-.9-1.2-1.3-1.7-1.5-2-2.3-3.1-2.3-3.1l-2.4 1.9zM129.4 128.1s.9-1.2 2.6-3.6c.4-.6.9-1.2 1.4-1.9.5-.7 1.1-1.5 1.8-2.3.6-.8 1.3-1.7 2-2.7.7-.9 1.6-1.9 2.4-2.9 6.8-8.3 17.1-19.7 31.3-31.5C185 71.4 203 59.4 223.8 49.7c20.8-9.7 44.5-17 68.9-19.9 12.2-1.4 24.4-1.8 36.5-1 12 .8 23.7 2.9 34.7 6 11 3.1 21.3 7.5 30.5 12.5 9.2 5.1 17.3 10.9 24.2 16.9 6.9 6 12.6 12.2 17.2 18 1.1 1.5 2.3 2.9 3.3 4.3s2 2.8 2.9 4.1c.9 1.3 1.7 2.6 2.6 3.9l1.2 1.8c.4.6.7 1.2 1.1 1.8.7 1.1 1 1.7 1 1.7l-10 5.9c7.3 3.8 14.5 8.4 21.6 13.7 1.1-8.7 1.5-17.7 1.1-27l-10 5.9s-.4-.6-1.1-1.8c-.3-.6-.7-1.2-1.1-1.8l-1.2-1.8c-.8-1.3-1.7-2.6-2.6-3.9-1-1.3-2-2.7-3-4.2-1-1.4-2.2-2.9-3.4-4.4-4.8-5.9-10.6-12.3-17.6-18.4-7-6.2-15.4-12.1-24.7-17.3-9.4-5.1-19.9-9.6-31.1-12.8-11.2-3.2-23.2-5.3-35.4-6.2-12.2-.9-24.7-.5-37.1 1-24.7 2.9-48.7 10.3-69.8 20.2-21.1 9.8-39.3 22.1-53.6 34-14.3 11.9-24.8 23.5-31.7 31.9-.9 1.1-1.7 2-2.4 3s-1.4 1.9-2.1 2.7c-.6.8-1.2 1.6-1.8 2.3-.5.7-1 1.4-1.4 2-1.7 2.4-2.6 3.6-2.6 3.6l2.5 1.7z"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="119.8" cy="134.6" r="18.3"/><circle fill="#F58235" stroke="#E76524" stroke-width="6" stroke-miterlimit="10" cx="248.9" cy="194.3" r="18.3"/><circle fill="#8967AC" stroke="#651C5F" stroke-width="6" stroke-miterlimit="10" cx="177.7" cy="176" r="18.3"/><circle fill="#54B948" stroke="#00873A" stroke-width="6" stroke-miterlimit="10" cx="230.7" cy="116.4" r="18.3"/></g></switch></svg>

After

Width:  |  Height:  |  Size: 4.6 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 359"><switch><g><g stroke-width="6" stroke-miterlimit="10"><circle opacity=".14" stroke="#000" cx="155.1" cy="133.7" r="90"/><circle fill="#E6E7E8" stroke="#808285" cx="146.3" cy="128" r="90"/><circle opacity=".14" stroke="#000" cx="453.3" cy="207.7" r="134.8"/><circle fill="#E6E7E8" stroke="#808285" cx="440" cy="199.2" r="134.8"/></g><circle fill="#FCE600" stroke="#FD0" stroke-width="6" stroke-miterlimit="10" cx="407.1" cy="278.2" r="21.6"/><circle fill="#39BCED" stroke="#008DD2" stroke-width="6" stroke-miterlimit="10" cx="414.3" cy="117.9" r="21.6"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="359.9" cy="175.4" r="21.6"/><circle fill="#F58235" stroke="#E76524" stroke-width="6" stroke-miterlimit="10" cx="520" cy="235.1" r="21.6"/><circle fill="#8967AC" stroke="#651C5F" stroke-width="6" stroke-miterlimit="10" cx="444.7" cy="201.2" r="21.6"/><circle fill="#54B948" stroke="#00873A" stroke-width="6" stroke-miterlimit="10" cx="498.4" cy="143.1" r="21.6"/><path fill="#6D6E71" d="M177 97.6s.7-.5 2-1.4c1.3-.9 3.2-2.2 5.8-3.7 5.1-3.1 12.7-7.1 22.3-10.6 9.6-3.5 21.2-6.4 33.9-8.1 12.7-1.6 26.4-2 40.1-.9 13.7.9 27.2 3.3 39.7 6.2 12.5 3 23.9 6.7 33.6 10.3 9.6 3.6 17.4 7.1 22.8 9.8.9.4 1.4.7 1.4.7l-5.1 10.4c8.4-.7 17-1.1 25.8-1-4.3-7.6-9.1-15.2-14.3-22.6L380.1 97s-.5-.2-1.4-.7c-5.5-2.6-13.4-6.2-23.1-9.9-9.7-3.7-21.3-7.4-33.9-10.4-12.7-3-26.4-5.3-40.2-6.3-13.8-1.1-27.8-.7-40.7 1-12.9 1.7-24.8 4.7-34.6 8.3-9.8 3.6-17.6 7.7-22.8 10.8-2.7 1.5-4.6 2.9-6 3.8-1.4.9-2.1 1.4-2.1 1.4l1.7 2.6z"/><circle fill="#39BCED" stroke="#008DD2" stroke-width="6" stroke-miterlimit="10" cx="169.3" cy="100.6" r="21.6"/><path fill="#6D6E71" d="M123 165.6s.6.7 1.6 2.1c.5.7 1.2 1.6 2 2.6.7 1 1.7 2.1 2.8 3.4 4.2 5.1 10.7 11.9 19.5 18.9 8.8 7 20 13.9 32.8 19.7 1.6.7 3.2 1.4 4.9 2 1.6.7 3.3 1.4 5 1.9l5.1 1.8c1.7.6 3.5 1.1 5.3 1.6.9.3 1.8.5 2.6.8l2.7.7c1.8.4 3.6.9 5.4 1.3 3.7.7 7.3 1.6 11 2.1 14.8 2.4 29.8 2.6 43.8 1.2 13.9-1.6 26.7-4.8 37.3-8.7 10.6-3.8 18.8-8.3 24.5-11.6.9-.5 1.4-.9 1.4-.9l6 9.9c1.2-2 2.3-4.1 3.4-6 1.1-2 2.1-4.1 3.1-6.2l1.4-3c.4-1 .9-2.1 1.3-3.1.8-2.1 1.6-4.1 2.4-6.1-2.2.4-4.4.7-6.5 1-1.1.1-2.1.3-3.2.4l-3.2.3c-2.1.2-4.2.3-6.3.4h-6.2l6 9.9s-.5.3-1.3.8c-5.6 3.2-13.6 7.6-24 11.3-10.3 3.8-22.8 7-36.5 8.5-13.7 1.4-28.5 1.2-43-1.1-3.6-.5-7.2-1.3-10.8-2-1.8-.4-3.5-.9-5.3-1.3l-2.6-.7-2.6-.8c-1.7-.5-3.5-1-5.2-1.6-1.7-.6-3.4-1.2-5-1.8-1.7-.6-3.3-1.2-4.9-1.9-1.6-.7-3.2-1.3-4.8-2-12.5-5.6-23.5-12.4-32.1-19.3-8.6-6.8-15-13.5-19-18.4-1.1-1.2-2-2.3-2.7-3.3-.8-1-1.4-1.8-1.9-2.5-1-1.4-1.6-2.1-1.6-2.1l-2.6 1.8z"/><circle fill="#D71920" stroke="#BE1E2D" stroke-width="6" stroke-miterlimit="10" cx="114.9" cy="158.1" r="21.6"/></g></switch></svg>

After

Width:  |  Height:  |  Size: 2.7 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 10 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 269.9"><switch><g><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="210" cy="68.4" r="39.1"/><circle fill="#FFF" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="206.1" cy="65.9" r="39.1"/><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="368.8" cy="70.6" r="38.8"/><circle fill="#FFF" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="365" cy="68.2" r="38.8"/><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="368.9" cy="217.7" r="37"/><circle fill="#FFF" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="359.3" cy="217.4" r="37"/><path fill="#808082" d="M246.4 64.4s.9-.1 2.4-.4c1.5-.2 3.7-.5 6.3-.8 5.2-.6 12.2-1.1 19.2-1.2 7-.1 14 .2 19.2.7 2.6.2 4.8.5 6.3.7.7.1 1.1.1 1.1.1L299.4 75c7.6-3.5 15.6-6.4 24-8.9-6.3-6.1-13.2-11.9-20.7-17.2l-1.5 11.5s-.4-.1-1.1-.1c-1.5-.2-3.8-.4-6.4-.7-5.3-.5-12.4-.8-19.5-.7-7.1.1-14.2.6-19.5 1.2-2.7.3-4.9.6-6.4.8-1.5.2-2.4.4-2.4.4l.5 3.1zM357.9 107.5s.2.7.6 2c.2.7.4 1.4.7 2.4.2.9.5 2 .8 3.1 1.2 4.5 2.4 10.7 3.2 16.9.7 6.2.9 12.5.8 17.1 0 2.3-.2 4.3-.2 5.7 0 .7-.1 1-.1 1l-11.5-.8c3.9 7.1 7.1 14.9 9.4 23.4 6.1-6.3 11.8-13.5 16.8-21.5l-11.5-.8s0-.4.1-1.1c.1-1.4.2-3.4.2-5.8.1-4.8-.1-11.2-.9-17.6-.7-6.4-2-12.6-3.2-17.3-.3-1.2-.6-2.2-.9-3.2-.3-.9-.5-1.7-.7-2.4-.4-1.3-.7-2.1-.7-2.1l-2.9 1zM219 102.4s1.3 1.5 3.7 4c1.2 1.2 2.6 2.7 4.2 4.4 1.5 1.8 3.3 3.8 5.2 6 7.6 8.8 17.8 20.5 28.8 31.4 5.5 5.5 11.2 10.8 16.8 15.5 2.8 2.4 5.6 4.6 8.2 6.6 2.7 2 5.2 3.9 7.6 5.6 4.8 3.3 8.9 6 11.7 7.8.7.4 1.1.7 1.1.7l-6.2 9.8c8.9.5 17.7.7 26.5.9-4.2-7.7-8.5-15.4-12.3-23l-6.2 9.8s-.4-.2-1.1-.7c-2.8-1.8-6.9-4.5-11.6-7.8-2.4-1.7-4.9-3.5-7.5-5.5-2.6-2-5.3-4.2-8.1-6.5-5.5-4.6-11.2-9.9-16.6-15.3-10.9-10.9-21.1-22.5-28.7-31.3-1.9-2.2-3.7-4.2-5.2-6-1.6-1.8-3-3.3-4.2-4.5-2.3-2.4-3.5-3.9-3.5-3.9l-2.6 2z"/><path d="M276.4 39.6H274v-3.9l2.4-.2v-1c0-3.8 1.8-6.8 6.6-6.8 1.5 0 2.8.4 3.6.6l-1 3.9c-.6-.2-1.3-.4-1.8-.4-1.3 0-2 .7-2 2.5v1.1h3.2v4.1h-3.2v13.7h-5.3V39.6zM376 143.1c0-1.5.9-2.7 2.5-3.6v-.1c-.9-.6-1.6-1.5-1.6-3 0-1.3.9-2.5 2-3.3v-.1c-1.3-.9-2.4-2.5-2.4-4.6 0-4.3 3.5-6.4 7.4-6.4 1 0 2 .1 2.8.4h6.5v3.8h-2.8c.3.5.6 1.4.6 2.3 0 4.1-3.1 6-7 6-.6 0-1.4-.1-2.2-.4-.5.4-.6.7-.6 1.3 0 .9.7 1.3 2.7 1.3h2.9c4.4 0 6.8 1.3 6.8 4.5 0 3.7-3.8 6.4-9.9 6.4-4.4 0-7.7-1.3-7.7-4.5zm12.4-.9c0-1.1-1-1.4-2.7-1.4h-1.8c-1.2 0-1.9-.1-2.5-.2-.6.6-1 1.1-1 1.8 0 1.3 1.6 2 3.9 2 2.4-.1 4.1-1 4.1-2.2zm-2.1-13.9c0-1.9-1-2.9-2.4-2.9s-2.4 1-2.4 2.9c0 2 1 3 2.4 3s2.4-1.1 2.4-3zM245.2 147.6h5.3v6.2l-.3 3.2c1.3-1.2 3.1-2.4 5.5-2.4 3.9 0 5.5 2.7 5.5 7.2v11h-5.3v-10.4c0-2.6-.7-3.4-2.2-3.4-1.3 0-2.2.6-3.3 1.7v12h-5.3v-25.1z" opacity=".64"/><path d="M277.4 40.8H275v-3.9l2.4-.2v-1c0-3.8 1.8-6.8 6.6-6.8 1.5 0 2.8.4 3.6.6l-1 3.9c-.6-.2-1.3-.4-1.8-.4-1.3 0-2 .7-2 2.5v1.1h3.2v4.1h-3.2v13.7h-5.3V40.8zM377 144.3c0-1.5.9-2.7 2.5-3.6v-.1c-.9-.6-1.6-1.5-1.6-3 0-1.3.9-2.5 2-3.3v-.1c-1.3-.9-2.4-2.5-2.4-4.6 0-4.3 3.5-6.4 7.4-6.4 1 0 2 .1 2.8.4h6.5v3.8h-2.8c.3.5.6 1.4.6 2.3 0 4.1-3.1 6-7 6-.6 0-1.4-.1-2.2-.4-.5.4-.6.7-.6 1.3 0 .9.7 1.3 2.7 1.3h2.9c4.4 0 6.8 1.3 6.8 4.5 0 3.7-3.8 6.4-9.9 6.4-4.4 0-7.7-1.4-7.7-4.5zm12.4-1c0-1.1-1-1.4-2.7-1.4h-1.8c-1.2 0-1.9-.1-2.5-.2-.6.6-1 1.1-1 1.8 0 1.3 1.6 2 3.9 2 2.4 0 4.1-1 4.1-2.2zm-2.1-13.9c0-1.9-1-2.9-2.4-2.9s-2.4 1-2.4 2.9c0 2 1 3 2.4 3s2.4-1 2.4-3zM246.2 148.8h5.3v6.2l-.3 3.2c1.3-1.2 3.1-2.4 5.5-2.4 3.9 0 5.5 2.7 5.5 7.2v11h-5.3v-10.4c0-2.6-.7-3.4-2.2-3.4-1.3 0-2.2.6-3.3 1.7v12h-5.3v-25.1z" opacity=".31"/></g></switch></svg>

After

Width:  |  Height:  |  Size: 3.5 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 595.3 407.4"><switch><g><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="160.2" cy="88.4" r="61.8"/><circle fill="#F8F6C1" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="154.1" cy="84.5" r="61.8"/><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="411.4" cy="91.9" r="61.3"/><circle fill="#D6D5EB" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="405.4" cy="88" r="61.3"/><circle opacity=".14" stroke="#000" stroke-width="6" stroke-miterlimit="10" cx="411.6" cy="324.6" r="58.5"/><circle fill="#D9ECD5" stroke="#808285" stroke-width="6" stroke-miterlimit="10" cx="405.8" cy="320.8" r="58.5"/><path fill="#808082" d="M217.6 81.2s1.6-.2 4.4-.6c2.8-.4 6.8-.9 11.6-1.5 9.6-1.1 22.5-1.8 35.4-1.7 12.9.1 25.8 1.2 35.3 2.5 4.8.6 8.8 1.3 11.6 1.7.4.1.7.1.9.1h.3l-2 11.4c7.9-3.1 16.1-5.8 24.5-8.3-6.3-6.1-13-12-20.1-17.7l-2 11.4h-.3c-.2 0-.5-.1-1-.2-2.8-.4-6.8-1.1-11.7-1.7-9.7-1.2-22.7-2.4-35.7-2.5-13-.2-26 .6-35.8 1.7-4.9.6-8.9 1-11.7 1.5-2.8.4-4.4.7-4.4.7l.7 3.2zM404.4 146.7s.4 1.4 1.2 3.8c.8 2.4 1.7 6 2.9 10.2 2.2 8.5 4.2 20 5.2 31.7.3 2.9.4 5.8.5 8.7.1 2.9.1 5.7.2 8.5-.1 2.7-.1 5.4-.2 7.9-.2 2.5-.2 4.9-.4 7.1-.2 2.2-.4 4.2-.5 6-.2 1.8-.4 3.3-.6 4.6-.1.7-.1 1.2-.1 1.2l-11.5-1.6c3.3 7.6 6.2 15.7 8.6 24.2 6.1-6.3 12-13.1 17.5-20.5l-11.5-1.6s.1-.4.2-1.2c.2-1.3.4-2.9.6-4.7.2-1.8.4-3.8.6-6.1.2-2.2.3-4.6.4-7.2.1-2.5.1-5.2.2-8 0-2.8 0-5.7-.2-8.6-.2-2.9-.2-5.9-.5-8.8-.9-11.8-3.1-23.6-5.2-32.2-1.1-4.3-2.1-7.9-2.9-10.4-.8-2.5-1.2-3.9-1.2-3.9l-3.3.9zM184.7 138.4s.6.6 1.6 1.8c1 1.2 2.6 2.8 4.6 4.9 2 2.1 4.4 4.6 7 7.5 2.6 3 5.6 6.4 8.8 10.1 12.9 14.9 30.3 34.7 49.2 53 9.5 9.2 19.4 17.9 29 25.6 9.7 7.7 19.2 14.3 27.4 19.8s15.2 9.8 20.1 12.9c.8.5 1.3.8 1.3.8l-6.1 9.8c8.8.3 17.6.5 26.4.7-4.2-7.7-8.5-15.4-12.6-23l-6.1 9.8s-.5-.3-1.3-.8c-4.9-3-11.8-7.4-20-12.8s-17.6-12-27.2-19.6c-9.6-7.6-19.4-16.3-28.8-25.4-18.8-18.2-36.1-38-49-52.8-3.2-3.7-6.2-7.1-8.8-10.2-2.7-3-5.1-5.5-7.1-7.6-2-2.1-3.5-3.7-4.5-4.8-1-1.1-1.5-1.7-1.5-1.7l-2.4 2z"/></g></switch></svg>

After

Width:  |  Height:  |  Size: 2.0 KiB

Some files were not shown because too many files have changed in this diff Show More