~?~

~?~

~?~

A Neighborhood of Infinity google_ad_section_start(name=default) Saturday, May 17, 2014 Types, and two approaches to problem solving Introduction There are two broad approaches to problem solving that I see frequently in mathematics and computing. One is attacking a problem via subproblems, and another is attacking a problem via quotient problems. The former is well known though I’ll give some examples to make things clear. The latter can be harder to recognise but there is one example that just about everyone has known since infancy. Subproblems Consider sorting algorithms. A large class of sorting algorithms, including quicksort , break a sequence of values into two pieces. The two pieces are smaller so they are easier to sort. We sort those pieces and then combine them, using some kind of merge operation, to give an ordered version of the origina...

google_ad_section_start(name=default) Friday, May 23, 2014 Cofree meets Free > {-# LANGUAGE RankNTypes, MultiParamTypeClasses, TypeOperators #-} Introduction After I spoke at BayHac 2014 about free monads I was asked about cofree comonads. So this is intended as a sequel to that talk. Not only am I going to try to explain what cofree comonads are. I'm also going to point out a very close relationship between cofree comonads and free monads. At the beginning of the talk the Google Hangout software seems to have switched to the laptop camera so you can't see the slides in the video . However the slides are here . Cothings as machines I often think of coalgebraic things as machines. They have some internal state and you can press buttons to change that internal state. For example here is a type class for a machine with two buttons that's related to a magma...

A Neighborhood of Infinity google_ad_section_start(name=default) Friday, January 26, 2007 The Monads Hidden Behind Every Zipper Uustalu points out that behind every zipper lies a comonad. I used this in my cellular automaton example . What he doesn't mention is that there is also a monad lurking behind every zipper and that it arises in a natural way. The catch is that it's a monad in the wrong category making it tricky to express in Haskell. Firstly, what does "wrong category" mean? In the category of vector spaces, every object is equipped with a commutative binary + operator. We can make no such assumption in Haskell. What's more, Haskell doesn't easily allow us to restrict type constructors to instances of Num say. So we can't easily implement monads in the category of vector spaces as instances of Haskell's Monad bind return Num convolution > data Zip...

~?~

A Neighborhood of Infinity Showing posts sorted by relevance for query zipper . Sort by date Show all posts Showing posts sorted by relevance for query zipper . Sort by date Show all posts google_ad_section_start(name=default) Friday, January 26, 2007 The Monads Hidden Behind Every Zipper Uustalu points out that behind every zipper lies a comonad. I used this in my cellular automaton example . What he doesn't mention is that there is also a monad lurking behind every zipper and that it arises in a natural way. The catch is that it's a monad in the wrong category making it tricky to express in Haskell. Firstly, what does "wrong category" mean? In the category of vector spaces, every object is equipped with a commutative binary + operator. We can make no such assumption in Haskell. What's more, Haskell doesn't easily allow us to restrict type con...

A Neighborhood of Infinity google_ad_section_start(name=default) Saturday, March 17, 2012 Overloading Python list comprehension Introduction Python is very flexible in the way it allows you to overload various features of its syntax. For example most of the binary operators can be overloaded. But one part of the syntax that can't be overloaded is list comprehension ie. expressions like [f(x) for x in y] . What might it mean to overload this notation? Let's consider something simpler first, overloading the binary operator + . The expression a+b is interpreted as a.__add__(b) if a is of class type. So overloading + means nothing more than writing a function. So if we can rewrite list comprehensions in terms of a function (or functions) then we can overload the notation by providing alternative definitions for those functions. Python doesn't provide a facili...

A Neighborhood of Infinity google_ad_section_start(name=default) Friday, January 26, 2007 The Monads Hidden Behind Every Zipper Uustalu points out that behind every zipper lies a comonad. I used this in my cellular automaton example . What he doesn't mention is that there is also a monad lurking behind every zipper and that it arises in a natural way. The catch is that it's a monad in the wrong category making it tricky to express in Haskell. Firstly, what does "wrong category" mean? In the category of vector spaces, every object is equipped with a commutative binary + operator. We can make no such assumption in Haskell. What's more, Haskell doesn't easily allow us to restrict type constructors to instances of Num say. So we can't easily implement monads in the category of vector spaces as instances of Haskell's Monad bind return Num convolution > data Zip...