Matthew Podwysocki's Blog

Earlier this week, I was challenged on Twitter to give a practical example of currying in C#.  This was a great question, because outside of the normal add and multiply people tend to do, there isn’t much out there.  This was also a question brought up as I spoke at the Philly.NET Code Camp this past weekend as well about good practical examples.  In this post, I hope to use one example that I used during my talk on Functional Programming at the Continuous Improvement in Software Conference in Austin last October. 

Continuing with our back to basics series which started last month with an introduction to Test Driven Development, this month we are covering Refactoring.  The discussion will be led by George Dinwiddie, a software development consultant, coach and a found of Agile Maryland and the Maryland Chapter of the APLN and we’re lucky to have him.  As with before, these are quite interactive discussions, so participation is highly encouraged.  

As part of my dive into the Collective Intelligence series, I’ve found myself many times taking code that was written in an imperative coding style and moving it towards a pure functional style with immutable data structures instead of ones, the application of functions instead of for loops (which is an upcoming post), and the elimination of state.  This was also a major part of my talk this past weekend at the Philly.NET code camp on Functional Programming in .NET.

Tonight for the Real World Haskell Book Club, Paul Barry and I decided to dig through the Programming Collective Intelligence book as some good hack projects as we dive deep into the language features.  As you may have noticed both here on my blog and on Twitter, I have been posting a lot of these samples in F# and refactoring along the way.  By taking the Python code and rewriting it in Haskell gave me better insight into the Haskell way, but also refactoring opportunities for my existing F# code.

In my recent adventures around Collective Intelligence, I took many code samples that have been written in an imperative coding style and moved them to a more functional style.  With this move sometimes brings some leaps in thinking in which you have to step back and break down the problem into smaller parts and come at it from a different direction.  Today, I’ll go over two examples in which we’re going to transpose a map from an imperative style using mutable dictionaries to one that is written in a functional style with immutable maps.  There is a lot of focus on this blog around immutability and functional composition as they are key to functional programming.

In our last post in the series, we discussed a way to get which items I should check out next through the use of the our similarity algorithms which included the Pearson Coefficient, the Euclidean Distance and Manhattan Distance among others.  This time, let’s take another approach through the use of the Slope One family of algorithms.

Previously, I went over some formulas on how we can calculate the similarity between our items using the Manhattan Distance, Chebyshev Distance and the Jaccard Coefficient.  Then we were able to plug in our given similarity function to another function which then gets the top matches for our given preferences.  This time, instead of determining which critic is more suited to my tastes, instead, we could instead rate which items should be viewed.

In the previous post covering Functional Programming and Collective Intelligence, I left off with the discussion of the two different algorithms for measuring similarity, the Euclidean Distance and the Pearson product-moment correlation coefficient.  The Programming Collective Intelligence covers these two formulas in depth, yet they are not the only two that are capable of performing the task.  Let’s briefly cover some more of those before moving onto ranking the critics and recommending items for a particular user.