The implementation is basically one switch statement from a C/Java/Ruby/Groovy/Python perspective. Ruby and Groovy coders will recognize that the return value of the function is the value of the last expression evaluated. So an if statement returns either the value of the true expression or the value of the false expression.

When conditional logic returns values like this, there is no need to use a stack variable to store a return value.

A quick introduction to some of the functions used in the code:

• (if): Aside from returning its true/false expression result, no major difference than Java.
• (cond): Basically a switch statement, returning a value just like (if)
• (let): Defines and initializes "variables" which are immutable.
• #(): This defines an anonymous function. Believe this is a macro for (fn).
• #{}: This defines a set data structure; unordered and no duplicates. Also see the (set). function
• {}: This defines a map data structure, populated with unordered key/value pairs. Bonus: (map key) AND (key map) both return the value for key in a map.

With some minimal descriptions listed, let's dig into the code:

When judging a hand it's critical to know how many of each suit are present AND how many of each value are present. One way to model this is to build histograms for suit and value.

The implementation behind that is not an easy read (probably because it's not great Clojure). Basically this code iterates over the pool of attributes (suits or values) and uses (conj) to aggregate maps into one big map. In the middle a filter function finds all cards matching the current property and then the total number is counted up.

Only one more helper method to go. This method determines whether the hand is a straight, whether all of its cards have consecutive values. The approach taken was a little odd. An array of all possible straight values is built and then segmented into overlapping hands. For example, the first two arrays would be [ace, two, three, four, five] and [two, three, four, five, six]. Each of these possibilities is matched against the hand, using Clojure's facility to compare sets easily.

(some) is a function which returns true when its filter function returns true for any of the collection items it examines.

After all that, here is the hand judging function. It's basically a few local "variables" and a switch statement. Some additional conditional logic appears inside the switch statement as well. This is required to determine whether a hand with three of a kind is a full house (are the remaining cards a pair?).

In the near future all this code will be cleaned up and moved out to BitBucket. Ideally some basic chip tracking and logic would be added so you could actually play poker from a REPL. That's probably much more difficult than it seems, but hopefully this has been useful so far. Please don't hesitate to contact me (goof at foognostic dot net) with any questions!

First, let's create a poker namespace to work in and then define some basic constants as keywords in sets.

Next, let's "define a class." I'm quoting that because a struct in Clojure is just a map with some keys to be expected.

Next we actually need, you know, a full deck of cards to shuffle. This was harder than I expected. At first I tried two loops, first iterating over suits and then values. This resulted in a list of ... four lists of... thirteen cards.

Unfortunately (map) didn't work as hoped. I decided to try a list comprehension. This was something I remembered from using once in Python. It turned out to be exactly what I needed:

This yields a lot of text, so let's inspect the output programmatically. (filter) is a function which takes a function and a list; the output consists of the list items for which the function inspects and returns true.

Now that we have the deck straightened out, it's time to shuffle it. I'm getting the feeling there is a beautiful mathmatical way to sort 52 cards involving permutations which would be easy to code functionally. Unfortunately I'm not there yet on either side. This implementation is really crude.

For example, this random-card implementation instantiates java.util.Random each time it is called (and without a seed value). (nth) returns the nth item of a sequence; (seq) is being used here because deck is a hashmap, which doesn't support ordered extraction.

Continuing on with the vulgar display of crude code... here is the shuffle method:

Let's ignore the lack of comments of any sort here. This implementation uses variable arity. That means when the function is passed one parameter the following code will run:

And when two parameters are passed the following code runs:

This is a feature of Clojure. I kind of like it. The way recursion was used here the variable arity made the code simple to read. I probably could have used (recur) for a very similar amount of code, but the dogs had to go out.

So the second chunk of (shuffle) picks a card at random from the unsorted pile, uses (conj) to include it in the sorted pile, uses (disj) to exclude the picked card from the unsorted pile, and then GOTO 10.

And now, with lots of gory code I'm not proud of, here is my first hand of 5 card draw:

Wow, three of a kind. It's almost as if I programmed in a "be nice to Seth" bit somewhere...

The team behind the Groovy programming language took a look at the ternary operator and realized something. Developers frequently use it during a variable assignment to take the value of the test expression when not null, otherwise take the value of the "else" expression. A new operator was added to the language to support exactly this usage and was dubbed the Elvis operator.

The Scala programming language does not have an Elvis operator, but Daniel Spiewak posted an impressive implementation.

This led me to thinking about defining the Elvis operator in Clojure, my current spare-time language. Clojure is a Lisp hosted on the JVM (with some plans for the CLR). This was a fun exercise but I make no claims that this is a good way to be Elvis-ish in Clojure.

First, here's a naïve implementation:

It works:

But it always evaluates the "else" expression. FALE.

So that's bad. Let's make a macro version. This should prevent the expressions from being evaluated before Elvis gets a chance to do his thing:

To verify this, I added

before the (if-not) form and called the method and the macro again:

So it was easy to avoid evaluating things by simply making the function into a macro. I'm sure there are many things above and beyond what I am doing here, but it was a nice experiment.

My last exploration of Clojure taught me to avoid for loops while splitting a string into overlapping character pairs. This exploration into Clojure was going to generalize that code to emit any width of overlapping character chunks.

Here is the old, inflexible code:

A quick summary of that:

• Defines a function named split-bigrams
• It accepts one untyped parameter, here named text
• The method body contains one function call to map, which takes three arguments: one anonymous function taking two arguments, and two sequences.
• map pulls one character from each sequence and passes them to the anonymous function, which turns them into a string

The trick? Two iterators over one string, with the second iterator starting at the second character. Then just iterate over the lists and mash the items together. Problem is, to get character triplets I would need a third iterator starting at the third character. That's no way to live! Just a big fat FALE WHALE.

I desperately hoped that macros could somehow magically generate all the lists for map. I like macros. Clojure likes macros! My poor little train of thought couldn't scale this mountain. I thought I could, I thought I could, but between tucking in kids and dog walks I was too tired/busy. So I gave up and looked for another option.

Howzabout recursion? I spent several days rewriting variants of this:

This prints the values I want... it just doesn't put them into a collection! I feebly tried incorporating map and reduce. Not sure how many infinite loops were created and cancelled...

Finally, I decided to read the source code of Clojure to see how they do things like this. That was a great decision. core.clj is clean, clear, and full of goodness. Somewhere in there I found recur being used how I needed it: do something to a collection, call itself with the output until the input was exhausted, and return the aggregated output:

This is probably a basic recursion pattern. I feel a little silly taking so long to figure it out. Just a little silly though, as the coding I do for a living doesn't encourage recursion.

At this point I am almost convinced that Clojure is the optimal language for me to grow as a programmer. Lisp itself is a low-level high-level language; you have to really understand how things are going to work, but not worry about things like garbage collection. The "homegrown VM" and "no library" problems just don't exist in Clojure. The APIs are clean and clear. Best of all the dogma is minimal and pragmatic. HUZZAH!

Unless something awesome happens the physics portion of the challenge will be tackled last, if at all. And I still intend to use Clojure.. I have a little ant based environment to assist.

If anyone is interested in joining team Foognostic, shoot me a mail at tbbs@sbbtabfgvp.arg, unless rot13 ain't your thing. Don't wait though, the contest ends June 29th at 14:00 CDT!

Another step needed to generate the cosine similarity for two strings is to create a frequency histogram, or how many times each character pair occurs in a string. This is a pretty good fit for a hash map, where the keys are the character pairs, and the values the occurrences.

Here was my initial try. This code meant to do well... but went far, far away from where I wanted. Let's take a detailed look at my failings:

What I wanted: a map like this => {"b" 2, "a" 3}. What I got was three hash maps, each with one key/value pair => ({"a" 1} {"b" 2} {"a" 3}). The intent was to use map to iterate over the sequences, and use assoc to put the key and value into one hash map. And now, for the parade of errors...

1. Use the zipmap function to build hashmaps like this: (zipmap ["a" "b" "a"] [1 2 3]) => {"b" 2, "a" 3}
2. Variables in the let block cannot be changed...
3. ... but I really needed to update the hash map defined in the let block.

Rather than continue to stew uselessly I used Emacs to hop into the #clojure IRC channel. A wonderful person suggested the reduce function; I'd used it once in Ruby where it is best known as inject. I'm going to skimp on my description of reduce a little since that article is so well done.

reduce iterates over a collection like map, but it passes a mutable context to each callback. The return value of reduce is the final value of the context... essentially. I am still coming up to speed on it obviously.

Anyhow, enough yammering. Here is reduce in action:

Key points:

• [l_histo r_histo] -- these are the arguments to the dot-product function.
• (fn defines an anonymous function.
• (get gets the value for the specified key from the specified map, returning the final argument when the key is absent.
• 0 is the default value for product
• (keys returns the keys of the specified hash map
• Clojure really wins a lot by delegating to Java. This happened for free: (Math/sqrt 100) => 10.0

So, reduce is a critical step for people coming from imperative programming languages looking to do basic things with collections.

I'm trying to settle on a specific task to accomplish when learning a new language. Something concrete but still a little academic... implementing cosine similarity using character bigrams isn't much code, but it covers enough bases to be useful.

Part of the process involves splitting a string into overlapping character pairs.

Bad old me instinctively thinks "for loop".

Good new me thinks... bad old me probably has it right. But it doesn't feel very Clojure-y. This solution is a little more Clojuriffic, probably still a long shot from idiomatic:

Bad old me (BOM) would have iterated over the string using a for loop with an index variable, cycling length - 1 times.

Good new me (GNM) had to take a different approach. I converted the string into two sequences; the first was just the string, but the second was the string minus the first character.

The (map) function takes a callback and a number of sequences. The callback function gets the nth element from each sequence, and the output from the callback is collected and returned by (map). I don't have to specify a length or repetition count, as (map) stops processing when any of the collections run out of data.

This hasn't taken a lot of time, but more than I like. It has taken A LOT of patience, energy, and focus during that time. But I like finding new ways to solve problems. Now I have a new tool in my nerdbelt, one that pushes the for loop back a little bit.

Last year I installed Trac to help organize things and that was fun, but this year I think BitBucket is the way to go. More features that someone else maintains -- woo!

This year another Foognostic solution will be submitted, barring unexpected events that weekend. For the sake of trying to look cool I will be using Clojure, mostly as an exercise to really explore a Lisp. I'm more familiar with Emacs Lisp, but Clojure is sitting right on top of all those featuriffic Java APIs.

The countdown timer stands at a little more than two weeks. That should be enough time to come up to speed, right? ... or have I just uttered famous last words?

In any event, watch this space for updates!

• The ICFP 2009 contest site.
• The ICFP 2008 task description.