Sociopath Community

An Identity Map is a special kind of endomap in which each element is mapped to itself.

functional notation,
f(John) = John
f(Mary) = Mary
f(Sam) = Sam

Coded examples,

identity.hs said:

-- Set A
type A = [String]

-- Identity map on Set A
identityMap :: A -> A
identityMap xs = xs

-- Test the identity map
input :: A
input = ["John", "Mary", "Sam"]
output :: A
output = identityMap input
main :: IO ()
main = print output
-- Output: ["John","Mary","Sam"]

identity.py said:

# Set A
A = ['John', 'Mary', 'Sam']

# Identity map on Set A
def identityMap(xs):
    return xs

# Test the identity map
output = identityMap(A)
print(output)
# Output: ['John', 'Mary', 'Sam']

 In Category Theory we often don't care about the details of any given object, as such we do not concern ourselves with Internal Diagrams but instead External Diagrams which emphasize the mappings between objects instead of the mappings between members of objects.

A --f--> B
A --g--> A
A --I--> A

External diagrams are more important because the number of objects and mappings we typically deal with are more than a few, as such keeping track of the internal mappings is complicated and more importantly not worth the effort given it doesn't lead to better results.

Composition of Maps :: two maps are combined to obtain a third map

Ex. Given the previous sets A and B we can imagine a situation in which each person of A wants to serve their favorite person in their favorite breakfast in B.

As such there will be two mappings, mapping g that represents the rule that maps members of A to their favorite members of A, and mapping f that maps members of A to their favorite breakfast.

Internal Diagram,

External Diagram,
A --g--> A --f--> B

functional notation,
f(g(John)) = f(Mary) = coffee
f(g(Mary)) = f(John) = eggs
f(g(Sam)) = f(Mary) = coffee

Via the functional notation we see that a mapping f is equivalent to a mapping of f following g, which will be denoted at f.g.

As such, given the problem of this example we could solve the problem with this single mapping f.g which takes us straight from the set A to set B while satisfying our goal described in the problem.

Internal Diagram,

External Diagram,

A --f.g--> B

Coded examples,

composition.hs said:

-- Function f maps members of set A to members of set B
f :: String -> String
f "John" = "eggs"
f "Mary" = "coffee"
f "Sam" = "coffee"

-- Function g maps members of set A to themselves
g :: String -> String
g "John" = "Mary"
g "Mary" = "John"
g "Sam" = "Mary"

-- Composition function
compose :: (a -> a) -> (a -> b) -> a -> b
compose g f x = f (g x)

h = compose g f

main = do
-- Print the composition of g and f applied to "John"
putStrLn (h "John")

-- Print the composition of g and f applied to "Mary"
putStrLn (h "Mary")

-- Print the composition of g and f applied to "Sam"
putStrLn (h "Sam")

composition.py said:

# Set A
A = ['John', 'Mary', 'Sam']

# Endomorphism on Set A
def g(x):
    if x == 'John':
        return 'Mary'
    elif x == 'Mary':
        return 'John'
    else:
        return 'Mary'

# Morphism from Set A to Set B
def f(x):
    if x == 'John':
        return 'eggs'
    elif x == 'Mary':
        return 'coffee'
    else:
        return 'coffee'

# Composition f(g(A))
composition = [f(g(x)) for x in A]
print(composition)

# Output: ['coffee', 'eggs', 'coffee']

 In general, if we have two maps f and g, where the domain of f is the same as the codomain of g, then we can form a Composition.

X --g--> Y --f--> Z == X --f.g--> Z

just got done studying all of cat theory. it was impawsible

Xadem said: 

just got done studying all of cat theory. it was impawsible

omg you're the worst. 

Taking a breather on this topic for now, looking at it feels harder today. 

Weird, seems more comprehensible as things go on.  Largely due to the programming/coding analogies.

Buttered Toast said: 

Weird, seems more comprehensible as things go on.  Largely due to the programming/coding analogies.

I have older posts to catch up on as well, and today it looks blurry. 

After each set of notes I am going to give a summary of some coded examples, specifically the examples written in Haskell given BT is currently learning Haskell and its technically a language that can be considered equivalent to CT given Synatax-Semantics Duality. 

I am writing this after completing what's below, I am wondering if the color gradient will bother anyone given it seems more natural to have done yellow->green->blue

Morphism

morphism.hs said:

import Data.Map (Map, (!), fromList)

-- Set A
type A = [String]

-- Set B
type B = [String]

-- Map from elements of A to their favorite breakfast in B
favoriteBreakfast :: Map String String
favoriteBreakfast = fromList [("John", "eggs"), ("Mary", "coffee"), ("Sam", "coffee")]

-- Morphism from A to B
morphism :: A -> B
morphism xs = map (\x -> favoriteBreakfast ! x) xs

The above code explicates the concept of Morphism. Recall that a morphism is a mapping between to objects according to a rule.

In this example the two objects are sets where set A = {John, Mary, Sam} and set B = {eggs, toast, oatmeal, coffee}. The rule of the morphism makes each member of A point at their favorite breakfast in B. 

The objects in this example are sets A and B, so the question is how do you represent said objects in Haskell? In Haskell an object is equivalent to a Type, so to define a new object is to define a new Type. 

-- Set A
type A = [String]

-- Set B
type B = [String]

In the above code, we use 'type' to begin the type definition. Each new type we define must have a name, so the names we choose correspond to A and B given this is what we decided to call our sets. In haskell, a long with most languages, we define new abstract objects using predefined objects native to the language. Hence, our new objects A and B are defined as [Strings] which are also a kind of type. Why string? Because strings represent text and the members of our sets are text. 

A key take away is that the definition of new types (objects) in haskell is a means to abstraction and generalization. 

The rest of the code defines a morphism from the set A to the set B. 

favoriteBreakfast :: Map String String

This line defines a value called favoriteBreakfast as a type Map String String. As I just mentioned, types correspond to objects so the value favoriteBreakfast is now defined as the kind of object Map String String represents. Map String String is called a key-value map, which associates keys, in this case a String, to values, in this case a string. In Python we call these dictionaries and in other languages they may be called associative arrays. 

favoriteBreakfast = fromList [("John", "eggs"), ("Mary", "coffee"), ("Sam", "coffee")]

The above line specifies the the keys and values we are trying to map together. It maps the key john to the value eggs, the key mary to the value coffee, and the key sam to the value coffee. fromList is a called function using the import at the very top of the program that describes the mapping of key-value maps. 

These two lines together provide the structure to the morphism we want to define, that is they provide the literal rule of the morphism that maps each member of A to their favorite breakfast in B.  

morphism :: A -> B

Above we finally define the function called morphism as a type A->B, which declares that the function takes in a type A and returns a type B. Given we defined the types A and B as strings, morphism takes in a string and outputs a string. 

Note at this point the rule that maps the set A to B has not been declared.  

morphism xs = map (\x -> favoriteBreakfast ! x) xs

In this line we finally describe the rule. 

It states that a function morphism takes in a list xs of members of some type A and returns members of some type B. The rule of the function is expressed as a applying a  lambda function  \x -> favoriteBreakfast ! x to each member of the inputted list of type A. The lambda function looks up values in our inputted list to their associated keys in the previously defined structure breakFast. 

At this point we have two objects A and B and a valid morphism with a rule that maps them together in the way we hope. The rest of the code simply tests that given the correct input A we get the correct output of B. 

Endomap

-- Set A
type A = [String]

-- Endomorphism on Set A
endomorphism :: String -> String
endomorphism x
| x == "John" = "Mary"
| x == "Mary" = "John"
| otherwise = "Mary"

Given an endomorphism is just a specific kind of morphism, in fact a simpler kind, this code is similar to the code for morphism.hs. 

type A = [String]

We define the set A as a string typed object called A. 

endomorphism :: String -> String

We declare a function called endomorphism that takes in an object of type string and returns an object of stype string.  

endomorphism x
| x == "John" = "Mary"
| x == "Mary" = "John"
| otherwise = "Mary"

This is where the code for morphism.hs and endomap.hs differ. In morphism.hs we predefined a structure called breakFast and then called that structure when defining the rule of function morphism. In endomap.hs, we are defining the structure and rule at the same time, this is because fundamentally a structure or behavior are the same thing. 

In this case the structure we use to define the rule is called Pattern Matching in haskell. Pattern matching is a means of specifying different results for different input values. 

| x == "John" = "Mary"

If the string in A is equivalent to "John" we want to change its value to "Mary", because John maps to Mary given Mary is Johns favorite person.  

| x == "Mary" = "John"

If the string in A is equivalent to "Mary" we change its value to "John", because Mary maps to John given John is Mary's favorite person. 

| otherwise = "Mary"

This line corresponds to Sam mapping to Mary because Mary is Sams favorite person. 

Again, the rest of the code tests that if we give the program our set A the desired mapping to A is achieved.  

 Identity Map

-- Set A
type A = [String]

-- Identity map on Set A
identityMap :: A -> A
identityMap xs = xs

 Identity maps are the simplest, like an endomap is maps A to A but specifically each member of A is mapped to themselves. 

As such, when looking at how we define our you'll see we take in our inputted string and return that same string given this corresponds to each member mapping to themselves. 

Mommy.

Explanation of composition.ms

I will post the next set of notes by Monday, they will be about Categories and their Properties. 

-- Function f maps members of set A to members of set B
f :: String -> String
f "John" = "eggs"
f "Mary" = "coffee"
f "Sam" = "coffee"

-- Function g maps members of set A to themselves
g :: String -> String
g "John" = "Mary"
g "Mary" = "John"
g "Sam" = "Mary"

-- Composition function
compose :: (a -> a) -> (a -> b) -> a -> b
compose g f x = f (g x)

h = compose g f

main = do
    -- Print the composition of g and f applied to "John"
    putStrLn (h "John")

    -- Print the composition of g and f applied to "Mary"
    putStrLn (h "Mary")

    -- Print the composition of g and f applied to "Sam"
    putStrLn (h "Sam")

This program represents the concept of Composition in CT, which recall is a morphism constructed by combining two other morphisms. Composition can be considered the fundamental operation of CT as it defines the structure of Category. 

f :: String -> String
f "John" = "eggs"
f "Mary" = "coffee"
f "Sam" = "coffee"

We define a function f that takes in an argument of type string and returns an object of type string. Recall that the function f is to represent the rule that maps each element in A to its favorite breakfast in B. 

Like in previous examples we use pattern matching to map elements of set A to elements of set B. Note that in this example our syntax for pattern matching is different than in the other programs, all this shows is that there are different means of syntactically instantiating what is considered the same data structure. 

Also notice that we have not declared sets A and B as typed objects explicitly in this program, instead we allow them to implicitly exist via instances in our functions. This is similar to the difference between an external vs external diagram in CT, here our approach is purely an external approach where the only thing we actually care about our morphisms between objects, not elements native to objects. As such the only place we find instances of set A and set B our in the definition of the rules that define the behavior of any given morphism. 

The upshot is that we have semantic freedom when approaching programming from a CT perspective. 

g :: String -> String
g "John" = "Mary"
g "Mary" = "John"
g "Sam" = "Mary"

 Again, the same as before we define a function g that maps the elements of A to their favorite person in A. 

compose :: (a -> a) -> (a -> b) -> a -> b

We begin the definition of out compose by defining the function type. 

The function compose takes in three arguments: (1) a function (a->a) that maps a to a, (2) a function (a->b) that maps a to b, (3) and a value a. The function returns a value of type b. 

While we may call the set of morphisms (a -> a) -> (a -> b) -> a -> b a composition in CT in Haskell there is a more general concept of this kind of function called a High-Order Function which is a function that takes functions as arguments. 

We will find that in defining a composition such as this it will always be a a high-order function, however not all higher order functions are compositions. In order for a higher-order function to be classified as a composition requires it to specifically take in two functions as arguments. 

compose g f x = f (g x)

Here we give the function 'compose' its desired behavior by properly associating its types to each of our predefined functions.

(a -> a) corresponds to g, g maps elements of set A to elements of set A

(a -> b) corresponds to f, f maps elements of set A to elements of set B

a corresponds to x, x is the specific string we input into the composition. 

The value of x should be a string from set A as the composition first maps a string from set A to its favorite element in set A, followed by mapping that favorite element to its favorite breakfast. If the string x is not a string from set A there will be nothing for it to map to. 

The rest of the code is again to test whether our composition does what he hope it does. 

AliceInWonderland said: 

I am about to get back into Category Theory and Buttered Toast is dipping his toes into it as well. 

Why might you want to learn it? It has applications in mathematics, computational theory, programming, logic, linguistics, and even certain formalism's of cognitive science. 

Regardless of if anyone is interested I will still probably post a lot in this thread given its the only alternative to me berating Buttered Toast in pm. 

If you are interested these are the sources you will want to check out: 

An Introduction to Category Theory by Harold Simmons

Category Theory for Scientists by David Spivak 

Category Theory of Programmers by Bartosz Milewski

The main text is Simmons but given my interests in programming I will be talking about categories in the context of programming a lot so it may not be a bad idea to read portions of the Milewski book. 

edit: you do not need a mathematical or computer science background, anyone of any skill level can do this with some effort. 

 I'm curious about it

Delora said: 

 I'm curious about it

This is the space to ask questions, bring other things up.  How curious are you?  And is your curiosity...about the subject, or separable?  What do you think you will find or want from it?

What programming knowledge do you have?