May 27, 2014 1 Comment
After spending a couple of weeks working though the imperative code, I decided to approach the problem from a F#/functional point of view. Going back to the original article, there are several steps that McCaffrey walks through:
- Get a series of transactions
- Get the frequent item-sets for the transactions
- For each item-set, get all possible combinations. Each combination is broken into an antecedent and consequent
- Apply the frequency of each antecedent in all transactions
- If the frequency of the combination is greater than the confidence level, include it in the final set
For the purposes of this article, Step #1 and Step #2 were already done. My code starts with step #3. Instead of for..eaching and if..thening my way though the item-sets, I decided to look at how permutations and combinations are done in F#. Interestingly, one of the first articles on permutations and combinations on Google is from McCaffrey in MSDN from four years ago. Unfortunately, this article was of limited use because the code is decidedly non-functional so it might as well been written in C# (this was pointed out in the comments). So going to Stack Overflow, there are plenty of good examples of getting combinations in F# on SO and elsewhere. After playing with the code samples for a bit (my favorite one was this), it hit me that the ordinal positions are the same for an array of X size. So going back to McCaffrey’s example, there is only item-sets of 2 and 3 length. Therefore, I can hard-code the results and leave the actual calculation for another time.
I used a tuple to represent the antecedent array and consequent array values. I then spun up a unit test to compare results based on McCaffrey’s detailed example:
A couple of things to note about the unit test:
1) The rules about variable naming and whatnot that apply in business application development quickly fall down when applied to scientific computing. For example, there is no way that this
List<Tuple<int, int>> expected = new List<Tuple<int, int>>();
is more readable that this
var expected = new List<Tuple<int, int>>();
In fact, it is less readable. The use of complex data structures and algorithms force a different set of naming conventions. Applying Fx-Cop or other framework naming conventions to scientific programming is as useful as applying scientific naming conventions to framework development. If it is a screw, use a screwdriver. If it is a nail, user a hammer…
2) I don’t have a good way of comparing the results of a tuple of paired arrays for equivalence – there is certainly nothing out of the box in Microsoft.VisualStudio.TestTools.UnitTesting. I toyed (briefly) with creating a method to compare equivalence in arrays but I did not in the interest of time. That would be a welcome additional to the testing namespace.
Sure enough, running the unit test using McCaffrey’s data all run green.
With step 3 knocked out, I now needed to determine the frequency of the antecedent in the transactions list. This step is better broken down into a couple of sub-steps. I used McCaffrey’s detailed example of 3,4,7 as proof of correctness in my unit tests:
I need a way of taking the antecedent of 3, and comparing it to all transactions (which are arrays) to see how often it appears. As an additional layer of complexity, that 3 is not an int, it is an array (all be it an array of one). I could not find a equivalent question on StackOverflow (meaning I probably am asking the wrong question), so I went ahead of made a mental model where I would map the TryFindIndex function against each item of subset and see if that value is in the original set. The result is a tuple with the original value and the ordinal position in the set. The key thing is that if the item was not found, it returns “None”. So I just have to filter on that flag and if the result of the filter is greater than 1, I know that something was not found and the functional can return false
In code, it pretty much looks like the way I just described it:
And I generated my unit tests out of the example too:
With this supporting function ready, I can then apply it to an array and see how many trues I get. That is the Count value in Figure 2 of the article. Seq.Map fits this task perfectly.
And the subsequent unit test also runs green
So with this in place, I am ready for the next column, the confidence column. McCaffrey used the numerator of 3 which is shown here:
So I assume that this count is the number of times 3,4,7 show up in the the transaction set. If so, the supporting function ItemSetCountInTransactions can also be used. I created a unit test and it ran green
So the last piece was to put it together in the GetHighConfRules method. I did not change the signature
Note that I did add a helper function to get Combinations based on the length of the array
And when I run that from the console:
So this is pretty close. McCaffrey allows for inversion of the numbers in the array (3:4 is not the same as 4:3) and I do not – but his supporting detail does not show that so I am not sure what is the correct answer. In any event, this is pretty good. The F# code can be refactored so that all combinations can be sent from an array. In the mean time, here is all 43 lines of the program.
Note how the code in the GetHighConfRules function matches almost one for one to the bullet points at the beginning of the post. F# is a language where the code follows how you think, not the other way around. Also note how the 43 lines of code compares to 136 lines of code in the C# example –> less noise, more signal.