• Introduction to Functional Programming - by Brad Clow
• Haskell 101 - by me!

There are still spots available if you're keen to come along. It should be fun!

I'm always up for some public scrutiny, so come along and bring your rotten tomatoes.

If you can't make it, I'll post the slides for the talk on this site, and on Meetup.com, when the event has finished so you can see what was covered. Feel free to ping me or ask questions.

Update 19th Aug '09
The talk seemed to go quite well. I had to motor through the material quite quickly due to the late start, but on the whole I think it was well received. I haven't had any negative feedback so far

Slides/content are now up for grabs!

Communities are arguably the life blood of technology. Without a good community the likelihood of the technology catching on is drastically reduced. Those communities which lack individuals that are happy to put time and effort in to help get others up to speed tend to stagnate. Any community which involves members that are abrasive, rude and downright offensive is destined to suffer long term.

The level of suffering will vary depending on quite a few things. Those things include existing user base, the age of the technology and the number of different ways that a given n00b can get information about that technology.

IRC is a very common and popular means for members of communities to interact. It provides a real-time element that you don't get with blogs, forums and other media like Twitter. It satisfies every geek's desire to get the answer and get it now. Experiencing support in real time via IRC can be extremely helpful and rewarding. It can work wonders for the popularity and image of the community and the technology itself.

If you're interested in seeing some active and extremely helpful communities, you should take a look at #haskell and #mercurial. Both of these channels are generally very active. The people that spend time in them are both helpful and friendly. Both of these channels indicate to me that there is a very healthy and vibrant community behind each of these pieces of technology.

Unfortunately, this kind of communication also has a downside. The real-time nature of IRC allows people to vent anger on newcomers without any means of moderation. The net result of this is that other individuals become to scared to offer their view or provide support for fear of receiving the same treatment. This goes for members with any level of skill or knowledge. There are some community channels out there containing hundreds of people, and yet there is no conversation. When questions are asked, nobody responds.

After my recent experience in a channel that fist this description, it's easy to see why. In less that half an hour of asking for clarification on certain points, I received a barrage of abuse which, in my view, was totally unjustified.

But let's say, for the sake of argument, that it was justified. That for some reason I annoyed someone in such a way that bombarding me with many 4 and 5-letter expletives was acceptable. Do you think that it paints a good picture of the community?

I think not.

In less than half an hour I went from excited to deflated. I lost interest in the piece of technology and lost faith in the community around it. Was my response justified or understandable?

I'm not sure about the answer to this

I feel that it's the job of the community to moderate other members of their community. If people get abusive then other members should step in and prevent it. In my case this wasn't possible due to the fact that the person in question was abusing me via a private chat so that the channel couldn't witness his venting. I'm guessing this wasn't the first time that he's done this to someone, nor will it be the last. I wonder how many others have suffered the same fate? If the silence of the channel is anything to go by, I'm guessing quite a few.

I guess what I'm trying to say here is this: don't underestimate the value and importance of your community. It's one of the most frequented faces of your technology. If it's bitter, unwelcoming and unsupportive, you will not only lose valuable newcomers who come looking for information and support, you will also lose future users due to the poor reputation. Ultimately, your tech will suffer.

If you're part of a community, do your bit to police it. Help those who need help. Stop those people who are abusive.

.. and if you don't have anything nice to say, then don't say anything at all!

A little bit of history...

Recently I've been delving into Haskell quite a bit. It's part of my apparently never-ending quest to learn as much as I can about as many languages as I can (well, those that appeal to me at least :)). While I love playing around with a language, toying with ideas, writing small programs, reading books, blog posts, etc it's not really the same as having an on-call expert to help and guide you.

While I'm aware of, and frequently visit, the Haskell IRC channell I find that the level of understanding there is so great that my piddly noob questions tend to get lost amongst the bombardment of much more advanced & interesting discussions. In short, while I find it a great place to go, it's not a great place to find someone who's happy to help guide me through the maze and go over topics in quite a bit of detail while I annoy them with questions.

Haskell is one of those languages where having a mentor is really beneficial. So I set about finding myself one. Thankfully, I found a rather helpful chap based in the UK, (he shall remain anonymous, as I don't want to violate the man's privacy), Peter Marks, who has been very forthcoming with information. He's humoured me and been incredibly patient so far, and I'm very grateful for his time.

One of the questions that I asked him was:

Why is it that everyone seems to strive to get their code into Point-Free style? I can see how a lot of the implementations are more concise, but many of those lose readability.

What is so special about it?

The discussion that followed was really insightful. That is what has inspired me to write this post.

Please note, any errors in this post are totally my own. They are not the fault of my mentor

The purpose of the post: Why aim for Point-Free style?

So it is just me, or does anyone else out there feel that there's a bit of a "thing" going on for Point-Free style? Sometimes I share my terrible code with people and I get shunned when it's not Point-Free and it could be.

Anyone?

I hope it's not just me Let's start with taking a quick look at what Point-Free style actually is.

So what is Point-Free style?

If we take a look at the Wikipedia we can see that..

Tacit [point-free] programming is a programming paradigm in which a function definition does not include information regarding its arguments, using combinators and function composition (but not ?-abstraction) instead of variables.

Simple eh? In essence, it basically means that your function definition doesn't reference any of its arguments/variables. For a crass definition, think point == argument and it should make sense.

So we're writing functions without directly referencing its arguments. For those not familiar with Haskell or other languages that support this, let's take a look at an example:

-- sum : take a list of numbers and add them all up to get a total
-- start with the base-case: an empty list
sum [] = 0
sum (x:xs) = x + sum xs

We can see that the above function is written in such a way that the arguments passed into the function are actually referenced in the body of the code. This is how a standard imperative programmer would write this function if he/she was new to Haskell. If we instead used a fold, we could define it like so:

sum xs = foldr (+) 0 xs

This does exactly the same thing as the previous definition, but as you can see the grunt work is done by the fold function. Now that we have this definition, we can easily move to Point-Free style:

sum = foldr (+) 0

Here we can see that no reference is made to the arguments of the function. Since we haven't referenced any "points", we have a Point-Free implementation.

Awesome. Cool. Sweet. Nifty.

But what does it give me? Why is it better?

Why use Point-Free style?

This section is based totally on my own opinion and is not an official definition I think that Point-Free style fits in the same category as many other coding patterns and styles, and that it's usually down to the individual programmer to determine the when and the why. So take my view with a pinch of salt.

In short, Point-Free style let's you focus on the how rather than the what.

It might be just me, but imperative programs seem to have a large focus on the data. The code which operates on the data is lost within a plethora of code that isn't necessarily specific to what the program needs to do. I've found that functional programming tends to be very different, at least in Haskell. Haskell lets me focus on what it is I need to do, and I feel that Point-Free is another step in the same direction. Is this good? I think so But I'll let you decide.

As well as the focus on the what I've found that aiming for a Point-Free solution can aid in helping you understand your problem better. This claim sounds like fluff, so let's go through an example and hopefully you'll see what I mean.

Where Point-Free helped me get a better understanding

Haskell developers use the composition operator (.) a lot. It actually aids in creating Point-Free style. I love the irony here. We add points (.) to remove points (arguments).

Anyway, the composition operator's definition, according to Prelude is:

(.)       :: (b -> c) -> (a -> b) -> a -> c
(.) f g x = f (g x)

This operator takes two functions and produces a function which is composed of the two. This function takes the output of one function and sends it through as the input to another function, returning the result of that call.

This is really handy. We can do some interesting things like:

ghci> let doubleAndAdd5 = (+5) . (*2)
ghci> doubleAndAdd5 20
45
ghci> :m +Data.List
ghci> let sumColumns = map sum . transpose
ghci> sumColumns [[1,2,3],[4,5,6],[7,8,9]]
[12,15,18]

Very handy indeed. While handy, it doesn't necessarily allow us to do everything we might want to do. One example is handling cases where we want to compose a function where the right-hand function takes two arguments instead of one.

So if we wanted to create a function that would take two values, add them together and double the result, all while using Point-Free style, we'd like to do something like this:

ghci> let addAndDouble = (*2) . (+)

:1:20:
    No instance for (Num (a -> a))
      arising from a use of `*' at :1:20-21
    Possible fix: add an instance declaration for (Num (a -> a))
    In the first argument of `(.)', namely `(* 2)'
    In the expression: (* 2) . (+)
    In the definition of `addAndDouble': addAndDouble = (* 2) . (+)
ghci>

As you can see, ghci doesn't like it. And rightly so! This is because the composition operator's signature is:

(.) :: (b -> c) -> (a -> b) -> a -> c

That is:

1. It takes an argument which is a function which takes a value of type b which returns a value of type c
2. It takes a function which takes a value of type a which returns returns a value of type b
3. It returns a new function which takes a value of type a and returns a value of type c

This doesn't work in our case, as we want our right-hand function to take two arguments. That is, we want a type signature that looks like this:

foo :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c

So everywhere we had (a -> b), what we really want is (a -> a1 -> b). Given that we don't have an operator that does that for us, let's define one. We'll start with the definition of the (.) operator and work towards a function that does what we need.

-- here is the composition operator again
(.) f g x = f (g x)
-- here's our new operator's definition
(.^) f g x y = f (g x y)

Simple! Let's see what ghci says about it:

ghci> let (.^) f g x y = f (g x y)
ghci> :t (.^)
a :: (t2 -> t3) -> (t -> t1 -> t2) -> t -> t1 -> t3

Looks good! This is exactly what we need. Now that we have a working function, let's aim to write this in Point-Free style. We do this by breaking down the function slowly and eliminating arguments by moving them to the far right hand side of the function definition.

The first argument to get rid of is 'y', as this is the last argument passed in:

-- start by moving y to the right
(.^) f g x y = f (g x y)
-- becomes
(.^) f g x y = f . (g x) $ y

These are functionally equivalent, and now that 'y' is out on it's own, we can drop it from our function definition:

ghci> let (.^) f g x = f . (g x)
ghci> :t (.^)
(.^) :: (b -> c) -> (t -> a -> b) -> t -> a -> c
ghci>

Excellent, we're a step closer. Now we need to do the same with 'x'. This takes a little more fiddling:

-- we need to take the original definition
(.^) f g x = f . (g x)
-- and change it so that it uses prefix notation instead of infix
(.^) f g x = (.) f (g x)
-- which is the same as
(.^) f g x = ((.) f) (g x)
-- what we're doing is calling g with x and applying the result to f
-- and hence we can compose the composition of f with the call to g
-- giving us the following
(.^) f g x = ((.) f) . g $ x
-- finally leaving us with
(.^) f g = ((.) f) . g

Phew I hope you can see the progression. We've managed to move x out of the picture, so now we're down to a fairly crazy looking definition. Let's see what ghci has to say:

ghci> let (.^) f g = ((.) f) . g
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So we've got rid of two variables, but there are still two more to go! Remember, 'f' and 'g' are still variables, they just carry functions. So let's get rid of 'g':

-- start with what we had before
(.^) f g = ((.) f) . g
-- change to prefix notation again
(.^) f g = (.) ((.) f) g
-- and drop g
(.^) f = (.) ((.) f)

This is looking rather crazy Again, let's make sure we haven't done anything stupid:

ghci> let (.^) f = (.) ((.) f)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

Excellent. We've still got what we need. One more point needs to be dropped, so let's get rid of 'f':

-- start with what we had before
(.^) f = (.) ((.) f)
-- which means that we're composing a composition with a
-- function composed of f and something else
(.^) f = (.) . (.) $ f
-- and we finally drop f
(.^) = (.) . (.)

Isn't that just crazy! Let's again check ghci:

ghci> let (.^) = (.) . (.)
ghci> :t (.^)
(.^) :: (b -> c) -> (a1 -> a -> b) -> a1 -> a -> c

So there we have it, our operator completely in Point-Free style.

This is where the penny dropped for me. The whole exercise of moving through to Point-Free made me really understand what it was I was doing in the first place. The final definition makes it very clear. We're composing two separate compositions.
Let's see if our function behaves itself using the example we listed above.

ghci> let addAndDouble = (*2) .^ (+)
ghci> :t addAndDouble
addAndDouble :: Integer -> Integer -> Integer
ghci> addAndDouble 10 15
50
ghci> addAndDouble 21 3
48

It does exactly what we need it too.

Conclusion

To sum up, Point-Free helps you tidy your code into more concise implementations which tend to aid you in understanding what it is you are trying to do. I feel it really helps you focus on what you're doing as opposed to what you're doing it to. It's down to you to determine whether you feel this is a good thing or not!

It is ultimately down to the developer to dictate when it should be used. There are definitely cases where the resulting function might not actually help in making things clearer. But on the whole, Point-Free style seems to help me understand what it is I'm doing (or, arguably, not doing).

Of course, you could just get sick and tired of trying to come up with variable names, in which case Point-Free is the bomb

Feedback of any kind is always welcome. Cheers!

A sample of the data might look something like this:

data = ({150,200,45,57,95,2,45,32,15,10,5,2,2,4},
         12,20,45,37,10,5,2,2,10,95,2,45,32,7},
         32,15,10,5,2,23,24,15,20,45,57,95,0,45})

So the first step would be to add 150, 12 and 32 and store the value. Then 200, 20 and 15, and store the value. Do this for all of the columns, then get a maximum and a minimum.

This little algorithm was going to be part of his project, and hence needed to be implemented in AS3. So I picked his brains about the AS3 syntax, because I have absolutely no clue given that I've never worked with any version of ActionScript in the past.

Together, we came up with the following solution:

var columnTotal:Number;
var biggest:Number;
var smallest:Number;
biggest = smallest = sum(vData, 0);

for(var i = 1; i < _scope.period_mcs.length; ++i)
{
  columnTotal = sum(vData, i);
  biggest = Math.max(biggest, columnTotal);
  smallest = Math.min(smallest, columnTotal);
}

// helper function
function sum(var data:Array, var index:Integer):Number
{
  var total:Number = 0;
  for(int i = 0; i < data.length; ++i)
  {
    total += data[i][index];
  }
  return total;
}

Does it work? Yes, it sure does. Is it optimal? Yes, and no I was lazy and used the Math.max and Math.min functions instead of doing the obvious...

if(biggest < columnTotal) biggest = columnTotal;

So if we did that, to reduce the need for function calls and unnecessary assignments, we end up with this:

var columnTotal:Number;
var biggest:Number;
var smallest:Number;
biggest = smallest = sum(vData, 0);

for(var i = 1; i < _scope.period_mcs.length; ++i)
{
  columnTotal = sum(vData, i);
  if(biggest < columnTotal)
  {
    biggest = columnTotal;
  }
  else if(smallest > columnTotal)
  {
    smallest = columnTotal;
  }
}

// helper function
function sum(var data:Array, var index:Integer):Number
{
  var total:Number = 0;
  for(int i = 0; i < data.length; ++i)
  {
    total += data[i][index];
  }
  return total;
}

I can't see many ways to improve on this without going overboard with optimisation. Any AS3 guru's are more than welcome to prove me wrong!

So after thinking about this in an imperative language, I couldn't help but have a look at what the functional version might look like. Of course, my current chosen Functional toy is Haskell and so I fired up VIM and GHCI and had a bit of a play.

First, I put the data into Haskell's list format:

vals = [[150,200,45,57,95,2,45,32,15,10,5,2,2,4],
        [12,20,45,37,10,5,2,2,10,95,2,45,32,7],
        [32,15,10,5,2,23,24,15,20,45,57,95,0,45]]

That was easy enough. The next step was to break the problem down so that I could use some of the built in functions of Haskell's Prelude libraries. My thought processes were:

1. Summing the column of the array could be done using sum, but I'd need to change the list so that rows become columns, and vice-versa.
2. To switch rows and columns, I could use the transpose function.
3. Then all I'd need to do is use maximum and minimum to get the right values out.

Being a bit of a primitive Haskeller, my first pass was something like this:

extremes n = (b, s)
  where
    l = map sum $ transpose n
    b = maximum l
    s = minimum l

The function extremes is the function which takes the data (list of lists) and spits out a tuple of (max, min).

Before the end of the conversation with my designer colleague in arms, I pinged him my version of the solution in Haskell and needless to say he was a little surprised as how concise it was. I was sure to point out that there is no doubt a better way of representing this solution with regards to speed and conciseness.

The first thing that I thought could be improved would be using a custom fold to get the max and min while parsing the transposed list. This would allow us to calculate the values in a single pass and hence be a little better with regards to performance. That would obviously sacrifice a little bit of the conciseness we're looking for.

When the conversation ended, I jumped onto IRC and spoke to some more seasoned Haskellers. The first suggested improvement that popped out of that chat was to use arrows to remove the need for the where clause. That solution looks like this:

extremes = (maximum &&& minimum) . map sum . transpose

Nifty Of all the other options, this proved to be the most readable and concise, though not the best performing.

The next most notable solution included the fold which calculated the min and max in a single parse, not a double parse:

extremes = foldl1 (\(a, b) -> max a *** min b) . join zip . map sum . transpose

Folds really are fantastic aren't they. Again we're using arrows here to do a bit of heavy lifting and that keeps things looking a little nicer.

So after this little session, my designer friend was aware of how easy it can be to crunch certain types of data using a functional language, like Haskell. It made me think again about how it'd be nice to just be able to plug in whichever language we wanted whenever we felt it would do the job better than whatever the current tool is.

So how would you improve it?

Problem #10 takes us back into the realm of the relatively boring - prime numbers (again). The question is as follows:

The sum of the primes below 10 is 2 + 3 + 5 + 7 = 17.

Find the sum of all the primes below two million.

Exciting stuff! Since we've already got ourselves a relatively nifty prime number generator from a previous post, we can simply reuse this, along with the sum function that comes in Prelude, to generate the answer.

Here is what the code looks like:

merge :: (Ord a) => [a] -> [a] -> [a]
merge xs@(x:xt) ys@(y:yt) =
  case compare x y of
    LT -> x : (merge xt ys)
    EQ -> x : (merge xt yt)
    GT -> y : (merge xs yt)
 
diff :: (Ord a) => [a] -> [a] -> [a]
diff xs@(x:xt) ys@(y:yt) =
  case compare x y of
    LT -> x : (diff xt ys)
    EQ -> diff xt yt
    GT -> diff xs yt
 
primes, nonprimes :: [Integer]
primes    = [2, 3, 5] ++ (diff [7, 9 ..] nonprimes)
nonprimes = foldr1 f $ map g $ tail primes
  where
    f (x:xt) ys = x : (merge xt ys)
    g p         = [ n * p | n <- [p, p + 2 ..]]
 
main :: IO ()
main = print $ sum (takeWhile (<2000000) primes)

I don't really have much else to say about this. I won't bother with the performance information because it's not really doing anything too exciting that hasn't already been discussed.

Cheers!

Prelude> nub [1,1,3,3,5,5,6,6,6,1]
[1,3,5,6]

Fairly simple stuff. Until recently I hadn't bothered pondering the internal implementation of this function because I hadn't really been too worried about performance. That's no longer the case. I recently cracked open the hood of nub, and was rather surprised by what I saw.

Since the source of Prelude is in the public domain, I'm safe to show you the content:

nub                     :: (Eq a) => [a] -> [a]
nub                      = nubBy (==)
 
nubBy                   :: (a -> a -> Bool) -> [a] -> [a]
nubBy eq []              = []
nubBy eq (x:xs)          = x : nubBy eq (filter (\y -> not (eq x y)) xs)

So nub uses nubBy and passes (==) as the filter for the items. This is all well and good, but the result is an O(n²) level of complexity! In this day and age that's pretty poor for a simple filtering mechanism, especially when we have more powerful mechanisms built-in to most libraries.

Since seeing this I had added a "write my own nub" task to my TODO list, but I haven't yet got round to it. So you can imagine my delight when I found this comment by Jedai over at hvergi.net. He'd pointed out that nub was indeed inefficient, and showed an alternative implementation:

Note that nub only demands that the list element be part of the Eq typeclass. As a result it is very inefficient and a better solution must always be prefered whenever the nature of the elements allows it.

import qualified Data.Set as S
nub' :: (Ord a) => [a] -> [a]
nub' = go S.empty
  where go _ [] = []
        go s (x:xs) | S.member x s = go s xs
                    | otherwise    = x : go (S.insert x s) xs

La différence de performance est énorme.

You got that right! Thanks to Jedai (and Arnar via hvergi.net) I now have a much faster nub implementation. Cheers guys!

It just goes to show that even these days you can't always trust the libraries. There is no harm is taking a look under the hood to see what's going on! You don't have to reinvent the wheel, but there's nothing wrong with making the wheel smoother

Problem #9 takes a turn back into the math theory and forces you to think about Pythagorean triplets. It goes as follows:

A Pythagorean triplet is a set of three natural numbers, a b c, for which,
    a² + b² = c²

For example, 3² + 4² = 9 + 16 = 25 = 5².

There exists exactly one Pythagorean triplet for which a + b + c = 1000.
Find the product abc.

The first solution to this problem that I came up with was just atrocious It was long, bloated and extremely messy. But it worked. If you really want to see it then ask me nicely and I'll post it.

For now I'm going to show you my second attempt, which is a little nicer on the eyes.

main :: IO ()
main = print $ head [ a * b * c
                    | b <- [1..400],
                      a <- [b..400],
                      let c = 1000 - a - b,
                      c^2 == a^2 + b^2 ]

It's a mini brute-forcer which uses two variables to count up to 400. I chose 400 as the end number because it seemed like a stupid idea to go as far as 500 when brute forcing since the first of the numbers that fit the criteria wouldn't be anywhere near that high. For each combination of numbers I pick what's left over and check to see if it fits the rules of a Pythagorean triplet. In this case there is only one that does (as per the question).

We can see below that the solution isn't particularly fantastic as far as performance goes. It's not terrible, but approaching .2 seconds for a problem like this is starting to get on the sluggish side.

	Fri Jul 25 21:28 2008 Time and Allocation Profiling Report  (Final)

	   main +RTS -p -RTS

	total time  =        0.18 secs   (9 ticks @ 20 ms)
	total alloc =  29,337,532 bytes  (excludes profiling overheads)

COST CENTRE   MODULE  %time %alloc

CAF           Main    100.0  100.0

                                           individual    inherited
COST CENTRE   MODULE      no.    entries  %time %alloc   %time %alloc

MAIN          MAIN          1           0   0.0    0.0   100.0  100.0
 CAF          Main        152          16 100.0  100.0   100.0  100.0
 CAF          GHC.Handle   88           4   0.0    0.0     0.0    0.0

Another way of brute-force solving this is to abuse a bit of math. We know that each Pythagorean triplet is representative of the sides of a triangle. Given that the sides of a triangle scale evenly when the entire triangle is scaled, we can assume that if we were able to find a triplet whose sum is a factor of 1000, then we could use this factor to generate a, b and c. It turns out that the 5th Pythagorean triplet (8, 15, 17) adds up to 40, and since 40 * 25 == 1000, we can simply multiple each of the values by 25 to get (200, 375, 425).

While this is interesting, brute-force methods aren't never really the nicest way of solving a given problem. In the case of Project Euler it's rare to find a problem that doesn't have some form of trickery that can be abused to get the answer in a much more efficient manner. The theory that should be used is that each Pythagorean triplet can be written in the following form:

k [ m^2 - n^2, 2mn, m^2 + n^2 ]

This info can be abused to come up with some code to generate the answer rather quickly. At this point, I become tired of the problem and decided not to implement a version that uses this theory. If you decide to write one, please ping me!

The challenge was first posted here. The problem is as follows:

Write a counter function that counts from 1 to max but only returns numbers whose digits don't repeat.

For example, part of the output would be:

* 8, 9, 10, 12 (11 is not valid)
* 98, 102, 103 (99, 100 and 101 are not valid)
* 5432, 5436, 5437 (5433, 5434 and 5435 are not valid)

Also:

* Display the biggest jump (in the sequences above, it's 4: 98 -> 102)
* Display the total count of numbers
* Give these two values for max=10000

So without further ado, here's my solution:

import Data.List
 
noDups :: String -> Bool
noDups l = length l == length (nub l)
 
items :: [Int]
items = filter (noDups . show) [1..10000]
 
main :: IO ()
main = print $ (maximum (zipWith (-) (tail items) items), length items)

It's probably not as concise as it could be, and I'm sure a more experienced Haskeller would be able to tidy it up a little bit. Despite that, it still performs quite well:

Thu Jul 24 21:34 2008 Time and Allocation Profiling Report  (Final)

	   main +RTS -p -RTS

	total time  =        0.00 secs   (0 ticks @ 20 ms)
	total alloc =   4,121,500 bytes  (excludes profiling overheads)

COST CENTRE   MODULE   %time %alloc

CAF           Main       0.0  100.0

                                            individual    inherited
COST CENTRE   MODULE       no.    entries  %time %alloc   %time %alloc

MAIN          MAIN           1           0   0.0    0.0     0.0  100.0
 CAF          Main         152          14   0.0  100.0     0.0  100.0
 CAF          GHC.Handle    88           4   0.0    0.0     0.0    0.0

Thoughts? How could I make this better/faster/more elegant? I'm keen to get some insight from a more experienced Haskell coder Cheers!

Problem #8 was thankfully a great deal more interesting than the last problem. It goes as follows..

Find the greatest product of five consecutive digits in the 1000-digit number.

   73167176531330624919225119674426574742355349194934
   96983520312774506326239578318016984801869478851843
   85861560789112949495459501737958331952853208805511
   12540698747158523863050715693290963295227443043557
   66896648950445244523161731856403098711121722383113
   62229893423380308135336276614282806444486645238749
   30358907296290491560440772390713810515859307960866
   70172427121883998797908792274921901699720888093776
   65727333001053367881220235421809751254540594752243
   52584907711670556013604839586446706324415722155397
   53697817977846174064955149290862569321978468622482
   83972241375657056057490261407972968652414535100474
   82166370484403199890008895243450658541227588666881
   16427171479924442928230863465674813919123162824586
   17866458359124566529476545682848912883142607690042
   24219022671055626321111109370544217506941658960408
   07198403850962455444362981230987879927244284909188
   84580156166097919133875499200524063689912560717606
   05886116467109405077541002256983155200055935729725
   71636269561882670428252483600823257530420752963450

I'm keeping with my Haskell theme and abusing some of the nice feature of Functional Programming to nail this one.

Here's my solution:

-- ord is required to convert chars to ints
import Data.Char (ord)
 
-- a string representation of the large number
number :: String
number =
     "73167176531330624919225119674426574742355349194934"
  ++ "96983520312774506326239578318016984801869478851843"
  ++ "85861560789112949495459501737958331952853208805511"
  ++ "12540698747158523863050715693290963295227443043557"
  ++ "66896648950445244523161731856403098711121722383113"
  ++ "62229893423380308135336276614282806444486645238749"
  ++ "30358907296290491560440772390713810515859307960866"
  ++ "70172427121883998797908792274921901699720888093776"
  ++ "65727333001053367881220235421809751254540594752243"
  ++ "52584907711670556013604839586446706324415722155397"
  ++ "53697817977846174064955149290862569321978468622482"
  ++ "83972241375657056057490261407972968652414535100474"
  ++ "82166370484403199890008895243450658541227588666881"
  ++ "16427171479924442928230863465674813919123162824586"
  ++ "17866458359124566529476545682848912883142607690042"
  ++ "24219022671055626321111109370544217506941658960408"
  ++ "07198403850962455444362981230987879927244284909188"
  ++ "84580156166097919133875499200524063689912560717606"
  ++ "05886116467109405077541002256983155200055935729725"
  ++ "71636269561882670428252483600823257530420752963450"
 
-- converts the number to a list of Int values
numberList :: [Int]
numberList = map (\n -> ord n - ord '0') number
 
-- breaks up the number list into chunks of 5 digits
chunks :: [[Int]]
chunks = c' numberList 5 995
  where
    c' _ _ 0 = []
    c' l n c = (take n l) : c' (tail l) n (c - 1)
 
-- main function iterates over the list of chunks,
-- calculates the product of each of the chunks and
-- then determines the biggest result
main :: IO ()
main = print $ foldr1 max (map product chunks)

The comments are pretty descriptive of what goes on. It turns out that the solution isn't that shabby in the performance stakes either:

Thu Jul 24 20:46 2008 Time and Allocation Profiling Report  (Final)

	   main +RTS -p -RTS

	total time  =        0.00 secs   (0 ticks @ 20 ms)
	total alloc =     571,224 bytes  (excludes profiling overheads)

COST CENTRE   MODULE  %time %alloc

CAF           Main      0.0   99.8

                                           individual    inherited
COST CENTRE   MODULE        no.  entries  %time %alloc   %time %alloc

MAIN          MAIN            1         0   0.0    0.0     0.0  100.0
 CAF          Main          152        15   0.0   99.8     0.0   99.8
 CAF          GHC.Handle     88         4   0.0    0.2     0.0    0.2

I still love how concise and easy the solutions to problems like this are in Haskell.

Problem #7 was as boring as batshit (to be quite frank). The only reason I'm posting about it is to keep The Head happy

The reason I thought it was boring was because it was just the age-old problem of "how fast can you generate primes":

By listing the first six prime numbers: 2, 3, 5, 7, 11, and 13, we can see that the 6th prime is 13.

What is the 10001st prime number?

A simple search of the web reveals a million different ways of solving this problem -- mostly written by people smarter than me

So did I cheat? No I didn't. I wrote the standard Sieve of Eratosthenes implementation in Haskell and got the answer in a respectable amount of time. Exciting stuff :|

I browsed around the web a little bit after solving the problem because I was interested to see how others might have solved it using Haskell. Yes, I am aware that there is a whole page dedicated to it but that wasn't enough.

After a bit of a search, I stumbled across this little doozy. If you can make heads or tails of it you're a better man than I It's quite a mind job to get your head around how this code works. This is an exercise I leave to the reader.

merge :: (Ord a) => [a] -> [a] -> [a]
merge xs@(x:xt) ys@(y:yt) =
  case compare x y of
    LT -> x : (merge xt ys)
    EQ -> x : (merge xt yt)
    GT -> y : (merge xs yt)
 
diff :: (Ord a) => [a] -> [a] -> [a]
diff xs@(x:xt) ys@(y:yt) =
  case compare x y of
    LT -> x : (diff xt ys)
    EQ -> diff xt yt
    GT -> diff xs yt
 
primes, nonprimes :: [Integer]
primes    = [2, 3, 5] ++ (diff [7, 9 ..] nonprimes)
nonprimes = foldr1 f $ map g $ tail primes
  where
    f (x:xt) ys = x : (merge xt ys)
    g p         = [ n * p | n <- [p, p + 2 ..]]
 
main :: IO ()
main = print $ primes !! 10000

Enjoy

PS. Jon - are ya happy now?