Matt Manela's Blog : Haskell

Prime Factorization using Unfold in Haskell

MattManela — Tue, 17 Mar 2009 16:53:00 GMT

I randomly yesterday started thinking about the unfoldr function in Haskell while working out at the gym (how nerdy is that, I am lifting iron but thinking of functional programming). Unfoldr take a single and an unfolding function and turns it into a list (the opposite of fold). At the gym I was thinking about an application where I can use this and I decided that when I got home I would use it to write a prime factorization function. This is a method that when given a number returns the list of its prime factors.

It was easy to write the only part I am not pleased about is the code I used to deal with tuples. It seems clumsy and I am still looking for a way to clean that up.

One note: The code below references a list of prime numbers called primes , which is not shown.

Here is the code:

   1: primeFactors x = unfoldr findFactor x   2:                  where   3:                    first (a,b,c) = a   4:                    findFactor 1 = Nothing   5:                    findFactor b = (\(_,d,p)-> Just (p, d))   6:                                   $ head $ filter ((==0).first)    7:                                   $  map (\p -> (b `mod` p, b `div` p, p))  primes

This function will take any number which is greater than 1 and return a list of its prime factors. But don’t take my word for it, I wrote a quickcheck property to ensure the prime factors multiply back to the original number:

   1: prop_factors num =  num > 1 ==> num == (foldr1 (*) $ primeFactors num)

When running quickcheck on this property you see the following:

quickCheck prop_factors
OK, passed 100 tests.

Parameterized State Transformer Monad in F#?

MattManela — Wed, 05 Nov 2008 08:30:29 GMT

I have have been playing around with F# and I decided to create a state monad. This worked out really well since I was able to leverage the F# computation expressions. I then decided to try to extend this and make it more general by creating a parameterized state transformer monad. This is a state monad which encapsulates another monad. What this allow you to do is turn any computation into a statefull one.

This concept exists in Haskell which you can see here. However, my attempts at replicating this in F# failed. Unlike in Haskell, the computation expressions in F# don't share a common interface (or type class). This prevents a computation from being able to generically take another computation as a parameter. The reason is that an operation on the parameterized state transformer monad such as bind will result in a bind called on its encapsulated monad. But since there is no interface for computations there is no bind method to call.

I attempted to fix this by creating my own monad interface but this didn't work:

   1: type Monad =   2:     abstract Bind : 'm * ('a -> 'm) -> 'm   3:     abstract Delay : (unit ->'m) -> 'm   4:     abstract Let : 'a * ('a -> 'm) -> 'm   5:     abstract Return : 'a -> 'm   6:     abstract Zero : unit -> 'm   7:     abstract Combine : 'm -> 'm2 -> 'm3   8:     abstract Run : (unit ->'m) -> 'm

After playing with that and failing I ended up with a less than ideal solution. Given a Maybe monad like below:

   1: // Maybe Monad       2: type MaybeBuilder() =   3:     member b.Return(x) = Some x   4:     member b.Run(f) = f()   5:     member b.Delay(f) = f   6:     member b.Let(p,rest) = rest p   7:     member b.Zero () = None   8:     member b.Combine(m1,dm2) = match m1 with   9:                                  | None -> dm2()  10:                                  | x -> x  11:    12:     member b.Bind(p,rest) = match p with   13:                             | None -> None  14:                             | Some r -> rest r

I created a state transformer monad which take an argument of type m:MaybeBuilder

   1: type StateMBuilder(m:MaybeBuilder) =    2:     member b.Return(x) = fun s -> m.Return (x,s)   3:     member b.Run(f) = fun inp -> (f inp)()   4:     member b.Delay(f) = fun inp -> fun () -> f() inp   5:     member b.Let(p,rest) = rest p   6:     member b.Zero () = fun s -> m.Zero()   7:     member b.Bind(p,rest) = fun s -> m.Bind(p s,fun (v,s2) -> rest v s2)   8:     member b.Combine(p1,dp2) = fun s -> m.Combine(p1 s, dp2 s)   9:    10:     // State specific functions  11:     member b.Update f = fun s -> try m.Return (s, f s) with e -> m.Zero()  12:     member b.Read () = b.Update id  13:     member b.Set t = b.Update (fun _ -> t)

Now although this type is technically parameterized ;) it isn't really the idea since its not generic, it has to be a MaybeBuilder. To use this with a different monad I would need to change m:MaybeBuild to m:SomeOtherMonad.

I am still going to play with this but this is as far as I have gotten.

After all of that here is how you create a state transformer monad parameterized over the maybe monad:

   1: let maybe = MaybeBuilder()   2: let state = StateMBuilder(maybe)

If anyone has an idea how I can make this work I would love to hear it.

Writing a Regular Expression parser in Haskell: Part 4

MattManela — Sun, 22 Jun 2008 02:18:00 GMT

With the previous two modules in place we are now set up to use a DFA to match against a string. In my implementation I support either a greedy match or an short match. In a full featured regular expression engine this ability to choose greedy or not would be per operator but for simplicity I have it for the overall match.

To do the matching I have a general function which will create a list of all matches. Then the difference between short and greedy matching is which of the candidate solutions does it choose.

This is the method:

   1: doMatch func machine st [] = doAccept  machine st []   2: doMatch func machine st string =  func $ map (\f -> doMatch' st f []) (tails string)   3:     where   4:       doMatch' state [] soFar = doAccept machine st soFar   5:       doMatch' state (s:str) soFar =    6:           case findTransition machine s state of   7:             Nothing -> doAccept machine state soFar   8:             Just (from, to, val) -> case doMatch' to str (soFar ++ [s]) of   9:                                       (False,_) -> case canAccept machine to of  10:                                                     True -> (True, soFar ++ [s])  11:                                                     False -> doMatch' to str (soFar ++ [s])  12:                                       (True,res) -> (True,res)

This creates the list of matches and uses the passed in function to determine how to filter to either the shortest or longest match.

For short or long matches I pass in one of these two functions:

   1: -- Get the shortest match   2: shortest matches = case  filter (\s->fst s) (sort matches) of   3:                      [] -> (False,"")   4:                      ms -> head ms   5:     6: -- Get the longest match   7: longest matches = last.sort $ matches

I created aliases for the functions to make it more handy:

   1: (=~) = greedyMatch   2: (=~?) = shortMatch

And then the final result:

   1: *SimpleRegex> "hiphiphiphorray" =~? "hip(hip)*"   2: (True,"hip")   3:     4: *SimpleRegex> "hiphiphiphorray" =~ "hip(hip)*"   5: (True,"hiphiphip")

I attached a zip of all the files for this project.

Enjoy!

Writing a Regular Expression parser in Haskell: Part 3

MattManela — Tue, 10 Jun 2008 09:08:00 GMT

The third module in the simple regular expression parser is called: NFAtoDFA. Which as you might have guessed, takes the NFA that resulted from the first module and converts it into a DFA. The structure that the DFA uses is the same that the NFA uses since they are both finite state machines.

Converting an NFA to a DFA requires mapping sets of nodes in the NFA to a single node in the DFA. Many nodes in a NFA will correspond to one node in the DFA. Making this change requires updating transitions to point to and from sets of nodes. To manage this transformation I create a state monad using the following context:

   1: -- The state which we pass to build the DFA   2: data ConvertContext = ConvertContext { nfa :: FiniteMachine,   3:                                        trans :: [Transition],   4:                                        setMap :: Map.Map (Set Node) Integer,   5:                                        setStack :: [Set Node],   6:                                        begin :: Node,   7:                                        accept :: Set Node,   8:                                        nextNode :: Node   9:                                      } deriving (Show, Eq)  10: type ConvertState a = State ConvertContext a

Most of the code in this module is just managing this context and updating it according to two operation:

Epsilon Closure
Set Move

These are explained in more detail in this article.

Basically, epsilon closure is the process of taking a set of initial nodes and returning a new set of all nodes you can traverse to purely on epsilon transitions. To help with this I created some smaller methods to build up to an epsilon closure.

First are a couple methods (findToNodes and closure):

   1: closure trans value nodes oldSet = Set.union (findToNodes trans value nodes) oldSet   2:     3: -- Search the table of transitions to find all nodes you can reach given an initial set of nodes   4: findToNodes trans value fromNodes = foldr match Set.empty trans   5:     where    6:       match (from, to, val) nodes   7:           | (from == fromNodes) && (val == value) = Set.insert to nodes   8:           | otherwise = nodes

findToNodes searches a transition table for all nodes which go from any node in fromNodes on value. It will builds up a set with all the to nodes that match.

closure wraps findToNodes to let us easily union together an initial set and the nodes we can reach from that set.

With this in hand we can write clearly a epsilon closure function:

   1: -- Given an initial set of nodes, find the set of all nodes you can reach by taking    2: -- transitions on epsilon only   3: epsilonClosure trans nodes = foldUntilRepeat Set.union Set.empty $   4:                              iterate (Set.fold (closure trans epsilon) Set.empty) nodes   5:     6:  

This function takes full advantage of the lazy nature of Haskell. It repeats the closure on epsilon over and over and streams its results into our function foldUntilRepeat. This method does what it says, it will fold the values that are streamed in until it sees the same value twice.

The set move is just combination of what you have already seen:

   1: -- Given a starting set of nodes the set of all nodes that you can reach on a given value   2: -- This includes epislonClosure on the desitination nodes   3: moveClosure trans value nodes = epsilonClosure trans $    4:                                 Set.fold (closure trans value) Set.empty nodes   5:  

With these functions in hand, this module just becomes calling them and updating the context until we have no more nodes in the NFA to process.

In the next installment I will discuss using the output of this modules to match a regex against a string.

Also, once again the code is attached.

Writing a Regular Expression parser in Haskell: Part 1

MattManela — Sun, 01 Jun 2008 23:28:34 GMT

A few weeks ago I read this article about writing a simple regular expression parser. That article does a really good job of explaining the theory behind regular expression. It then goes step by step into how to write a program (he uses C++) to parse a regular expression, convert it into a NFA, convert that into a DFA and then use that DFA to match strings.

After reading that I decided to write my own simple regular expression parser using Haskell. I saw it as a challenge to try to see how you deal with a more complex program in a pure functional language. After a couple weeks ( Grand Theft Auto 4 kind of ruined my progress for a while ) I have some results.

I split the project into 3 modules.

RegexToNFA - Provides functionality to parse a simple regular expression and return a NFA.
1. This modules also define the FiniteMachine type which is a general structure for finite state automata.
NFAtoDFA - Providers functionality to convert a NFA into a DFA.
1. This module uses the same FiniteMachine type from RegexToNFA
SimpleRegex - Provides the functionality to give take a regular expression and a string and return what it matches (if it matches anything).
1. This modules uses RegexToNFA and sends its results to NFAtoDFA and then uses the resulting DFA to match against a string.

This is a very simple and limited regular expression parser. It supports only union(|), concatenation, closure(*) and parenthesis. In addition, I don't preserve information after the NFA is created about the location of the parenthesis. This means you can't pull out sub-matches when a entire expression matches.

In my next three I will talk about each module and point out interesting parts of them. There is nothing too complex but shows how to approach it in Haskell (making heavy use of the State monad).

If you want to see a much more complex and full featured regular expression parser written in Haskell take a look at this.

Click here to continue to Part 2.

Breadth First Tree Traversal in Haskell

MattManela — Mon, 12 May 2008 05:30:06 GMT

As my interest in functional languages has grown, I have become increasingly interested in using them to implement algorithms which I can already write with imperative languages.

For example, I was taught to implement (and I assume most other people as well) a breadth first traversal of a tree using a queue and a loop. An example using this method can be found at the wikipedia page for a breadth first search. When I wanted to try implement a breadth first search in Haskell I quickly realized that algorithm wouldn't port over very well. I thought a bit and was able to come up with this algorithm:

   1: -- My Implementation   2: breadth :: Tree a -> [a]   3: breadth nd =  map rootLabel $ nd : (breadth' [nd])   4:     where                5:       breadth' [] = []   6:       breadth' nds = let cs = foldr ((++).subForest) [] nds in   7:                      cs ++ breadth' cs

The idea was that each call to breadth' takes a list of nodes (which represents of level of the tree) and will concatenate the children of each of those nodes together and recursively call itself again with that list. This works but its not pretty Haskell. When choosing Haskell (from what I have learned) it is best if you can avoid explicit recursion and use built in combinators. After I coded my breadth first traversal function I decided to look into the Haskell standard libraries to see how it is done there. What I found was a function called levels which returns a list of lists, where each sub-list is a level of the tree. I slightly modified this to have the same functionality as my breadth function which creates one list of all the nodes in the breadth first order.

This is the resulting code:

   1: -- Haskell Standard Libraray Implementation   2: br :: Tree a -> [a]   3: br t = map rootLabel $   4:        concat $   5:        takeWhile (not . null) $                   6:        iterate (concatMap subForest) [t]

This is really slick implementation of what I did above. The algorithm is the same but the way they went about writing it is so much prettier.

When I am finally starting to get a handle on Monads...

MattManela — Sun, 06 Apr 2008 09:59:34 GMT

When I am finally starting to get a handle on Monads I discovered Arrows and I am thrown back into confusion. At least that is how it feels. In my exploration of Haskell I have spent a good deal of time trying to completely grasp and understand Monads. I have read much about it and feel pretty good about my understanding of them now. I am no expert but I at least am no longer afraid when I see or read about them.

But then I came across Arrows. Arrows (from what I understand) are a further abstraction on top of Monads which are themselves abstractions. What does this mean? I don't know.

I encountered arrows when I was looking into using the Haskell XML Toolkit. I was able to get a sample working (which I am planning to write about soon) using the toolkit and Arrows but it felt like shooting a pistol in the dark.

When I post the sample I created I will try my best to describe what I understand about it but I feel like this is going to be a slow road before I get a grasp on Arrows.

Lazy Prime Number Sieve in C#

MattManela — Mon, 17 Mar 2008 09:28:21 GMT

In my last post I talked about a Stream class for creating efficient lazy lists in C#. In addition, I showed several classic functional methods I ported to C# to be used on the lazy lists. As I mentioned in that post, I will now talk about an example I included in the source code for the lazy list class.

The example is an implementation of a naive sieve for generating prime numbers. This prime generator is a classic example of lazy list evaluation in Haskell. This is the sieve in Haskell:

primes = sieve [2..]
sieve (p : xs) = p : sieve [x | x <− xs, x ‘mod‘ p > 0]

This sieve is often mistakenly called the Sieve of Eratosthenes. This sieve behaves differently and is extremely less efficient. An explanation on how the sieve above is different from the Sieve of Eratosthenes can be found in this paper by Melissa E. O’Neill.

Irregardless of the fact that this is not the Sieve of Eratosthenes it still exhibits the beauty of lazy lists. Each invocation of the sieve method gets passed a new lazy list with a filter applied to it. The filter excuted on a per element basis when it is needed on an element. This code is really pretty and exhibits the idea of filtering an infinite stream and passing this filtered stream into another method to be filtered again.

With the stream class from my last post and some of the method I defined we can create this method in C# (although with out the same elegant syntax since we don't have list comprehension). My definition in C# is show below:

Stream<int> naturals = null;
naturals = new Stream<int>(0, () => ones.ZipWith(naturals, (x, y) => x + y));
Stream<int> naturalsFromTwo = naturals.Tail.Tail;

Stream<int> primes = null;
primes = Primes(naturalsFromTwo);

// ... 

static Stream<int> Primes(Stream<int> xs)
{
    return new Stream<int>(xs.Head, () => Primes(xs.Tail.Filter(x => x % xs.Head != 0)));
}

While this code looks much uglier it is doing the same thing. First of all, naturals, is a stream which is all the natural numbers. I then create naturalsFromTwo which is the same as [2..] which you saw in the Haskell code. The Primes function is the same as the sieve function in the Haskell code. It takes a stream and creates a new stream with all of the next primes multiples filtered out of it.

Beautiful!

Digging deeper into C# Lazy Lists

MattManela — Sat, 15 Mar 2008 09:47:00 GMT

One of the most interesting aspects of the Haskell language is the fact that features lazy evaluation. My interest in lazy evaluation led me to a post on Wes Dyers blog about lazy lists in C#. In his blog post he talks describes how to create a lazy list class in C# and demonstrates some classic lazy and functional methods of manipulating them. After reading this I decided to use his code as a basis to some further experimentation.

I started playing with his code and modifying it to make it easier to use. The end result was a class and a set of methods which allow you to easily use and manipulate lazy lists in C#. I will list some changes/ additions I made below:

Stream Class

I first changed the names next and value from Wes's example to head and tail since I feel that makes more sense.

I then modified the stream class to implement IEnumerable<T>. This will allow the stream to be used more seamlessly in code and act just as any other collection does. The implementation for GetEnumerator was pretty straight forward:

public IEnumerator<T> GetEnumerator()
{
    yield return head;

    var t = tail();
    if (t != null)
    {
        foreach (var x in t)
            yield return x;
    }

}

The third change I made to the Stream class was to not use his Memoize method but to add another field in the stream class called realized which will store the value of tail after its first use. I felt this was easier to read.

Lazy List Functions

In Wes's post he shows how to implement Zip (well he actually showed ZipWith but called it Zip) and Map on the stream class. I added to this by first converting them to extension methods just for convenience. Then I added many other methods over lists that any functional programmer is used to having like:

Fold

public static T FoldR<U, T>(this Stream<U> st1, Func<U, T, T> folder, T init)
{
    if (st1 == null) return init;
    if (st1 != null && st1.Tail == null) return folder(st1.Head, init);
    return folder(st1.Head, st1.Tail.FoldR(folder, init));
}

public static T FoldL<U, T>(this Stream<U> st1, Func<T, U, T> folder, T init)
{
    if (st1 == null) return init;
    return st1.Tail.FoldL(folder, folder(init, st1.Head));
}

and

Filter

public static Stream<T> Filter<T>(this Stream<T> st1, Func<T, bool> filter)
{
    if (st1 == null) return null;
    if (filter(st1.Head))
        return new Stream<T>(st1.Head, () => st1.Tail.Filter(filter));
    else
        return st1.Tail.Filter(filter);
}

Then to top it all off I added an extension method AsStream to allow you as convert any IEnumerable into a Stream:

public static Stream<T> AsStream<T>(this IEnumerable<T> coll)
{
    return coll.GetEnumerator().AsStream();
}

public static Stream<T> AsStream<T>(this IEnumerator<T> enumer)
{
    if (enumer.MoveNext())
    {
        return new Stream<T>(enumer.Current, () => enumer.AsStream());
    }
    else
    {
        return null;
    }
}

With all of these extension methods you will now be able to take a running start at Lazy Lists in C#.

I posted the code I worked on on Code Gallery so click here if you want to download it an give it a spin.

The code contains several examples of using the stream class and also a lazy prime generator which I will discuss in my next post.

Who would have thunk it?

MattManela — Wed, 19 Dec 2007 09:40:18 GMT

I recently read this article about Lazy Computation in C#. What the article discusses is creating lazy evaluation in C#.

Lazy evaluation is a key feature of functional languages like Haskell but is not common in imperative languages. It is used in Haskell because it implements parameter passing on a call by need basis. What this means is that a functions arguments are not executed until they are used but once used the argument retains its calculated value. This is good because it prevents wasted computation since if a argument isn't used it isn't executed.

The article goes into details about how to create lazily evaluated arguments and why they are useful.

Now, I don't know if anyone else found this posts title funny but I did because a lazily evaluated argument used in Haskell and that the article shows how to create is commonly referred to as a Thunk. :)

Lambda Expressions are more fun in Visual Basic .NET

MattManela — Fri, 07 Dec 2007 09:33:35 GMT

I love C# and I would never want to do anything to make it seem any less amazing but I have to give credit where credit is due ... to Visual Basic .NET. Yes, I said it. Both languages have been adding features inspired by the functional and dynamic programing world. However, VB .NET has went a few steps further to truly merge imperative, object oriented, dynamic and functional programing into one convenient package.

Much of this functionality comes from the fact that VB .NET has late binding built in to many of its operations. This allows the programmer to be more expressive and "get away" with more. I was aware that VB .NET had some unique features but as a C# programmer I never got around to playing around with it to see how they feel.

This changed recently when I was fooling around with lambda expressions in C#. I have been casually playing and experimenting with Haskell (a pure functional programing language) for about a year now and I have become very accustomed with just writing a lambda expression and not worrying about defining its type.

With C# 3.0 I assumed I would be able to do the same thing. I wanted to be able to write C# code that is similar to the following Haskell code:

f = \x -> x + x

I figured this would be done easily in C# with the lambda expressions and implicitly typed variables. So I wrote:

var f = x => x + x;

I was very pleased with this code, it looked very close to the Haskell. It is concise, clean and quick however it doesn't compile. You get this error:

Cannot assign lambda expression to an implicitly-typed local variable

The problem is that C# is strongly typed and is unable to determine what type f should be since it cannot determine what type x is. So, you would have to write something like this:

Func<int,int> f = x => x + x;

Now, that isn't hard to do but I don't want to have to write out that type every time I want to create a lambda expression.

I tried the same lambda expression in Visual Basic .NET and ...:

Dim f = Function(x) x + x

Tada!, that worked like a charm. And when I call f(2) it returns 4, and when I call f("matt") it would return "mattmatt".

This was the behavior I was looking for. This peaked my interest in VB .NET and since then I have been exploring features in it and seeing how it performs late binding to make this all happen.

After I experiment some more I will write in detail about what is really going on behind the scenes in the VB .NET Compiler.