This month we have three speakers, and I am one of them! In my talk, "Erlang - Why should you care?", I will be giving a fairly non-technical introduction to Erlang. I'll be covering off the features of the language, some of its design goals and its history. I aiming to show that this language is not one that was spawned out of academia and that it has been applied in the real-world ever since its conception. If I have time, I'll also be giving a small demonstration of one of the neatest features of the technology.

I'll be posting the slides and demonstration code here on this blog as well as BFPG's home after the meetup has taken place.

Myself and my comrades, Tom and Tony, will aim to provide a fun and interesting evening at our new venue. Based on the RSVPs so far, it looks like we are going to have one of the biggest turn-outs to date. This is probably due to the exposure we got during last month's talk by Dave Thomas. There are still plenty of spots left, so if you're keen to come along, go and sign up. Bring your friends, your friend's friends and your mum.

I hope to see you there!

Update (6th July 2010): We had a fantastic turn-out of just short of 50 people (a record breaker for the group so far!). My talk seemed to be fairly well-received. No rotten tomatoes were thrown and the crowd seemed engaged through most of the talk. It felt good! I think many people wanted to see more code, but since that wasn't the focus of the talk they were a little disappointed. If people are keen for more Erlang goodness at future meetups, then I'll be happy to dive a little deeper.

As promised, here are the slides:

1. PPTX
2. PDF (Google Docs)
3. PPT (Google Docs)

If you have issues reading the slide deck, or would like it in another format, then please drop me a line.

The talk was covering Functional Programming and the NoSQL movement (which, as Dave himself puts it, should be called NoRDB). These are two areas of computing that are currently key interests of mine, so it won't come as a surprise to find that I thoroughly enjoyed the talk. I certainly wasn't the only one. Dave did such a great job of covering the positives of these two movements that we're already seeing more and more people signing up for membership to BFPG.

I'm not going to go into the gory details about what Dave covered in his talk as I don't want to spoil it for other people if he plans on doing it again elsewhere. There are a few things I would like to mention though:

• Functional Programming is here to stay. If you're not familiar with it, or haven't yet taken a look at it, I suggest you get started!
• If you're looking to get involved with FP and you're in or around the Brisbane area, be sure to come to one of our BFPG meetups.
• Don't fall into the trap of assuming that if your system needs a back-end data store that an RDBMS is the only option, because it's not!

This talk has inspired me to not only continue checking out the likes of Haskell, Erlang and Riak, it's pointed me at some languages that I never knew existed. Languages which are insanely powerful, very dense, yet still extremely useful. Some examples are J, K and Q. KDB+ in particular is very interesting as it ties in with the use of another type of technology that I was aware of but knew nothing about: Column Databases. Crazy stuff.

After seeing so many people excited by the prospect of Functional Programming after Dave's talk had concluded, I decided to set up a new website for BFPG so that we had a proper home rather than just a spot on Meetup.com. Check it out and feel free to send through some feedback if you have any, or drop us a line if you have any ideas for talks or would like to present something yourself.

That's it for today's brain-fart

I can thank Gabrielle Lana for this discovery, as it was his attempt at one of the katas that got me into it. He's also the reason I looked into Katacasts, which are simply screencasted recordings of people attempting to solve Code Katas.

This post is about my first Katacast, capturing my attempt at Code Kata #9 using Erlang and VIM with Rake as my build system. I've put the video up on Vimeo for the world to see/share. It's also embedded below for your convenience.

Before watching, I'd like to point out a few things about the video, and things that I have learned from the experience:

• I captured the video on my Linux Mint install. For some reason, capturing quality video in Linux is proving to be a bit of a pain for me. As a result, the video quality isn't that great. This partly due to the compression of the video, and partly due to the software failing to pick up some screen updates.
• I tried really hard to add a backing sound-track but all of my efforts failed in one way or another. If I did manage to get one to work it was either WAY too big (ie. > 1GB in size) or the quality was absolutely terrible.
• There were points during the process where I had to alt-tab out to a browser to do a bit of research on something that I didn't know (such as an Erlang syntax quirk). This resulted in a few points where I don't appear to be doing anything. In future, I'll remember to hit pause on the recording when this happens.
• I captured it in a non-standard resolution. I'm not sure if that's going to make it look bad or not. Feedback here is appreciated. I think in future I'll capture at a 800x600 resolution.
• This video is best viewed in full-screen mode.

So please excuse the lack of quality in this first Katacast. I'll be sure to improve when I next create one. That being said, on with the show!

As always, feedback/criticism/etc is greatly appreciated. I'd love to hear what you guys do and use to capture and edit your screencasts, particularly in Linux.

I know, this kind of thing happens thousands of times a day. Some arbitrary geek decided to build the next killer app and expects to make a crapload of cash out of it. While that would be nice, the ultimate goal isn't the cash. The goal for me is to build something that gets used, and for me to begin to master an area of technology that I've had a quiet passion for for a long period of time now.

My plan is simple. While learning the technologies that I will be using I'll be building another application and blogging about it so that all of you can learn with me. Meanwhile, I shall use my learnings to build this other application at the same time.

The final result should be a series of posts which help other people learn the technology stack, give better coverage and visibility to languages and technologies that a lot of the geek world doesn't know about (and really should!), and for me to carve myself a bit of a niche here on the East coast of Ozland. I am hoping to be able to consult my services out to other businesses as a result.

For those that are interested in following along, here is the full tech stack and toolset that I'll be using:

• Erlang - A fantastic cross-platform functional programming language that has some amazing features.
• Webmachine - A HTTP toolkit which sits on top of Mochiweb that makes it easy to build well-behaved HTTP applications.
• Nitrogen - An Erlang-based framework that makes it easy to build websites.
• Riak or CouchDB - Both of these amazing pieces of tech are potential candidates for the back-end storage. I'm not yet sure which one I'll go with.
• jQuery - A great JavaScript library for the front-end.
• VIM - My favourite text editor
• Xubuntu - Ubuntu Karmic Koala with XFCE as the window manager.
• Mercurial - My favourite version control system.
• Trac - A project tracking tool.
• VirtualBox - My choice for virtualisation. I tend to run Windows 7 as my primary OS, so most of my dev will be in a VM. When I get my desktop machine back up and running (with all three monitors!) it'll most likely multiboot Win 7 and Xubuntu.
• Google Wave - I'll be using this for communications with some really switched on people in the Erlang community who have kindly offered to help me with questions and whatnot specific to some of the areas of tech I've mentioned above.

During the course of my blogging/learning I'll be focussing on Webmachine, Riak/CouchDB, Erlang and Nitrogen. All the other tools will probably get mentioned along the way, but the primary goal is to focus on these things.

I'm really excited! I'm currently in the process of documenting my goals and the design for the main application. Once that's done, I'll get started with the fun stuff. I've got a lot to do and it should be a fun ride. I hope you enjoy following along!

• 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!

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!

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!