A simple proof checker for teaching

For the last few years I have been teaching functional programming to first year students. One of the main benefits of using functional programming is that you can prove simple, but non-trivial, properties of simple programs, for example, that the empty list is right-neutral for append:

append xs [] = xs

The practical problem with teaching a large group of students is that you end up with a large pile of assignments to check, which means a large number of teaching assistants of various degrees of competence in reading and understanding proofs. Note that for programming assignments we didn’t have this problem because we could use automated random unit testing. Pedagogically, having inconsistent marking standards is not only irritating to students but potentially devastating in the final exam if TAs habitually accept wrong proofs as correct in the assignments. The final exam is marked by me, and I may not be as blind to mistakes.

One possibility is to use proof assistants such as Coq, Agda or Isabelle, but they are a bit too intricate for first year students who are just learning the basics of proofs, logic, recursion and induction. What we want is a proof checker tailored to the needs of the beginning student. These were our design principles:

  1. The syntax of production-level proof assistants aims for concision, elegance and expressiveness. Our aim was a syntax that matched as much as possible the informal mathematical vernacular that students are used to from pen-and-paper proofs.
  2. Production-level proof assistants have various levels of interaction and automation which are not only useless to the beginning student but actively get in the way of learning proof techniques because they may encourage a trial-and-error approach to proofs. Also, very simple fragments such as pure propositional may be entirely automated in such proof assistants.
  3. Even production-level proof assistants can be annoyingly clumsy when it comes to writing equational proofs. However, most of the proofs that we ask our students are equational. Doing congruence reasoning comes very easy to students, but doing it in proof assistants formally is a pain. This aspect is something we wanted automated.
  4. We also need a generally high level of user-friendliness.

The source code, documentation and a range of examples from the simplest to moderately complicated are available on Github. Here I am just going to give the proof for the very simple example above. If you find it appealing I recommend you read the full documentation on-line.

append : 'a list -> 'a list -> 'a list ;
[append nil]: forall xs:'a list.
              append [] xs = xs : 'a list ;
[append ys]:  forall xs:'a list. forall ys:'a list. forall y:'a.
              append (y::ys) xs = y :: append ys xs : 'a list ;
Theorem [append neutral]:
Statement: forall xs:'a list.
           append xs [] = xs :'a list 
Proof: by induction on list :
case []:
 we know [0]: append [] [] = [] :'a list
              because [append nil] with ([]) .
 by [0]
case (hd :: tl):
 [IH]: append tl [] = tl : 'a list .
 we know [1]: append (hd :: tl) [] = hd :: (append tl []) :'a list
              because [append ys] with ([], tl, hd) .
 we know [2]: append (hd :: tl) [] = hd :: tl : 'a list
              because equality on ([1], [IH]) .
 by [2]

A comparison with the Agda equivalent is perhaps a good illustration of our trading off succinctness for readability. Note especially the need for an explicit congruence principle in the Agda proof. The list data type and append (++) are pre-defined. (Coq is not really comparable because it is tactics-based.)

cong-∷ : {A : Set} → (x : A) → ∀ xs ys → xs ≡ ys → x ∷ xs ≡ x ∷ ys
cong-∷ x xs .xs refl = refl
unitr[] : {A : Set} → (xs : List A) → xs ++ [] ≡ xs
unitr[] [] = refl
unitr[] (x ∷ xs) = Goal where
 p : xs ++ [] ≡ xs
 p = unitr[] xs 
 Goal : x ∷ (xs ++ []) ≡ x ∷ xs
 Goal = cong-∷ x (xs ++ []) xs p

The author of the tool is my intern student Yu-Yang Lin, with essential supervision and help from Neel Krishnaswami. Funding for the project was provided by the College of Engineering and Physical Science, University of Birmingham.

Your feedback is most welcome! Even more welcome are more examples, bug reports and bug fixes. If you are looking to make a more substantial contribution, parsing errors could be vastly improved.

Posted in General | Leave a comment

What things compute?

I suppose we can agree that computers compute. We know that they do that because we make them do that. We have a program, on paper or in our head, and we have certain facilities to load that program into the computer memory. This is called implementing the program. Then, when the program runs we can compare the actual behaviour of the physical computer with the expected behaviour defined by the abstract program. Note that this expected behaviour we can determine “by hand” via manual calculations, at least in principle. Programs in the abstract are mathematical objects, programs in the concrete are behaviours of physical devices we call computers. I suspect trained computer scientists will find very little controversial (or exciting) in the clarification above. This is the so-called “implementation theory” of computing, advocated among others by the influential cog-sci philosopher David Chalmers.

This definition is, I would say, sound in the sense that things and behaviours that are described by it are always computation. But is it complete? Are there notions of computation that fall outside of it? If we say “no” then we should expand the definition somehow — lets get back to that. But if we say “yes”, then what are the consequences? Implementation theory assumes that the abstract program defines the concrete program, which is an instance of it. A computer is then a device that accelerates computation by some physical means. The crucial assumption is that the abstract program, as a mathematical object, requires design and therefore intent. Accordingly, only artificial things can compute. We cannot say, for example, that a brain computes. There seems to be something that resembles “information processing” or “computation” in the way a brain behaves, but we don’t actually have the anchoring reference that is the abstract program to compare it with and say that it is an implementation of it. This may seem like nit-picking but it’s a genuine problem.

Outside artificial things designed to compute, i.e. computers, what else computes? What is computation, if anything, as a natural phenomenon? I haven’t seen a good answer so far. I have seen however two classes of bad answers.

The first bad answer is something that has to do with a “system” having “inputs” and “outputs”. This is bad on two accounts — without even going into the deeper philosophical problems of causation as a scientific concept. The first problem is that any natural system has many things that can be considered as “inputs” and “output”. For example if we throw a rock, and we take the initial velocity vector as an input and its space-time coordinates as an output, we can say that it is a system that computes a parabola tangent to that vector. But there is necessary intent in the choice of what measurements are considered as inputs and output. Any object has a trajectory in a highly-dimensional space of properties, and any projection of that trajectory on a lower-dimensional space of measurements defines a different computation. There is no one special computation the system performs. If we take intent out of the equation we have an incomprehensibly large state space and an incomprehensibly complicated trajectory through it, tracking everything down to atomic-level configurations. The second problem is that such broad definitions can quickly degenerate into pancomputationalism: everything computes. And, if everything computes, computation is an uninteresting concept. The brain computes, but so does a piece of wood. Computation is simply another word for behaviour subject to (natural) laws. The Universe is a big computer, computing its own future — grand but somewhat vacuous.

The second bad answer is something that has to do with “processing symbolic information”. As in the case of selecting particular measurements of a system as inputs and outputs, the notion of “symbol” requires not only intent but also, outside of a formal setting, very special powers of of abstraction — think about how many concrete shapes a symbol such as the letter ‘a’ can take. We know the human brain can process symbolic information, but we are far from certain any other kinds of brain can do that, so this definition rules them out as computing things. Also, the process of defining and recognising symbols itself is a prerequisite of computation, but not part of computation itself — which strikes me as odd. Whereas the input-output attempted definition is too broad, this is both too precise and too reliant on concepts that require further clarification. It is tantamount to saying “computation is what the human brain can do”. It does not explain the brain using computation, it uses the brain as an explanation for computation.

In conclusion I want to shatter our presumed consensus: computers do not compute. Not even computers. We compute. Computers just help us along. Implementation theory gives a lucid definition of computation: a relation between a pre-existing mathematical concept and the behaviour of a physical thing. The pre-existence of the mathematical concept is essential. Trying to fit a mathematical model on a pre-existing physical behaviour has a different name: scientific discovery. Where does this live computationalismthe theory that, broadly speaking, the brain is a computer and the mind a computation? I think it exposes its vacuity. A “computational theory of the mind” is along the same lines as having “a computational theory of the weather”, in which the earth is seen as a computer and the weather what it computes. It’s a metaphor that gives the illusion of understanding, without telling us whether tomorrow will rain or not — akin to using élan vital to “explain” life or scansoriality to “explain” propensity to climbing.

But perhaps I am being harsh. “Computation” is vacuous only when used as an explanation, as a first-class scientific concept. But it is not vacuous as an abstract concept or as a characterisation of a style of mathematical model or as a paradigm. The parallel between energy/work as used in physics and information/computation as used in cognitive science is quite striking. In his Lectures on Physics, Feynman has this to say about energy and energy conservation principles [PDF]. I think similar considerations apply to information and computation:

[Conservation of Energy] is a most abstract idea, because it is a mathematical principle; it says that there is a numerical quantity which does not change when something happens. It is not a description of a mechanism, or anything concrete; it is just a strange fact that we can calculate some number and when we finish watching nature go through her tricks and calculate the number again, it is the same. [...]

It is important to realize that in physics today, we have no knowledge of what energy is. We do not have a picture that energy comes in little blobs of a definite amount. It is not that way. However, there are formulas for calculating some numerical quantity, and when we add it all together it gives “28″—always the same number. It is an abstract thing in that it does not tell us the mechanism or the reasons for the various formulas.

For a good survey of the problem of defining computation I recommend Piccinini’s chapter on Computationalism in the Oxford Handbook of Philosophy and Cognitive Science.

Posted in anticomputationalism | 1 Comment

Leaving the Nest: variables with interleaving scopes

A paper [PDF] with this title, co-written with Jamie Gabbay and Daniela Petrişan, will appear in Computer Science Logic (CSL 2015). Actually the full title is Leaving the Nest: Nominal techniques for variables with interleaving scopes. The “nominal techniques” part is in reference to a new mathematics of names pioneered by Gabbay and Pitts in the late 1990s. In this post I will give a very brief and informal taster/introduction to nominal techniques then tell you why our paper is actually quite interesting.

Names are a peculiar data structure. There are only two things you can do with them. Given two names you can compare them, and given a finite set of names you can find a fresh name relative to them, i.e. a name that is not in that set. There is a perhaps subtle distinction to be made between names and concrete representation of names, which can be strings or integers. Concrete representation might allow other operations as well, such as concatenation or addition, but qua names they only have equality testing and fresh generation.

Because there are only very few things we can do with names and to names, nominal structures, i.e. data structures incorporating names have an interesting property called equivariance, which means informally that all meaningful properties of such structures are preserved by name permutations. What does this really mean? Consider the following OCaml program:

let x = ref () in let y = ref () in x == y;;

A new unit reference, a pointer is created and assigned to x, then another one to y, then they are compared for equality. This little program is always equivalent to false. No matter what pointer-values are returned by the memory management runtime of OCaml, they will always be different. The actual value of the pointers qua names must be irrelevant! This is why invariance is under permutation: they can change names but they will not map different names to equal names.  This simple and elegant principle leads to a powerful and elegant theory of names about which you can read in Andy Pitt’s excellent book.

Nominal techniques really come into their own when dealing with syntax which uses locally-scoped names, such that of the lambda calculus (e.g. λx.x) or predicate logic (e.g. ∀x.x=x). In a syntactic context, the principle of equivariance leads to an equivalence of terms up-to-renaming, commonly known as alpha-equivalence. So terms such as λx.x and λy.y are equivalent. Moreover, this equivalence is also a congruence (is preserved by syntax) so that we can work with equivalence classes under alpha-equivalence instead. This is done often informally in the study of syntax, but a solid mathematical understanding of names is actually required to ensure that recursive definitions over nominal structures — i.e. something as banal as substitution — are actually well defined.

A common theme in the literature, motivated by syntax, has been the use of names in inductively-defined structures, where name abstraction is a term-forming operation. By definition, these names are always well scoped, which means that their scopes are well nested. However, names can be used in a different way, not in the language itself but in the semantics, at the meta level, to mediate access to resources. Memory locations, file handlers, network sockets, etc.  are all examples of such resources which, much like names, can only be tested for equality and created: they are names. However, unlike syntactic names they can be not just created but also destroyed. And the pattern of creation and destruction doesn’t need to be well nested anymore.

For example, this is a sequence where the scopes of a, b, c are interleaved (we mark name-creation with ⟨ and name-destruction with ⟩): ⟨a ⟨b a⟩ ⟨c b⟩ c⟩. The name b is introduced after a is created and when is destroyed it is still “active”. With the (obvious) intuition of scope and alpha-equivalence, we should expect the sequence above to be equivalent to ⟨a ⟨c a⟩ ⟨b c⟩ b⟩.

In our paper we give a mathematical treatment of this phenomenon, focussing on what we believe to be the most interesting aspects: What does it mean for a variable to be free or bound in this setting? What is the right notion of alpha-equivalence when scopes are not well nested? How can we define proper functions on sequences that use names with interleaved scopes? We give syntactic, relational and algebraic models for alpha equivalence which coincide — this is certainly reassuring that we gave the right definitions.

An example which illustrates alpha equivalence and name capture quite well is interleaving of sequences with names. For example, what happens if we want to interleave the sequence ⟨a a⟩ with itself? The standard definition of sequence interleaving gives us two sequences: ⟨a a⟩ ⟨a a⟩ and ⟨a ⟨a a⟩ a⟩. However, taking into account the fact that ⟨a a⟩ = ⟨b b⟩ this should be the same as interleaving those two, which seems to give us six sequences: ⟨a a⟩ ⟨b b⟩, ⟨a ⟨b b⟩ a⟩, ⟨a ⟨b a⟩ b⟩, ⟨b b⟩ ⟨a a⟩, ⟨b ⟨a a⟩ b⟩ and ⟨b ⟨a b⟩ a⟩, but quotienting by alpha-equivalence (in the obvious way) we are left with three: ⟨a a⟩ ⟨b b⟩, ⟨a ⟨b b⟩ a⟩, ⟨a ⟨b a⟩ b⟩, which is still not the same as two. What is going on here?

⟨a a⟩ ⟨b b⟩ = ⟨a a⟩ ⟨a a⟩  – we can re-use bound variable ‘a’ instead of ‘b’
⟨a ⟨b b⟩ a⟩ = ⟨a ⟨a a⟩ a⟩  – we can reuse bound variable ‘a’ instead of ‘b’, noting that there is some name-shadowing going on

So we are left with ⟨a ⟨b a⟩ b⟩, which is the only one which genuinely requires two names in a situation akin to variable capture in the lambda calculus. With a proper notion of alpha-equivalence our definition of interleaving just works and we can skip such tedious analyses.

This has a neat diagrammatic representation — if you have read this blog you may have guessed that I like diagrams! The sequence ⟨a a⟩ represents the diagram , with the two endpoints delimiting the scope. This is nice because the name ‘a’ no longer appears, so it is “obvious” that

  • ⟨a a⟩ ⟨b b⟩ = ⟨a a⟩ ⟨a a⟩ = 
  • ⟨a ⟨b b⟩ a⟩ = ⟨a ⟨a a⟩ a⟩ = 
  • ⟨a ⟨b a⟩ b⟩ = 

In terms of more serious applications, formalisations of game semantics and other trace semantics should now further improve.

Before I sign off, a shout out to my student Bertie Wheen for proving some of the syntactic results in Agda.

Posted in programming languages | Leave a comment

Inventing an algebraic knot theory for eight year olds (V)

Towards Equations

We finally reconvened our maths club after a mid-term break (children not available) combined with the university exams period (me not available). I correctly assumed nobody remembered anything we talked about before. At least not in detail. Also, we had a significant number of new children joining our group, who had no idea about what we have been up to.

In the previous sessions we discovered and invented our notation, which consisted of three combinators (X, C, I) and three operations: composition (“gluing”), tensoring (“stacking”) and dual (“flipping”).



This time we just took this as a given, the starting point of our development. If the previous sessions were analytic, trying to decompose knots into basic constants and operations, this session was synthetic, starting with formulas and drawing them up and seeing what we get.

The first formula we contemplated was C;C*, which everyone immediately identified as a circle. The knot-theoretic name for this is the unknot, word which caused a certain amount of amusement. One student cleverly observed, unprompted, that (C;C*)* would have been the same thing, also an unknot, and we had a short discussion about how symmetry of a knot K boils down to K=K*. That was quite rewarding and fun and prepared the ground, somewhat serendipitously, for the next formula C;X;C*:

The same student rashly pointed out that this shape is also symmetric, i.e. C;X;C*=(C;X;C*)*. Is this true or false, qua knots?

The ensuing discussion was the most interesting and important part of the session. Initially the students were in majority supportive of the validity of the equation, then someone pointed out that X≠X* so, they reckoned, it must be that

Indeed, the shapes are not identical. The opinion of the group swung so they all agreed that the equation is not valid and the two shapes (original and flipped version) are not equal.

But aren’t they? What do you think? We are talking knots here, and two knots should be equal when they are topologically equal, i.e. they can be deformed into each other without any tearing and gluing. So in fact they are equal because:

So here we have a genuinely interesting equation, where two formulae are equal not because the shapes they correspond to are geometrically equal (i.e. “identical”) but because they are topologically equal, i.e. there is a smooth deformation between them. Also note that the deformation must be in 3D by “twisting” the left (or right) side of the unknot — a 2D transformation would make the wire “pinch” which may or may not be allowable, depending on how we precisely set things up (if we were very serious and careful about what we are doing).

The point was quickly grasped and we moved on. It is a subtle point which I think can be damaged by over-explaining if the initial intuitions are in the right place, which they seemed to be.

Next we looked at a much more complicated formula that took a long time to draw correctly: C;(I⨂C⨂I);(X⨂X*);(I⨂C*⨂I);C*.

As you may see, if we are drawing this as a knot and tidy things up a bit we actually have this:

Which is really just two unknots — they don’t interlock so they can be pulled apart with no tearing and gluing, i.e. topologically. The formula for this is the much simpler C;C*;C;C*!

This point was not easy to make, and it seemed difficult for the students to appreciate it. By this time they were quite tired and the drawing of the more complex formulation of the two unknots diagram drained them of energy and patience — they made quite a few errors and had to restart several times. Showing them a much easier way to achieve the same knot diagram almost made them angry!

I hope to use this as a motivation for the future: how to simplify a formula before we draw it. Until now we have looked at equality semantically, using the underlying model. In due course, as students become more used with manipulating knot diagrams using formulas, I will start introducing some general equational properties.

Posted in teaching | Leave a comment

Types: computation vs. interaction

Type Theory is at the moment the workhorse of programming language theory. It is an elegant, clever and incredibly useful framework for thinking about programming (for full disclosure, I have written several papers with the word “type” in the title). In this post I will not elaborate on the positives of Types but I will try to find at what point they become less useful. The argument below should be accessible to any programmer. To the theorist it will say nothing new, but it will say things that are not said often enough or clearly enough — I think. I hope it will not be too impolite. 

For me, this is an important exercise, because Type Theory is a collection of beautiful and seductive ideas, and as such it has the potential to get one carried away to extremes — like Marxism or Libertarianism. The beauty of Type Theory is not a pragmatic beauty. One is not (yet) in awe at what has been achieved with Type Theory. C and Javascript have this kind of pragmatic beauty, akin to Democratic Capitalism or Social Democracy. They succeed despite being messy and riddled with internal inconsistencies. They emerged, were not designed — or at least not in a principled way. Type Theory on the other hand has a beauty arising out of internal coherence, elegance and simplicity. The messy, illogical stuff is frowned upon. But can it be avoided? 

What does a computer do when it does not compute?

Lets ask a silly question first: What does a computer do? Like all simple questions, this one is steeped in ambiguity, so a simple answer cannot follow absent clarifications. What is a computer? Here there are two answers, depending whether we mean a conceptual computer, so the answer could be A Turing machine! or A von Neuman architecture! These are fine answers. But if you mean a physical computer you could say A MacBook! or An Android phone! These are also fine answers. But the language is already playing tricks on us. A conceptual computer computes, but a physical computer computes and interacts with its physical environment. 

A physical computer that merely computes will still interact with the environment, but in an unsatisfactory way: by consuming energy and warming up. For us, as users of physical computers, the computation is the boring part. Computation is what happens when a spinning wheel appears on the screen and the device becomes unresponsive. We don’t like computers when they compute, we like them when they interact. We consider them to do useful stuff when they drive physical devices. When they draw. When they sing and dance. When they forward that packet to the right node on the network. When they retrieve that interesting nugget of information from the TB hard-drive. 

Computation v. interaction provides some creative tension in the world of programming languages. Programming languages come from two directions. Some of them were birthed by logicians who wanted to get a grip on the foundations of mathematics, and who understood that computation played an important role there. This was the genesis of the lambda calculus. Modern programming languages that hail from this tradition include Haskell and the ML family (OCaml, SML, F#). Other programming languages were birthed by engineers who made physical computers and they needed to write programs for them. Fortran and C came about this way. And, of course, nowadays the two families seem to converge. Computational languages (aka “functional”) reluctantly allow interaction-oriented features (“imperative”) and all languages seem to boast of “lambdas” and “closures”, hallmarks of computational/functional languages.

Much energy has been spent proposing and defending precise definition of “functional” (or “declarative”) versus “imperative” languages, so lets not go there. In a futile attempt to avoid this controversy I will say “computational” languages for those languages and language features that focus on computation, and “interaction” languages for those languages and features that focus on interacting with the environment.

What are Types for?

The concept of types, broadly speaking, is essentially computational. It was introduced by Bertrand Russell to avoid certain paradoxes in the foundations of mathematics. In programming languages, types are syntactic guarantees that certain errors will not happen. For example

  • F is code defining a function that takes an integer as an argument and produces an integer as a result.
  • M is code computing an integer.
  • Therefore F(M) is code in which the function F is guaranteed to run correctly, as it receives an integer according to expectations, and which produces an integer as a result.

So just like in Principia Mathematica, types can be used to prevent certain kinds of errors. This is very reasonable, although there are some strings attached. Because type systems are defined compositionally on the syntax they will rule out some programs that would not cause run-time problems. They are sound (no faulty programs accepted) but not complete (some non-faulty programs are rejected). For example, here is a failing OCaml program:

# if true then 0 else 'a';;
Error: This expression has type char but an expression was expected of type int

The first error is caused because in the process of calculating the type of the program the two branches of the if statement must have compatible types, even though the ‘else’ branch is irrelevant dead code. Here is how Python handles this problem:

>>> 0 if 1 else 'a'

The type is not checked and the program runs alright. Everyone happy?

People who think they understand something about the theory of programming languages, including me, tend to agree that what Python does is wrong. Of course, millions of happy Python users disagree and get things done with it on a daily basis. Such is life — if only they listened to the experts.

Is Curry-Howard an isomorphism?

But is this all that there is to be said about types, that they inject a bit of sanity and discipline in programming languages? No, there is more to the story. Enter Curry-Howard. These two logicians noticed a quite fascinating analogy between type systems of programming languages and logics. You can formulate the types of a programming language using logical connectives: A→B can be read either as “A implies B” or “function of argument A and result B”. And then, the calculations required to determine the type of a program, where the type is written as some formula P, are closely related to the calculations required to prove that the logical formula P is true. This is truly an amazing, fascinating analogy and it holds remarkably well for a broad range of logics. Via the correspondence we can derive some truly elegant programming languages, for example Agda, truly a Shangri-La — or maybe a land of the Lotophagi, depending on one’s taste — of types.

But is it really all that surprising that a rich formal system, such as a logic’s proof system, can compute? Any complex enough formal system can compute, see e.g. rewrite systems. Without taking anything away from the elegance of the approach, the fact that it works should not be all that shocking. But the Curry-Howard method teaches us how to awaken the computation that is lurking within any logical system. Only a fool wouldn’t see the beauty and the usefulness of this.

But what about the opposite direction, can we always associate a type system with a “computer program”? That is a harder question because all sorts of things can be used to compute, some of them quite extravagant. Neural networks are an old example, as old as conventional computers. If neural networks compute, what is a “program”? Can we associate a type system with it? Not that I know of. The very question seems strange. How about chemical or DNA-based computing? Types are intrinsically associated with composition, and if a computing device is not made out of components, hoping for a meaningful type system to emerge seems to me unjustified.

To many programmers the notion of program seems to be more basic than that of type, and the two are not intrinsically connected. If a program is a proof, then what does type inference do? We already have the proof, but we don’t know if it is a proof of something? This is a curious thing, isn’t it?


To start questioning the utility, or the possibility, of a type system we don’t need to go as far as computers made of slime. Whenever we need to employ programming languages which are computation-oriented (“functional”) to interact with the real world there is a general feeling of unease. What is the right way to do it? At one end of the spectrum we have ML-languages which simply ignore, at the level of the type system, the interaction aspects. A program of type int->int will take an int, produce an int, and may or may not interact with the world. This is reasonable but to many it seems like an opportunity lost. Why not use the type system to say something about interaction as well?

Haskell does that, by using a type-theoretic device called a monad. Each monad indicates one particular kind of interaction, such as using memory or perform input-output. I am not a fan of monads, I confess. Monads, introduced by Eugenio Moggi, can be used as a language mechanism, the way Haskell uses them, or as a meta-language construct to formulate semantic models of languages that combine computation and interaction, a la ML. The latter is unquestionably useful, a matter of mathematical necessity. The former, I am not sure. Some monads (I/O) package real interaction, some have nothing to do with interaction (the “maybe” monad) and others are mock interactions (the “state” monad). The first one is reasonable, the second one is also reasonable but for completely different reasons (which I suppose is already becoming reasonable), and the third one is unreasonable on the face of it. It is not the same thing to program with state or as if there was state available, for the same reasons that driving a car simulator and a real car is not quite the same thing.

In the research lit there are many other effect systems. They are clever pieces of mathematical thinking, and very elegant within the fairly restricted bounds of what they can do. But to me, at the heart of it, they seem like languages of mock interaction rather than real interaction. They are reasonable to use as meta-languages, to describe certain interactions, but not as programming languages where the interaction should be real.

Compositionality, but at a cost

Compositionality, another word for plug-and-play, is a very pleasant property of systems. It guarantees that if the parts have some good property, the whole will have a good property. It is nice, but it comes at a cost. For example, it is a fact that global optimisations are always more efficient than composing local optimisations and global analyses are more precise than composing local analyses.

If we want to compose, we need to push all the properties at the interface and ignore the innards. This requires abstraction. This is a cost. For example, a language like OCaml won’t let you write a heterogeneously branched if statement because a type cannot be assigned to it.

if x then 0 else 'a'

For the same reason it won’t let you create a heterogeneous list

# [0; 'a'; fun x -> x + 1];;
Error: This expression has type char but an expression was expected of type int

However, unlike heterogeneous if statements, which are silly, heterogeneous lists could be useful. Here is a fairly exhaustive list of how various languages handle heterogeneous lists. In fact you can program heterogeneous lists in dependently typed languages, but it’s unreasonably complicated. Python makes no complaints:

>>> g = lambda x: x**2
>>> [1, 'a', "hello", g] [1, 'a', 'hello', <function <lambda> at 0x103e4aed8>]

To me this is one methodological weakness of type theory, the commitment of having types for all terms in the language. Why is that? Types are designed to facilitate composition, but the natural unit for program composition is not the term but the function, or even the module.  It makes sense to assign types to modules — it is methodologically consistent. But how we calculate these types could conceivably be more flexible, allowing a global perspective within the unit of composition. Types, as properties at the interface could be calculated using the entire arsenal of (decidable!) logics and static analyses. I understand it would make things like language spec and error reporting more difficult, but it should make the programming easier, if the success of languages such as Python is teaching us anything.

Compositionality v. interaction

To me it seems that the abstraction penalty induced by compositionality plays an important role in the questionable suitability of type theories for capturing interaction. Interaction with real-life systems means interacting with messy systems. In order to interact with them we need an interface language that is suitable both for the programming language and for the real-life physical system. This is not impossible, but only if we don’t require the interaction language to model the physical system itself.

Hardware design is an interesting example, as it works on two levels of abstraction. At the high level we have hardware description languages (HDL) which deal with the logical description of the circuit — the language of the Booleans, sometimes enhanced with extra values such as “undefined”. In this language the order of events can be described, but not precise timings. In this language combinatorial feedback loops, are almost always banned because the precise behaviour depends on extra-logical factors, such as precise timings. Yet without combinatorial feedback loops flip-flops and other memory elements cannot be defined.

SR flip-flop

SR flip-flop

The result is to provide memory elements as black box library components, defined and tested in a different, lower-level, language. But at the interface the two levels of abstraction are reconciled and composition can occur.

In a follow-on post I will explain how a similar approach to types can be taken in the case of programming languages.

Posted in programming languages | Leave a comment

Inventing an algebraic knot theory for eight year olds (IV)


Here is a quote that captures the ethos against which our maths club militates:

We take other men’s knowledge and opinions upon trust; which is an idle and superficial learning. We must make them our own. We are just like a man who, needing fire, went to a neighbor’s house to fetch it, and finding a very good one there, sat down to warm himself without remembering to carry any back home. What good does it do us to have our belly full of meat if it is not digested, if it is not transformed into us, if it does not nourish and support us?          – Montagne, “Of Pedantry”.

This is how mathematics is usually delivered to students: knowledge upon trust. And it is knowledge of a particularly mystical variety, where magical symbols come together in incomprehensible ways. This is the myth we need to dispel, this is the knowledge we need our kids to digest. Sometimes Algebra can be nothing more than a way to write down knots and their properties.

Last session, using the notation we developed together, went well. One unexpected hick-up was the fact that my students had not seen parentheses before, but we took that in our stride. They also hadn’t use variables before, so most of the examples were concrete. But the little use of variables we made was not confusing.

I even introduced some proper maths terminology, the Big Maths Words. First I asked them to give names to the composition operation, and they came up with some reasonable suggestions such as gluing, linking or joining. When I told them the Big Math Word was composition they liked it — it was “like music”, where you “compose” a song from notes. Indeed! They also had reasonable suggestions for the tensor, things such as stacking or building, but they didn’t much like the Big Math Word tensor. I don’t like it very much myself, I confess.

For the first 20 minutes we went over the new and tidied up notation. The rest of  the time, 30 minutes or so, we worked out examples of going from a drawn knot to the formula. It is not easy, in fact it is quite a challenge (try the exercises) so they often got things wrong. One pervasive error was getting confused by repeated tensoring (“stacking”) of tangles, K⨂K’⨂K” which often was written as K⨂K’K” — an interesting error.

Tomorrow’s session we will finally reach equations. We have already seen the equation I*=I, which was noticed while developing the notation. First we will start with similar coherence equations, which basically mean that two notations denote the same knot. Things like associativity of composition or tensor are typical coherence equations. But because children have no appreciation of parantheses and operator precedence associativity is perhaps not the best example. Functoriality of the tensor is much more interesting.

  1. Draw the tangle for (C◦C*)⨂(C◦C*).
  2. Draw the tangle for (C⨂C)◦(C*⨂C*).
In both cases the result is a couple of loops. The difference is in how we put the loops together and not in what the result is:
Functoriality means that no matter what tangles H1, H2, H3, H4 (for some reason the kids chose H as the standard variable for knots) the following two tangles, if they can be constructed, are always equal:

The unit and the co-unit also suggest compact-closed-like coherence axioms, which have a more topological flavour. Try this knot: (I⨂C)◦(C*⨂I). It looks like this:

But this is only a wire with some irrelevant bends. We have the equation

(I⨂C)◦(C*⨂I) = I

There is another similar equation, where the shape is like an ‘S’ rather than like a ‘Z’. Can you guess it?

The trove of equations is deep for this algebraic theory of knots and tangles and there is plenty of scope for children to discover equations once they understand what they represent. In addition to compact-closed we can also find equations from traced, braided and closed-monoidal categories.

But most importantly, I think the point is not to just give such equations to the students in order for them to develop skill in calculating knot equivalences using equational reasoning, so I won’t do that. That’s the kind of mystical maths I want to avoid. What is important are these two points:

  1. Understanding the idea of equational reasoning, that the same structure can be expressed in several equivalent ways, and that equations are the mathematical way to show this.
  2. Exploring the space of equations. Ideally, after a while the issues of soundness and completeness should emerge naturally.

Now, a brief comment to the cognoscenti. The categorical structure of this algebra of tangles is not an obvious one. We are using both the unit and the co-unit of compact closed categories, but our category is braided rather than symmetric. However, compact closed categories are symmetric so we are not in an obvious setting. The interaction of braiding and “compact closure” (informally speaking) gives equations like this:

C◦X◦C* = C◦C*

which correspond to this topological isomorphism of tangles:

These are two ways to describing the unknot. The category is clearly non-degenerate because we seem to be able to describe any knot. So combinatorial completeness seems an achievable result. Equational completeness (i.e. any equivalent knots can be proved to be so)  however seems like a challenging and interesting question!

In terms of related work, this seems similar enough: Peter Freyd and David Yetter, Braided compact monoidal categories with applications to low dimensional topology, Adv. Math. 77, 156-182, 1989.

If you are interested in another diagrammatic explanation of algebra also have a look at Pawel Sobocinksi’s entertaining and informative blog.

Posted in teaching | 1 Comment

Inventing an algebraic knot theory for eight year olds (III)

Unlike previous posts, this one precedes the math club meeting. The reason is that we need to tighten some loose ends in our emerging knot theory notation. The first two meetings (I and II) were all about exploring knots and ways to describe them using notations, and we made some impressive strides. But at this stage I need to exercise some authority and steer them firmly in the right direction:

  • We are going to use I rather than 0 (zero) to denote the identity of composition. Even though 0 is a neutral element for addition, as correctly spotted by the children, using it as the neutral element for composition is not idiomatic. 1 (one) is more standard, for various reason I will not get into here.
  • Using a fraction-like notation for “parallel” (tensorial) composition is also quite unidiomatic, although it is intuitive. We shall introduce the standard ⨂ notation instead.
  • We will stick with a generic duality operation _* so that our “unit” and “counit” are C and C* rather than C and D as some of the children insisted on.

These are of course small matters which we could put up with, at the expense of becoming incomprehensible to the rest of the world. The more important thing is that the interplay between “sequential” (“functional”) composition and “parallel” (“tensorial”) composition is not very easy to get right. Look at our overhand knot:

The individual components are well identified but a nice way to put them together is unclear. There is a sequential composition at the top (X◦X◦X) but how to connect that with the C, L and C* underneath is not clear from the decomposition. X “interacts” with C and C with L but not obviously sequentially or in parallel.

The way out is to introduce types. What are types? To paraphrase John Reynolds’s succinct explanation, they are a syntactic discipline that guarantees correct composition. And this is what we need here.

We shall always give knots a type (m, n) ∈ N². The left projection represents how many “loose ends” stick out to the left and the right projection how many to the right. So this is a (4, 6)-knot:

Note the implicit restriction: we allow no loose ends to stick out from the top or from the bottom. Is this a reasonable restriction? Yes, because if a bit of string goes down or up we can always “bend” it left or right then “extend” it until it lines up nicely with the other loose ends. This topological invariance of knots should be intuitively obvious to my young students, I hope.

So the types of our basic knot parts are:

Now we can say that we only allow the composition K◦K’ for knots K:(m,n) and K:(m’, n’) if n=m’, resulting in a knot K◦K’:(m, n’). Here are two composable knots:

And this is their composition, with “composition links” emphasised:

Note that because these are “strings” the loose ends don’t need to be “geometrically” aligned. It is enough to have the right number of loose ends to be able to glue them. And this is their actual composition:

Any two knots K:(m, n) and K’:(m’, n’) can be composed in parallel in a knot K⨂K’:(m+m’, n+n’). The composition of the two knots above is:

So now everything is in place to properly describe algebraically our overhand knot:

Above we introduced -•- as a shortcut for repeated sequential composition, useful for concision. Note that we needed the identity string I not just on the bottom, but also to the left and to the right, in order to make the loose ends match properly in sequential composition. This kind of “padding” with identities will be a useful trick that will allow us to define a lot of knots compositionally!


  1. (easy) Is this the only way to describe an overhand knot? Give an alternative description.
  2. (easy) Is this the only kind of overhand knot? If no, write the definition of a different overhand knot.
  3. (medium) Write the definition of a Granny Knot and its variations: the reef, the thief and the grief knots.
  4. (medium) Write a definition for the Shoelace Knot.
  5. (hard) Is there a knot that cannot be described with our notation?
Posted in teaching | 1 Comment

Chalmers’s Digital Radio

In previous posts I gave arguments against the apparently widely held belief, at least amongst readers of this blog, that all mental states and phenomena, consciousness in particular, are reducible to computational processes in the brain: computationalism. Whether this is or isn’t the case divides the philosophical community, with famous names agreeing (Searle, Penrose) or disagreeing (Dennett, Chalmers).

This post is not another argument against computationalism but an attempt to be more scholarly. I will take a brief critical look at one of the more influential papers in the area, Chalmers’s “A Computational Foundation for the Study of Cognition“ (Journal of Cognitive Science 12:323-57, 2011). There are some things I admire about this paper. For once, it sets out quite meticulously to define what a computation is, making the important distinction between abstract computation and implemented computation. Even though as a computer scientist I find many points of disagreement in the detail of how this theory is constructed, the fact that Chalmers considers it in the first place is admirable. Many computationalist philosophers fail to make this distinction, which renders some of their arguments sloppy and implausible. But at least Chalmers answers definitively some rather silly (at least to a computer scientist) questions raised by Searle and Putnam about the relationship between computation in the abstract and the concrete. The opening sections of the paper found me nodding in agreement most of the time.

The main thrust of Chalmers’s computationalist explanation is in Section 3 which spells out his theory of “organizational invariance of mental properties”. Unlike the previous section, where technical words are used in their technical sense, here technical-sounding words are used in a rather vague and informal way. Sentences like this set off all sorts of alarm bells, as the amount of sense they make is questionable: “Causal topology can be thought of as a dynamic topology analogous to the static topology of a graph or a network.” I shall not quibble with language though but try to assign sensible and charitable meaning to the argument in order to make a sensible counterpoint.

The argument is conveniently summarised by Chalmers, so I can quote it in its entirety:

The argument for this, very briefly, is a reductio. Assume conscious experience is not organizationally invariant. Then there exist systems with the same causal topology but different conscious experiences. Let us say this is because the systems are made of different materials, such as neurons and silicon; a similar argument can be given for other sorts of differences. As the two systems have the same causal topology, we can (in principle) transform the first system into the second by making only gradual changes, such as by replacing neurons one at a time with I/O equivalent silicon chips, where the overall pattern of interaction remains the same throughout. Along the spectrum of intermediate systems, there must be two systems between which we replace less than ten percent of the system, but whose conscious experiences differ. Consider these two systems, N and S, which are identical except in that some circuit in one is neural and in the other is silicon.

The key step in the thought-experiment is to take the relevant neural circuit in N, and to install alongside it a causally isomorphic silicon back-up circuit, with a switch between the two circuits. What happens when we flip the switch? By hypothesis, the system’s conscious experiences will change: say, for purposes of illustration, from a bright red experience to a bright blue experience (or to a faded red experience, or whatever). This follows from the fact that the system after the change is a version of S, whereas before the change it is just N.

Before pointing out the logical fallacy of this argument (can you spot it?) lets travel in time, to a strange and dystopian future where in the wake of an untold cataclysm humanity will have lost some of its scientific knowledge. Among the forever lost items is all knowledge of radio communication. So when the archeologists of the future discovered a radio set in working condition it caused somewhat of a sensation. They surrendered the radio for examination to their contemporary scientists and philosophers. Moreover, unbeknownst to all, one fully automated nuclear-powered radio station, hidden among the ruins of the past, was still eternally broadcasting.

The scientists of the future figured out quickly that the radio was an electronic device, plugged it in and delicately experimented with the various knobs and buttons. The on/off button and the volume knob where easy to figure out. Their initial theory was that they discovered a white-noise machine. The philosophers of the day explained at length and convincingly why ancient folk might have wanted to build such a machine. But their speculations where quickly abandoned when the scientists figured out that the most mysterious knob, which we call the dial, had a function after all: If you point it to a particular number on the scale the device starts producing music instead of noise. Being able to listen to what was probably the sacred music of the ancient culture caused widespread fascination. Historians established with some confidence that Madonna was none other than the mythical figure revered as the mother of God in the ancient religion of Christianity.

This was a most interesting discovery not only culturally but also technologically. In the dystopian future digital devices such as computers and digital music players were still manufactured. So there was a solid understanding of music-producing electronic devices. The scientists figured out rather quickly that the radio was not digital, but analog. However, its input-output behaviour was precisely that of a digital music player, so they assumed it was some kind of analog equivalent of a digital music player. They even figured out what the dial was: a broken shuffle knob.

But they were not quite sure, and that was really annoying them. They knew that the ancient civilisation had mastered some lost technologies so they kept wondering. Was that really a music player, just analog? One of their prominent philosophers argued persuasively that ‘yes’:

All the components of the radio are electronic, but analog. So you could isolate each electronic component, interface it to the rest of the device via a kind of modem, then reimplement its functionality digitally. When two digital components are connected we can just remove the superfluous modems. So, in a step-by-step way, we can replace the entire analog device with a digital device so that we end up with a digital music player.

Persuaded, most scientists gave up further investigations into the nature of the radio. Except one well funded and talented scientist who questioned the argument and set out to actually put it in practice. Painstakingly, she figured out and replaced the analogue components of the radio with digital components — until she reached the antenna of the radio. She was shocked by the behaviour of this component. It was a very basic-looking arrangement of conductive elements which produced output out of apparently nothing.  The only plausible hypothesis was that this was the memory element of the device, which stored all the music coming out of it. But it was much too simple in structure to be a memory. Our scientist was baffled. She wrote a few research papers about the stupendous analog memory technology of the ancients, but they got a mixed reception. The tabloid magazines made quite a stir around this mysterious technology but the established research publications refused to publish such speculation.

We are not sure what happened next. Did our scientist give up? Did she eventually discover electromagnetic waves and unlocked the true mystery of the radio? Most likely her lack of publications resulted in her losing her research funding.

Lets return to Chalmers now. His recipe for building a silicone computer out of a brain is similar to the above recipe for building a digital music player out of a radio set. The fallacy of the argument is called begging the question: when you assume that all brain components can be replaced with little silicone computers you already assume that all relevant functionality of that brain component is of a computational nature. But this is what the argument set out to prove in the first place, that the activity of the brain is of a computational nature.

If not computation, then what else is there in the brain that could realize mental states, in particular consciousness? Perhaps not radio-waves either. My money is on the theory that we don’t have the faintest clue. Just like our talented scientist from the future could not imagine radio waves, so we cannot understand what is going on, really, in the brain. Just like her, we understand a lot about various phenomena in the brain — except for the essence of how and why it works at a fundamental level. Our attempts to explain it using whatever concepts we have at hand will be, I have little doubt, as laughable as the miasmatic theory of disease or the phlogistonic theory of combustions. I admit, my theory is not a fascinating one.

Other than that, the paper is nice and readable. With this (fallacious) argument in place and its (mistaken) conclusion reached everything else fits neatly together. Just don’t use it as a recipe if you are trying to build a digital radio.

Posted in anticomputationalism, armchair philosophy | Leave a comment

Inventing a knot theory for eight year olds (II)

So I am running a math club for 8 year olds and we are reinventing (an) algebraic knot theory. We are not trying to reinvent existing knot theory, just to make a journey of intellectual and mathematical discovery. In the first meeting I gently shocked the children by showing them that mathematics is not only about numbers, but about patterns in general — such as knots. Being only 8 they are very theatrical in expressing emotion. WHAT!? Maths about KNOTS!? I loved the wild face expressions and hand gestures. We spent most time making and drawing knots and concluded that drawing knots is quite hard. We needed a better notation.

A notation for knots: the knotation

One preliminary observation that I made which resonated well was that there are a lot of numbers out there but we only need 10 symbols to represent all of them: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. Of course we could only use 0 and 1, or just 1, but let us not get distracted. It is about having a nice and convenient notation not just any notation. So I drew a couple of knots on the whiteboard and I encouraged the children to try to identify the “smallest pieces the knot is made of”, where by a “piece” I meant this: we draw a small circle on the whiteboard and the “piece” is the bit of knot we see inside the circle. If our circles are small enough it is easy to see that the pieces inside the circles are quite similar. So here is an overhand knot with some parts of it circled.

  •  We notice that even if we ‘zoom in’ on a knot piece, as in the case of the red circles, the interesting knot piece ‘looks the same’:

  • We notice that if a knot piece is too large, as in the case of the blue circle, it can be clearly decomposed into smaller basic knot pieces.
  • We also notice that many knot pieces which we select here and there look quite similar, as in the case of the green circles.

I don’t think there is a clear methodology one can use in inventing a good notation for a concept or set of concepts. It is a fun and creative endeavour. It is a design exercise in which many criteria must be balanced. On the one hand we have expressiveness, which means that we can use the notation to represent a large range of concepts. But we also have elegance, which is more subjective but not entirely arbitrary. We want a small (but not too small) set of notations. We want it to be also concise. We want it to be pretty.

So we explored a while and in the end, with some careful guidance, we narrowed in on these constants:

The names C and X were suggested because of the shape of the knot piece they represent. L was short for “line”. These shapes can be flipped over and result in 3 other constants:

Here there was some disagreement between me and the kids. They were happy with the flipping operation and they were happy with X* but they didn’t like C* because it looked more like a D (without the vertical bar). Some of them insisted that we call them D and X*. L* was clearly a non-issue because it was just like L. I had to put my foot down and we settled on C, X, L and the -* operator.

This exercise also presented us with our first equation: L = L*. We didn’t insist on equations because they will become more important in a few weeks.

The final part of the hour was dedicated to developing notations for assembling knots out of these constants. There are two obvious ways to compose knot pieces, horizontally and vertically. Here is how the overhand knot can be split into basic components:

How do we put them together? The bits at the top can be quite clearly written as X⋅X⋅X. The bit below seemed like C⋅C*. And at the bottom we have L. Because the bit at the bottom is quite long many kids wrote it as L⋅L or L⋅L⋅L but they quickly realised our second equation: L = L⋅L. This observation led to an unfortunate turn of events in which the kids decided that is like 0 because added with itself stays the same, and therefore changed it from L to 0. Next week we will need to change it to the correct one (1) even if I need to exercise my executive power.

This is where we ran out of time. So we didn’t have any good notation for vertical assembly. Because we didn’t have vertical assembly we couldn’t really test our notation — to the trained eye it’s quite obvious it is not quite good yet. The way C, C* and L are composed is not entirely clear because vertical and horizontal composition interact. But it is a start. I want the children to move away from how they are used to study mathematics, as a stipulated set of rules in which answers are either correct or incorrect. I don’t want them to execute the algorithm, but to invent the programming language in which it is written. Coming up with stuff that doesn’t work is OK, as long as we notice it doesn’t work and we improve on it.

But what did we accomplish? Quite a lot. In one hour a dozen 8 year olds rediscovered some of the basic combinators used in monoidal categories, such as the braid, or such as duality, unit and co-unit as used in compact closed categories. We also rediscovered composition and its identity, and some of its equations. We used none of the established names and notations, but we discovered the concepts. We are on our way to inventing a fairly original categorical model of knots and braids. Next week we will quickly figure out the monoidal tensor and move on to the really exciting bit: coherence equations.

Posted in teaching | 1 Comment

Inventing a knot theory for eight year olds (I)

Last year I experimented with teaching seven and eight year olds about monoidal categories using a very concrete model of cardboard rectangles and bits of string. The experiment was a success, with children becoming able to represent formally a model or to construct a model from a formal specification. They also developed an understanding of some key concepts, such as coherence. The physical manipulation of cardboard and strings was fun and relating it to notation and equations was surprising to the children and, I think, interesting.

This year I am reprising the experiment, with some changes. The first thing I wasn’t too happy with last year was the overhead of constructing models of cardboard and string. Too many things can go wrong, from poking holes too close to the margins so that they tear to making the wires too long or too short. Not to mention that some children did not know how to tie a knot! The motivation of building structures of cardboard and strings was also unclear, I didn’t even have a name for these structures. So this year we are only looking at knots. They are a simpler to build physical structure since all you need is the strings — no more cardboard and hole punchers. They are also something children already know. And if they don’t know how to tie them it’s OK, because that’s what we are learning. The second change I am making is slowing down the pace and making the process more exploratory. I will not try to teach them anything in particular but we will aim to develop together a term algebra for knots.

The first meeting of our club started with a general discussion about what is mathematics. Third-graders are taught a very narrow view of the subject, which they tend to identify with arithmetic. “Tricky problems” was another common view of what mathematics is about. When I asked whether a triangle is something that mathematics deals with the kids started to question their own understanding of what it is really about.

I proposed that mathematics is the general study of patterns and this was immediately accepted. Then we talked a while about the need in mathematics to represent concepts and I introduced the concept of “notation”, illustrated with a potted history of numerals, notations for the numbers. We spent some time on hieroglyphic numerals, a topic which turned out to be very enjoyable in its own right. I wanted children to discover the inconveniences of this system compared with our Indo-Arabic system and they indeed came to that conclusion quite soon.

The next step was to introduce knots. The fact that mathematics would have something to say about knots struck many children as implausible but even the most skeptical changed their tune immediately when reminded that “knots are some kind of patterns we make with strings” and “maths is about patterns”. This abrupt change of mind and wholehearted acceptance of a previously rejected thesis makes working with children a great pleasure.

We started by making knots. The first bit of technical terminology we established was calling anything we make with strings “a knot”, including braids or bows or even a plain bit of string. This was deemed acceptable. Making knots and experimenting with various ways of tying them was of course a lot of fun.

This is also a knot!

The second step was representing knots by drawing them. The challenge was to draw a half-knot:

The children under-estimated the difficulty of the task, producing something like this:

This drawing of course makes line crossing ambiguous. Which line is above and which line is below?  I suggested leaving small gaps to indicate line crossings:

The principle was readily understood but the execution was problematic. Drawing the knot correctly proved a real challenge, with more than half the children failing to draw it correctly.

The upshot of all this struggle was a consensus that we really need a better way to write down knots, a “notation” (knotation?). The groundwork has been laid for creating a term algebra for knots next week.


Posted in teaching | 2 Comments