|
<?xml version="1.0" encoding="UTF-8"?> |
|
<!--Xholon Workbook http://www.primordion.com/Xholon/gwt/ MIT License, Copyright (C) Ken Webb, Mon Feb 24 2020 08:07:52 GMT-0500 (Eastern Standard Time)--> |
|
<XholonWorkbook> |
|
|
|
<Notes><![CDATA[ |
|
Xholon |
|
------ |
|
Title: Realizing applied category theory in Julia |
|
Description: |
|
Url: http://www.primordion.com/Xholon/gwt/ |
|
InternalName: 6c264fef74eb81401cb43a95d02bfcf8 |
|
Keywords: |
|
|
|
My Notes |
|
-------- |
|
February 6, 2020 |
|
|
|
Evan Patterson gave a presentation during the 2020 MIT course "Programming with Categories". |
|
|
|
Graphviz (no braiding in Graphviz?; my Graphviz implementation is incorrect in various ways) |
|
-------- |
|
graph G { rankdir = LR; label = "video 19:00, but without the braiding" |
|
|
|
1 [shape = point] [fillcolor = white] [color = white] |
|
2 [shape = point] [fillcolor = white] [color = white] |
|
3 [shape = point] [fillcolor = white] [color = white] |
|
4 [shape = point] [fillcolor = white] [color = white] |
|
|
|
// objects ? |
|
//A B C |
|
|
|
// functions |
|
f [shape=box] [style = rounded] |
|
g [shape=box] [style = rounded] |
|
h [shape=box] [style = rounded] |
|
|
|
1 -- f |
|
2 -- g |
|
f -- h |
|
g -- h |
|
h -- 3 |
|
h -- 4 |
|
} |
|
|
|
|
|
References |
|
---------- |
|
(1) https://www.youtube.com/watch?v=7dmrDYQh4rc |
|
Evan Patterson: Realizing Applied Category Theory in Julia |
|
|
|
(2) https://roamresearch.com/#/app/programming-with-categories/page/ZHTUvANK5 |
|
I exported davidas's notes for Evan Patterson's presentation, as markdown, and pasted these into the Markdown section below. |
|
|
|
(3) http://brendanfong.com/programmingcats.html |
|
18.S097: Programming with Categories |
|
|
|
(4) https://github.com/epatters/Catlab.jl |
|
An experimental framework for applied category theory |
|
|
|
(5) https://www.epatters.org/ |
|
Evan Patterson, Stanford University, Statistics Department |
|
I'm a PhD student working to improve the scientific process through research in... |
|
Statistics and ML |
|
Software systems |
|
Applied category theory |
|
|
|
(6) https://www.epatters.org/papers/ |
|
Evan Patterson publications |
|
|
|
(7) https://arxiv.org/pdf/1909.10475v1.pdf |
|
String Diagrams for Assembly Planning, by Jade Master, Evan Patterson, Shahin Yousfi, and Arquimedes Canedo |
|
|
|
(8) https://github.com/epatters/wiring-diagram-canvas |
|
Wiring diagrams in HTML canvas |
|
Visualize wiring diagrams, also known as string diagrams, in the HTML canvas. |
|
The package is written in TypeScript, provides components for React, and interfaces with the HTML canvas using Konva.js. |
|
For now, the package provides only viewing, not editing, capabilities. Layout is handled by external tools like Graphviz. |
|
|
|
(9) https://www.epatters.org/projects/ |
|
|
|
(10) https://nbviewer.jupyter.org/github/epatters/Catlab.jl/blob/gh-pages/dev/generated/wiring_diagrams/wiring_diagram_basics.ipynb |
|
Basics of wiring diagrams |
|
view only |
|
"This website does not host notebooks, it only renders notebooks available on other websites." |
|
can download the notebook; JSON |
|
can run on binder; it sort of works? |
|
|
|
(11) https://raw.githubusercontent.com/epatters/Catlab.jl/gh-pages/dev/generated/wiring_diagrams/wiring_diagram_basics.ipynb |
|
downloaded notebook; JSON |
|
|
|
(12) https://github.com/epatters/Catlab.jl/blob/gh-pages/dev/generated/wiring_diagrams/wiring_diagram_basics.ipynb |
|
source |
|
|
|
(13) https://jupyter.org/ |
|
) https://jupyter.org/try |
|
|
|
(14) https://hub.gke.mybinder.org/user/binder-examples-demo-julia-9fh4jhjt/notebooks/demo.ipynb |
|
NOTE: This is a Julia demo for Binder, it's been adapted from the Julia demo on the nbconvert website. |
|
Binder is an open-source project and Julia support is early in development. |
|
This notebook uses IJulia: a Julia-language backend combined with the IPython interactive environment. |
|
This combination allows you to interact with the Julia language using IPython's powerful graphical notebook, |
|
which combines code, formatted text, math, and multimedia in a single document. |
|
KSW I get errors when I run some of the code blocks. |
|
|
|
(15) https://epatters.github.io/Catlab.jl/latest/ |
|
Catlab.jl Documentation |
|
KSW this seems to be the core documentation for Catlab |
|
|
|
]]></Notes> |
|
|
|
<markdown><![CDATA[ |
|
- davidad's notes from Evan Patterson's seminar "Realizing applied category theory in Julia" (2020-01-16, 17:00, MIT room 2-255) |
|
- # Introduction |
|
- Applications of category theory outside pure math |
|
- started in logic, type theory, and programming languages |
|
- Now spread to: |
|
- Quantum stuff |
|
- Chemistry (Petri nets) |
|
- Databases and knowledge representation |
|
- Control theory and robotics |
|
- Probability and statistics |
|
- But where are the tools? |
|
- In applied math, having the math is only half the story. |
|
- Applied math must ultimately feed back into better scientific and/or computational methods, |
|
- and in today's world software is a big part of how math becomes instantiated in a way that matters. |
|
- The tool ecosystem for computational category is very immature |
|
- There aren't really any standards, it's a bit of a wild wild west |
|
- Two views on CT's relationship to software |
|
- 1. **Designing with categories**: Like design patterns, but hopefully better, because they're based on more rigorous math. This is the philosophy that drives the [Programming with Categories] course. |
|
- 2. **Computing on categories**: What are the data structures and algorithms necessary to build a computer algebra system for category-theoretic questions? |
|
- This talk is really about the second one. |
|
- Catlab.jl |
|
- A pun on "Matlab" |
|
- A Julia package that aims to be: |
|
- A library that others could use as a starting point to apply CT in their domain |
|
- A computer algebra system for categories (aspirationally) |
|
- An interactive computing environment with CT aspects (the work here is being done mostly by Jupyter, so far) |
|
- Some specific features: |
|
- Ability to work with symbolic expressions |
|
- Rendering string diagrams |
|
- Rendering symbolic expressions into executable Julia code |
|
- A way of looking at these features is translations between 3 representations: |
|
- Graphical syntax |
|
- Symbolic syntax |
|
- Executable code |
|
- Why use Julia for ACT? |
|
- Julia is a modern programming language with |
|
- Multiple dispatch |
|
- Unicode operators |
|
- A powerful macro system allowing custom syntax |
|
- Julia is also practical: |
|
- Designed to be fast |
|
- JIT compiler |
|
- Growing adoption in conventional applied math community |
|
- I'd like to see ACT be part of broader applied math, and see Julia as one way to connect to optimization, stats, etc. |
|
- Other existing Computational Category Theory projects |
|
- Cateno by Jason Morton (unmaintained since 2015, but in Julia & a direct inspiration) |
|
- Categorical Query Language (CQL) by Conexus AI (AGPL/proprietary), cofounded by David Spivak |
|
- Solves word problems in finitely presented categories |
|
- Statebox |
|
- Rewriting and proof assistants for monoidal/higher categories |
|
- Quantomatic |
|
- Globular |
|
- Cartographer |
|
- Homotopy.io |
|
- # Major Features |
|
- ## Signatures |
|
- This is not quite Julia code because Julia doesn't have dependent types, but this macro will get something out of this |
|
- Two ways to instantiate a signature: |
|
- 1. As Julia functions on concrete data types (@instance) |
|
- 2. As typed systems of symbolic expressions (@syntax) |
|
- Example of first kind: instance of Category with (type, dimension) pairs as objects and matrices as morphisms |
|
- This is defined as Julia functions |
|
- Composition is defined in terms of Julia's built-in matrix multiplication |
|
- Example of second kind: |
|
- We can leave the @syntax empty, and still be able to manipulate objects and morphisms built from free variables |
|
- With __no__ simplification logic, the associativity law is not true: (f⨾g)⨾h compares unequal to f⨾(g⨾h) |
|
- We can define symbolic expressions that normalize at construction, e.g. by associating to the left and removing units, or just representing morphisms as lists. |
|
- Signatures are based on Generalized Algebraic Theories (GAT), invented by Cartnell in his PhD thesis. |
|
- GATs are like algebraic theories with types, and a simple form of "dependent" types. |
|
- A classic example is that $$\mathrm{Hom}$$ in a category is a type that depends on two terms of $$\mathrm{Ob}$$ |
|
- Same expressivity as Essentially Algebraic Theories |
|
- **Caveat**: Right now catlab doesn't support __axioms__ of algebraic theories, just the signature part. In the future maybe we'll support writing down axioms and even maybe trying to validate them somehow. |
|
- **Wanted**: Math and data structures for treating GATs, or "doctrines" (like "compact closed") as **data**. |
|
- To create new ones from old ones, etc. |
|
- What's the right way? Food for thought... |
|
- But for now I'm just working with these GATs. |
|
- ## Wiring Diagrams |
|
- Also sometimes known as [[string diagrams]] (in physics and ACT) or "port graphs" (in CS) |
|
- Two kinds of wiring diagrams: |
|
- ### Combinatorial: wiring diagrams **as data structures** |
|
- Implemented on top of digraphs from LightGraphs.jl |
|
- Each box in the diagram corresponds to a vertex |
|
- Two special vertices represent the dangling wires |
|
- Arbitrary metadata on boxes, ports, and wires |
|
- Two interfaces for this data structure: |
|
- **Imperative**: Mutate by adding/removing boxes and wires |
|
- **Categorical**: composing and tensoring |
|
- Wiring diagrams are instances of `SymmetricMonoidalCategory` |
|
- Extra structure on the category (like closed) can be modeled by adding a type parameter (?) |
|
- Wiring diagrams as an operad |
|
- Composition in this operad is **substitution** |
|
- Inverse of substitution is **encapsulation** (may not be the standard name): replacing a subdiagram with a single box |
|
- ### Topological: wiring diagrams as **diagrams**, embedded in $$\mathbb{R}^2$$ |
|
- One way to get a wiring diagram layout is by making a morphism expression and treating it as a binary space partitioning tree |
|
- A completely different way is to pipe it out to a tool for generically visualizing directed graphs (specifically `graphviz`) |
|
- We can also draw out to TikZ |
|
- Translating between wiring diagrams and morphism expressions |
|
- Morphism expressions $$\rightarrow$$ wiring diagrams |
|
- Easy |
|
- Uniquely defined |
|
- Wiring diagrams $\rightarrow$ morphism expressions |
|
- Not uniquely defined (interchange law) |
|
- Not easy! |
|
- Algorithm inspired by "series-parallel digraphs" (Valdes et al 1982; Mitchell 2004) |
|
- Caveat: need to make math out of this adaptation of the algorithm! |
|
- Algorithm tries to maximize parallelism ("prefers $$\circ$$ over $$\otimes$$") |
|
- It's based on "series and parallel reductions": partially turning parts of the wiring diagram into morphism expressions in some order until it's all just a morphism expression |
|
- Is this the best algorithm for this? Is it even a good algorithm? I don't know |
|
- Question: are the wiring diagrams morphisms in a bicategory? |
|
- Maybe, because rewriting morphisms are 2-cells? |
|
- Normalization by round-trip? |
|
- Making a morphism expression into a wiring diagram and then back into a morphism expression __seems__ to be finding a normal form |
|
- But does it really always work? I don't know |
|
- $$\mathrm{roundtrip}(\Delta_{A \otimes B}) = (\Delta_A \otimes \Delta_B)\, ⨾\, (\mathrm{id}_A \otimes \sigma_{A,B} \otimes \mathrm{id}_B)$$ |
|
- This is one of the axioms David and Brendan state for a supply of comonoids—interesting! |
|
- ## Executable code |
|
- It's convenient to specify the available functions as part of a finite presentation of a category |
|
- `compile_expr` takes a morphism expression and translates it into Julia code, bottoming out at those generators |
|
- We can also translate from some fragment of Julia syntax into a wiring diagram! |
|
- Question: what about programs that aren't circuits? e.g. that have looping? |
|
- In category theory, looping is often represented by traces (the ability to have traces) |
|
- But I haven't done that yet. |
|
- For now, these programs that you can do this with, don't have any control flow. |
|
- # Applications |
|
- ### Semantics of data science code |
|
- Project at IBM Research AI and at Stanford |
|
- Take code that's doing data analysis or machine learning, and extract a semantic representation, independent of the languages or libraries being used. |
|
- Motivation is to be able to compare analyses that were conducted in different tech stacks on a kind of equal footing |
|
- There's an ontology-based approach to this ("Data Science Ontology") |
|
- Language-specific analyzer produces dataflow representation of a program |
|
- Catlab.jl is used to do more transforms on the wiring diagram |
|
- Question: what kind of transforms? |
|
- Basically, a monoidal functor. |
|
- I'm expanding some of the boxes |
|
- ### Compositional assembly planning |
|
- As a proxy for a realistic robotic assembly domain, we used LEGO assembly simulated in Minecraft |
|
- Assembly planning was carried out partially by simplifying wiring diagrams in Catlab |
|
- I think planning in general is an area that is very ripe for ACT |
|
- ### Scientific model augmentation |
|
- This group is interested in semantic representation and model transformation for scientific models, mostly epidemiology so far |
|
- E.g. translating between agent-based and differential equation based models that represent similar assumptions |
|
- # Future Directions |
|
- Many opportunities for mathematical, algorithmic, and implementation work |
|
- Computer algebra directions |
|
- Declarative, rule-based rewriting for |
|
- symbolic expressions |
|
- wiring diagrams |
|
- Solving word problems |
|
- Calculating hom-sets |
|
- GATs and beyond |
|
- "Standard library" for ACT |
|
- Linear algebra (some demos are a goal for 2020) |
|
- Two different categories depending on which monoidal product you focus on: |
|
- $$\oplus$$: Graphical linear algebra ($$\mathsf{LinRel}$$, category of linear relations) |
|
- $$\otimes$$: Tensor networks and categorical quantum mechanics |
|
- Knowledge representation |
|
- Ologs and/or relational ologs |
|
- Network theory: Markov processes, reaction nets, circuits, etc. |
|
- Decorated cospans and/or structured cospans |
|
- Resources |
|
- https://github.com/epatters/Catlab.jl |
|
- Julia language Slack #catlab |
|
- evan (at) epatters dot org |
|
- Q&A |
|
- What happens when you have a second tensor structure, like in linear logic? |
|
- This has been a problem for a long time, I don't know a good answer |
|
- That would be a very practical thing for people to try to figure out what's a good way to handle those kind of situations |
|
- What happens when you go from wiring diagram to expression to wiring diagram? |
|
- You should always get the same wiring diagram back |
|
- The vertex labels might have gotten switched, but up to graph isomorphism they should be the same |
|
- Do you use port names or just indices? |
|
- Right now it's just indices |
|
- I was actually talking to David about this earlier today |
|
- Sometimes it's nice to have names, so it might be nice to support both |
|
- That being said, you could put names in there as part of arbitrary metadata, but it wouldn't be used in rendering or code generation or anything |
|
- Both the wiring diagrams and the symbolic expressions are point-free, so all the variables disappear in either of those representations |
|
- Could I add a rewrite like $$\sin^2 + \cos^2 = 1$$? |
|
- In a presentation, it will allow you to write that, but it won't really do anything |
|
- It would be nice to have some rewriting, but I don't want to reimplement Mathematica |
|
- You could really spend years and years making good rewriting |
|
- Maybe more like a proof assistant: users can do the rewrites if they do the work of showing where the apply? |
|
- What does CatLab actually do in assembly planning? |
|
- It's actually just providing data structures for the planning. The algorithms aren't built into CatLab; I'd like to see some growth in this area. |
|
- At the very least right now we're using CatLab to __represent__ these plans |
|
- And we're also using the functionality of going from wiring diagrams to expressions as part of the __scheduling__: which things do I want to do in parallel in a single time interval? |
|
- The wiring diagram tells you what you could do in parallel without really saying that you __will__. |
|
- This is one area where it's interesting to have different representations for morphisms; a more detailed representation can have an interesting interpretation |
|
- If you want to do simulation—what would be the next step toward implementing parameters and stepping through a simulation? |
|
- Minecraft is a discrete world, so for every time step, for each worker, I have to say what snap (if any) it performs. |
|
- Is there a place in this work where category theory comes in (in any of the three applications) separate from wiring diagrams? |
|
- In the semantic enrichment of code I think it's very natural to think of the process as a monoidal functor. |
|
- You can always take something expressed categorically and compile away the category theory if you want to, but... |
|
- It's not that CT is giving you a capability that you couldn't do without it, but what I hope for with CatLab is that certain processes appear in lots of different domains: a generic "planning and scheduling algorithm" could be used in lots of different domains that may not even look like scheduling |
|
- I think it's not always the right question to ask "what did CT let you do that you couldn't do before?", it's more "how well did it help you understand and connect it to other domains?" |
|
- What does it mean for the transformation of wiring diagrams to be functorial? |
|
- You can take each of the individual boxes and interpret it with the functor, and then put the results back together |
|
- Once you know this vocabulary, you can say in one sentence what it's doing ("monoidal functor") |
|
- You mentioned categorical quantum circuits; have you looked at libraries like Cirque or Kisket for simulating quantum circuits? |
|
- My goal with quantum would be to connect it to ITensor or Quantomatic |
|
|
|
----- |
|
**My notes and questions**, Ken Webb, February 24 2020 |
|
|
|
[Basics of wiring diagrams](https://epatters.github.io/Catlab.jl/latest/generated/wiring_diagrams/wiring_diagram_basics/#Generators-1) |
|
|
|
I am writing this partly to convince myself that I understand the "Basics of wiring diagrams" page. |
|
|
|
**Generators** |
|
|
|
Why is this section called "Generators"? What are Generators, and why is this significant in this case? The word "generator" is not used anywhere else on this web page. Presumably, the page is letting those who already know what a generator is, know that Catlab can handle generators. |
|
|
|
Example 1 - Generators: |
|
~~~ |
|
WiringDiagram{Catlab.Doctrines.BiproductCategory.Hom}([:A], [:B], |
|
[ 1 => {inputs}, |
|
2 => {outputs}, |
|
3 => Box(:f, [:A], [:B]) ], |
|
[ Wire((1,1) => (3,1)), |
|
Wire((3,1) => (2,1)) ]) |
|
~~~ |
|
|
|
I will now describe example 1 in my own words, with questions where I'm unsure. |
|
|
|
This is an example of a wiring diagram (or just "diagram" for short) in Catlab. |
|
|
|
**Catlab.Doctrines.BiproductCategory.Hom** |
|
|
|
A Catlab doctrine is a specific category, and can be either of two types, Ob (an object) or Hom (a morphism). I know about "Ob" and "Hom" from various places, including the page on "Symbolic expressions". |
|
|
|
What is a "BiproductCategory"? This may not be a very important question at this point. I know it's one of many (an infinite number of?) different types of category. |
|
|
|
There are four input parameters(?) to the wiring diagram: two sets of labels(?) [:A] and [:B], a collection/set of three boxes, and a collection/set of two wires. |
|
|
|
Each box is indexed by an integer ID. The IDs are 1-based (the first ID is 1, rather than 0 which would make it 0-based). Because they are indexes, they are three successive integers - 1 2 3. If there are n boxes, then the IDs would belong to the set {1,...,n}. |
|
|
|
In the statement **Box(:f, [:A], [:B]) ]**, is ":f" a label? It's internal to the wiring diagram, so :f is not one of the input parameters to the wiring diagram. But :A and :B are input parameters. |
|
|
|
I believe that :A and :B are types? |
|
|
|
The initial and final boxes are not shown, but are informally(?) labeled as "inputs" and "outputs". They pseudo exist on the diagram's "outer box". I would say they do exist, but only as ports on the "outer box". |
|
|
|
Probably "inputs" is a keyword signifying the collection/set of input parameters [:A], and "outputs" is a keyword signifying the collection/set of input parameters [:B]. |
|
|
|
Note to myself: ROOM/ObjecTime/eTrice offer multiple ways to handle inputs and outputs on an outer box. |
|
- as internal ports inside the outer box; conceptually these ports connect to the behavior of the outer box |
|
- as boxes inside a separate TestHarness box; and using relay ports + conjugated ports |
|
- variations of these |
|
|
|
~~~ |
|
This diagram is my sense of what's going on here. |
|
The outer box is the wiring digram, with |
|
inputs (labeled 1) on the left and |
|
outputs (labeled 2) on the right. |
|
The inner box is the function or morphism (Hom) f. |
|
I show each port with square brackets around it (ex: [1] ) |
|
|
|
1 2 |
|
+---------------------+ |
|
| | |
|
| +-----+ | |
|
| | | | |
|
[1] --> [1] 3 [1] --> [1] |
|
| A | f | B | |
|
| +-----+ | |
|
| | |
|
+---------------------+ |
|
~~~ |
|
|
|
Each box has zero(?) or more ports. A port can be an input port or an output port. Each port is labeled using a 1-based ID. If a box has both a set of input ports and a set of output ports, then each of these sets is separately labeled with IDs starting with 1. |
|
|
|
Each wire maps a source box and output port to a target box and input port. |
|
|
|
There are two wires in the wiring diagram. |
|
|
|
The first wire **Wire((1,1) => (3,1))** connects from box 1 output port 1, to box 3 input port 1. |
|
|
|
The second wire **Wire((3,1) => (2,1))** connects from box 3 output port 1, to box 2 input port 1. |
|
|
|
The next several examples on the Catlab webpage seem to confirm my understanding. |
|
|
|
Composition |
|
~~~ |
|
WiringDiagram{Catlab.Doctrines.BiproductCategory.Hom}([:A], [:C], |
|
[ 1 => {inputs}, |
|
2 => {outputs}, |
|
3 => Box(:f, [:A], [:B]), |
|
4 => Box(:g, [:B], [:C]) ], |
|
[ Wire((1,1) => (3,1)), |
|
Wire((3,1) => (4,1)), |
|
Wire((4,1) => (2,1)) ]) |
|
~~~ |
|
|
|
Monoidal products |
|
~~~ |
|
WiringDiagram{Catlab.Doctrines.BiproductCategory.Hom}([:A,:C], [:B,:D], |
|
[ 1 => {inputs}, |
|
2 => {outputs}, |
|
3 => Box(:f, [:A], [:B]), |
|
4 => Box(:h, [:C], [:D]) ], |
|
[ Wire((1,1) => (3,1)), |
|
Wire((1,2) => (4,1)), |
|
Wire((3,1) => (2,1)), |
|
Wire((4,1) => (2,2)) ]) |
|
~~~ |
|
|
|
Copy and merge, delete and create |
|
~~~ |
|
WiringDiagram{Catlab.Doctrines.BiproductCategory.Hom}([:B], [:B,:B], |
|
[ 1 => {inputs}, |
|
2 => {outputs}, |
|
], |
|
[ Wire((1,1) => (2,1)), |
|
Wire((1,1) => (2,2)) ]) |
|
~~~ |
|
|
|
TODO |
|
- do these examples in Haskell (I am currently learning Haskell). |
|
- be able to export the WiringDiagram syntax from my own Xholon applications/models/workbooks |
|
- implement these WiringDiagram examples in Xholon |
|
- take notes on other portions of the Catlab documentation |
|
|
|
]]></markdown> |
|
|
|
<_-.XholonClass> |
|
|
|
<!-- domain objects --> |
|
<PhysicalSystem/> |
|
<Block/> |
|
<Brick/> |
|
|
|
<!-- quantities --> |
|
<Height superClass="Quantity"/> |
|
|
|
</_-.XholonClass> |
|
|
|
<xholonClassDetails> |
|
<Block> |
|
<port name="height" connector="Height"/> |
|
</Block> |
|
</xholonClassDetails> |
|
|
|
<PhysicalSystem> |
|
<Block> |
|
<Height>0.1 m</Height> |
|
</Block> |
|
<Brick multiplicity="2"/> |
|
</PhysicalSystem> |
|
|
|
<Blockbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[ |
|
var a = 123; |
|
var b = 456; |
|
var c = a * b; |
|
if (console) { |
|
console.log(c); |
|
} |
|
//# sourceURL=Blockbehavior.js |
|
]]></Blockbehavior> |
|
|
|
<Heightbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[ |
|
var myHeight, testing; |
|
var beh = { |
|
postConfigure: function() { |
|
testing = Math.floor(Math.random() * 10); |
|
myHeight = this.cnode.parent(); |
|
}, |
|
act: function() { |
|
myHeight.println(this.toString()); |
|
}, |
|
toString: function() { |
|
return "testing:" + testing; |
|
} |
|
} |
|
//# sourceURL=Heightbehavior.js |
|
]]></Heightbehavior> |
|
|
|
<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[ |
|
$wnd.xh.Brickbehavior = function Brickbehavior() {} |
|
|
|
$wnd.xh.Brickbehavior.prototype.postConfigure = function() { |
|
this.brick = this.cnode.parent(); |
|
this.iam = " red brick"; |
|
}; |
|
|
|
$wnd.xh.Brickbehavior.prototype.act = function() { |
|
this.brick.println("I am a" + this.iam); |
|
}; |
|
//# sourceURL=Brickbehavior.js |
|
]]></Brickbehavior> |
|
|
|
<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[ |
|
console.log("I'm another brick behavior"); |
|
]]></Brickbehavior> |
|
|
|
<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> |
|
|
|
<svg width="232pt" height="123pt" viewBox="0.00 0.00 232.43 122.80" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> |
|
<g id="graph1" class="graph" transform="scale(1 1) rotate(0) translate(4 118.8)"> |
|
<title>G</title> |
|
<polygon fill="white" stroke="white" points="-4,5 -4,-118.8 229.426,-118.8 229.426,5 -4,5"></polygon> |
|
<text text-anchor="middle" x="112.213" y="-8.2" font-family="Times,serif" font-size="14.00">video 19:00, but without the braiding; my Graphviz implementation is incorrect in various ways</text> |
|
<!-- 1 --> |
|
<g id="node1" class="node"><title>1</title> |
|
<ellipse fill="white" stroke="white" cx="2.2132" cy="-96.8" rx="1.8" ry="1.8"></ellipse> |
|
</g> |
|
<!-- f --> |
|
<g id="node5" class="node"><title>f</title> |
|
<polyline fill="none" stroke="black" points="82.2132,-114.8 52.2132,-114.8 "></polyline> |
|
<path fill="none" stroke="black" d="M52.2132,-114.8C46.2132,-114.8 40.2132,-108.8 40.2132,-102.8"></path> |
|
<polyline fill="none" stroke="black" points="40.2132,-102.8 40.2132,-90.8 "></polyline> |
|
<path fill="none" stroke="black" d="M40.2132,-90.8C40.2132,-84.8 46.2132,-78.8 52.2132,-78.8"></path> |
|
<polyline fill="none" stroke="black" points="52.2132,-78.8 82.2132,-78.8 "></polyline> |
|
<path fill="none" stroke="black" d="M82.2132,-78.8C88.2132,-78.8 94.2132,-84.8 94.2132,-90.8"></path> |
|
<polyline fill="none" stroke="black" points="94.2132,-90.8 94.2132,-102.8 "></polyline> |
|
<path fill="none" stroke="black" d="M94.2132,-102.8C94.2132,-108.8 88.2132,-114.8 82.2132,-114.8"></path> |
|
<text text-anchor="middle" x="67.2132" y="-92.6" font-family="Times,serif" font-size="14.00">f</text> |
|
</g> |
|
<!-- 1--f --> |
|
<g id="edge2" class="edge"><title>1--f</title> |
|
<path fill="none" stroke="black" d="M4.30668,-96.8C8.65295,-96.8 25.1925,-96.8 40.0827,-96.8"></path> |
|
</g> |
|
<!-- 2 --> |
|
<g id="node2" class="node"><title>2</title> |
|
<ellipse fill="white" stroke="white" cx="2.2132" cy="-42.8" rx="1.8" ry="1.8"></ellipse> |
|
</g> |
|
<!-- g --> |
|
<g id="node6" class="node"><title>g</title> |
|
<polyline fill="none" stroke="black" points="82.2132,-60.8 52.2132,-60.8 "></polyline> |
|
<path fill="none" stroke="black" d="M52.2132,-60.8C46.2132,-60.8 40.2132,-54.8 40.2132,-48.8"></path> |
|
<polyline fill="none" stroke="black" points="40.2132,-48.8 40.2132,-36.8 "></polyline> |
|
<path fill="none" stroke="black" d="M40.2132,-36.8C40.2132,-30.8 46.2132,-24.8 52.2132,-24.8"></path> |
|
<polyline fill="none" stroke="black" points="52.2132,-24.8 82.2132,-24.8 "></polyline> |
|
<path fill="none" stroke="black" d="M82.2132,-24.8C88.2132,-24.8 94.2132,-30.8 94.2132,-36.8"></path> |
|
<polyline fill="none" stroke="black" points="94.2132,-36.8 94.2132,-48.8 "></polyline> |
|
<path fill="none" stroke="black" d="M94.2132,-48.8C94.2132,-54.8 88.2132,-60.8 82.2132,-60.8"></path> |
|
<text text-anchor="middle" x="67.2132" y="-38.6" font-family="Times,serif" font-size="14.00">g</text> |
|
</g> |
|
<!-- 2--g --> |
|
<g id="edge4" class="edge"><title>2--g</title> |
|
<path fill="none" stroke="black" d="M4.30668,-42.8C8.65295,-42.8 25.1925,-42.8 40.0827,-42.8"></path> |
|
</g> |
|
<!-- 3 --> |
|
<g id="node3" class="node"><title>3</title> |
|
<ellipse fill="white" stroke="white" cx="222.213" cy="-80.8" rx="1.8" ry="1.8"></ellipse> |
|
</g> |
|
<!-- 4 --> |
|
<g id="node4" class="node"><title>4</title> |
|
<ellipse fill="white" stroke="white" cx="222.213" cy="-58.8" rx="1.8" ry="1.8"></ellipse> |
|
</g> |
|
<!-- h --> |
|
<g id="node7" class="node"><title>h</title> |
|
<polyline fill="none" stroke="black" points="172.213,-87.8 142.213,-87.8 "></polyline> |
|
<path fill="none" stroke="black" d="M142.213,-87.8C136.213,-87.8 130.213,-81.8 130.213,-75.8"></path> |
|
<polyline fill="none" stroke="black" points="130.213,-75.8 130.213,-63.8 "></polyline> |
|
<path fill="none" stroke="black" d="M130.213,-63.8C130.213,-57.8 136.213,-51.8 142.213,-51.8"></path> |
|
<polyline fill="none" stroke="black" points="142.213,-51.8 172.213,-51.8 "></polyline> |
|
<path fill="none" stroke="black" d="M172.213,-51.8C178.213,-51.8 184.213,-57.8 184.213,-63.8"></path> |
|
<polyline fill="none" stroke="black" points="184.213,-63.8 184.213,-75.8 "></polyline> |
|
<path fill="none" stroke="black" d="M184.213,-75.8C184.213,-81.8 178.213,-87.8 172.213,-87.8"></path> |
|
<text text-anchor="middle" x="157.213" y="-65.6" font-family="Times,serif" font-size="14.00">h</text> |
|
</g> |
|
<!-- f--h --> |
|
<g id="edge6" class="edge"><title>f--h</title> |
|
<path fill="none" stroke="black" d="M94.6161,-88.6991C105.855,-85.2507 118.928,-81.2396 130.132,-77.8021"></path> |
|
</g> |
|
<!-- g--h --> |
|
<g id="edge8" class="edge"><title>g--h</title> |
|
<path fill="none" stroke="black" d="M94.6161,-50.9009C105.855,-54.3493 118.928,-58.3604 130.132,-61.7979"></path> |
|
</g> |
|
<!-- h--3 --> |
|
<g id="edge10" class="edge"><title>h--3</title> |
|
<path fill="none" stroke="black" d="M184.566,-74.4013C199.672,-77.0388 216.4,-79.9597 220.347,-80.6487"></path> |
|
</g> |
|
<!-- h--4 --> |
|
<g id="edge12" class="edge"><title>h--4</title> |
|
<path fill="none" stroke="black" d="M184.566,-65.1987C199.672,-62.5612 216.4,-59.6403 220.347,-58.9513"></path> |
|
</g> |
|
</g> |
|
</svg> |
|
]]></Attribute_String><Attribute_String roleName="setup">${MODELNAME_DEFAULT},${SVGURI_DEFAULT}</Attribute_String></SvgClient> |
|
|
|
</XholonWorkbook> |
