John Baez on Categories

<?xml version="1.0" encoding="UTF-8"?>  <XholonWorkbook> <Notes><![CDATA[ Xholon ------ Title: John Baez on Categories Description: Url: http://johncarlosbaez.wordpress.com/2011/01/18/petri-nets/ InternalName: YoutubeId: Keywords: My Notes **May 28 2012** -------- Mathematician John Baez has been writing about mathematical categories, and he's got me convinced that categories are something I should have a closer look at. I'll use this workbook to get started. The purpose of a workbook is to jot down notes, and try out various ideas. I will try to work through what John is saying by relating it to stuff I already know. In his article on Petri Nets John writes :: Whenever you have a setup with: • abstract gadgets that have ‘input wires’ and ‘output wires’, and you can • hook up these gadgets by connecting outputs to inputs, and • the wires can cross over each other, and • it doesn’t matter whether one wire crosses over or under another then you’ve probably got a symmetric monoidal category! A lot of my own models and apps have this type of structure. For example, this image is from an executable model of a cardiac cell, that I reimplemented from a paper by Beard :: http://xholon.cvs.sourceforge.net/viewvc/xholon/xholon/config/xmiapps/Beard2005_UML_Xholon_Step4_v1/Mitochondrion_Step4.png This must be a symmetric monoidal category? More of the cardiac cell model :: http://xholon.cvs.sourceforge.net/viewvc/xholon/xholon/config/xmiapps/Beard2005_UML_Xholon_Step4_v1/ http://xholon.cvs.sourceforge.net/viewvc/xholon/xholon/src/org/primordion/xholon/xmiapps/ http://xholon.cvs.sourceforge.net/viewvc/xholon/xholon/transform/MagicDraw/ I will read some of the paper "Physics, Topology, Logic and Computation: A Rosetta Stone"[2] that John co-authored, and that he suggests "for a precise definition, and lots of examples"[1]. Now I've read the first 10 pages of the paper. The Rosetta Stone is condensed in Table 1, which translates terminology between 5 domanins[2]. |Category Theory Physics Topology Logic Computation --------------- ------- --------- --------- ----------- object system manifold proposition data type morphism process cobordism proof program | The objects and morphisms of Category Theory represent "things" and "ways to go between things". "In |physics|, the objects are often physical systems, and the morphisms are processes turning a state of one physical system into a state of another system — perhaps the same one.[2]" I'm familiar with two concepts of state in systems :: (1) Finite State Machines, where each state is an integer or String, especially as used in UML see for example the Elevator simulation http://www.primordion.com/pub/presentations/KenWebb_Oclug_UmlPresentation_v2.pdf (2) Simulations of physical systems with many attributes, where each attribute is a floating-point number, and where the current state of the system is the collection of current values of all those attributes see for example the One-Layer Atmosphere Model http://www.primordion.com/Xholon/wb/openwb.php?q=2489058&f=gist.github.com/raw/ This workbook contains a very simple default app (simulation of a physical system) involving a Block and its Height. The JavaScript code in one of the editors further down on this page, is a process that changes the value of Height each time step. Each time step this physical system has a different state. To run this physical system, and allow the process to come into play :: Click the Run button at the top of the page. Click the Pause button in the overlay, to unpause the app and start it running. Watch the value of Height (the state of this physical system) as it increases each time step. "In |quantum physics| we often formalize this by taking Hilbert spaces as objects, and linear operators as morphisms.[2]" "there is an extensive network of interlocking analogies between physics, topology, logic and computer science"[2] So, "what’s the use of this stuff?", where "stuff" means category theory. "What it will do is help organize our understanding of systems made of parts." [1] With |Xholon| I typically use the terms "structure" and "behavior", as found in the Unified Modeling Language (UML) version 2.0 specification (the Superstructure document from August 2005). Part I of the document is labeled "Structure", and Part II is labeled "Behavior". These are equivalent to the Computation terms "data type" and "program" used in Table 1. Structure is about classes and class instances (things). Behavior is about programs that operate on the structure over time. In the very simple default app included on this page, the XholonClass, xholonClassDetails, and PhysicalSystem editors specify the structure, and the Blockbehavior editors specify the behavior implemented in a choice of five different programming languages. In UML, behavior is about the diagrammable structure of behavior (such as state machine diagrams) rather than the actual lines of programming code (which can live inside the states and transitions of a state machine). Objects **May 29 2012** ------- A problem I'm having with understanding the Rosetta Stone[2] paper, is that we have different concepts of what an |object| is. Because I'm steeped in concepts of object-oriented (OO) analysis, design, and programming, I can't help but think of objects in that way. But objects in the Rosetta Stone paper may have more to do with pre-OO computer science concepts and languages. Section 2.2 of the paper (Categories p.5) defines |category| and provides some simple examples of objects and morphisms. I can understand this better if I look for an analogy with the pre-OO C programming language. The diagrams in that section of the paper represent objects as labels on input and output wires (ex: X Y), and morphisms as labeled ellipses (ex: f g). These objects look like low-level data-types such as integers, real numbers, and booleans. The simple diagram on page 6 (rotated 90° here so it takes less space) :: X +---+ Y -->--| f |-->-- +---+ has an input wire of type X, an output wire of type Y, and a morphism |f:X --> Y|. My understanding of what this means is captured by the code in the JavaScript editor further down on this page. To run this example :: Click the Run button at the top of the page. This will create a runtime overlay. Copy the 4 lines of code from the JavaScript editor, starting with the "var x = 13" line and ending with the complete "print" line. Paste these lines of code into the textarea of the overlay. Click the Submit button in the overlay. It should display "f(13) = 169" This is different from the Object-Oriented (OO) paradigm where f would be a method in some object of a certain type (class) that knows how to do this type of morphism. X and Y would be thought of as input and output data, possibly objects in their own right (instances of class X and class Y). I have noted in the past that algebraic and OO approaches invert each others notations. For example, in an editor further down on this page, I represent the statement "the height of the block is 0.1 meters" as :: <Block> <Height>0.1 m</Height> </Block> Height is an attribute of Block. In algebra this is represented as :: h_B = 0.1 m where h_B means h subscript B. It could even be just :: h = 0.1 So mathematicians are primarily concerned with numeric values, while OO software developers are more concerned (initially) with the objects that contain the numeric values. I think of the object that f is in as being an |active object|, while the instances of X and Y are |passive objects|. The Rosetta Stone paper defines category :: Deﬁnition 1 A category C consists of: • a collection of objects, where if X is an object of C we write X ∈ C, and • for every pair of objects (X, Y), a set hom(X, Y) of morphisms from X to Y. We call this set hom(X, Y) a homset. If f ∈ hom(X, Y), then we write f : X → Y. I'm not sure from this if the "objects" are OO classes, or instances of classes (OO objects). Wikipedia[5] defines category, using the word "class" as defined in Set Theory :: A category C consists of • a class ob(C) of objects • a class hom(C) of morphisms, or arrows, or maps, between the objects. Each morphism f has a unique source object a and target object b where a and b are in ob(C). We write f: a → b, and we say "f is a morphism from a to b". We write hom(a, b) (or homC(a, b) when there may be confusion about to which category hom(a, b) refers) to denote the hom-class of all morphisms from a to b. (Some authors write Mor(a, b) or simply C(a, b) instead.) References :: (1) http://johncarlosbaez.wordpress.com/2011/01/18/petri-nets/ (2) http://arxiv.org/abs/0903.0340 (3) http://math.ucr.edu/home/baez/week296.html Electrical circuits (4) http://math.ucr.edu/home/baez/week288.html analogies between circuits and other systems (5) http://en.wikipedia.org/wiki/Category_(mathematics) ]]></Notes> <script implName="lang:python:inline:"><![CDATA[ print "symmetric monoidal category" ]]></script> <script implName="lang:javascript:inline:"><![CDATA[ var x = 13; // input wire of type X (numeric) var f = function(x) {return x * x;} // a morphism from X to Y var y = f(x); // output wire of type Y (numeric) print("\n f(" + x + ") = " + y); ]]></script> <_-.XholonClass>  <PhysicalSystem/> <Block/>  <Height superClass="Length"/> </_-.XholonClass> <xholonClassDetails> <Block> <port name="height" connector="#xpointer(Height)"/> </Block> </xholonClassDetails> <PhysicalSystem> <Block> <Height>0.1 m</Height> </Block> </PhysicalSystem> <Blockbehavior implName="lang:python:inline:"><![CDATA[ # This works if pasted in as a last child of Block. height.incVal(0.02) print("Python wants something to do. Height:" + str(height)) ]]></Blockbehavior> <Blockbehavior implName="lang:javascript:inline:"><![CDATA[ // This works if pasted in as a last child of Block. height.incVal(0.02); print("JavaScript wants something to do. Height:" + height + "\n"); ]]></Blockbehavior> <Blockbehavior implName="lang:webEditionjs:inline:"><![CDATA[ this.bindPorts(this.parent()); this.height.incVal(0.02); print("\nJavaScript wants something to do. Height:" + this.height.attr('val')); ]]></Blockbehavior> <Blockbehavior implName="lang:bsh:inline:"><![CDATA[ // This works if pasted in as a last child of Block. height.incVal(0.02); System.out.print("Java/Beanshell wants something to do. Height:" + height + "\n"); ]]></Blockbehavior> <Blockbehavior implName="lang:jruby:inline:"><![CDATA[ require 'java' # This works if pasted in as a last child of Block. $height.incVal(0.02) puts "Ruby wants something to do. Height: #{$height}" ]]></Blockbehavior> <Blockbehavior implName="lang:groovy:inline:"><![CDATA[ // This works if pasted in as a last child of Block. height.incVal(0.02); System.out.print("Groovy wants something to do. Height:" + height + "\n"); ]]></Blockbehavior> <SvgClient><Attribute_String roleName="svgUri"><![CDATA[data:image/svg+xml, <svg width="100" height="50" xmlns="http://www.w3.org/2000/svg"> <g> <title>Block</title> <rect id="PhysicalSystem/Block" fill="#98FB98" height="50" width="50" x="25" y="0"/> <g> <title>Height</title> <rect id="PhysicalSystem/Block/Height" fill="#6AB06A" height="50" width="10" x="80" y="0"/> </g> </g> </svg> ]]></Attribute_String><Attribute_String roleName="setup">${MODELNAME_DEFAULT},${SVGURI_DEFAULT}</Attribute_String></SvgClient> </XholonWorkbook>