19 July 2011


We're now maintaining a repository for "SpecialKEval" over on github.

28 April 2011

Jogguru on Amazon

Jogguru is now available for Android via the Amazon app store, check it out!

14 February 2011







グラフィックス: Ray.

Jogguru iOS

Introducing Jogguru, the fast and fun way for learners of all levels to boost their knowledge of Japanese! Now available on the iTunes Store for the iPhone, iPod Touch and iPad on iOS3.0 and up.

✓ Hunt for hiragana words by connecting up adjacent letters
✓ Score points for words with 3 or more letters and complete achievements!
✓ Instant kanjis and English translations
✓ Features all JLPT N1-N5 vocabulary
✓ Share your words and scores with your friends on Facebook, on Twitter and by e-mail
✓ Post scores to Game Center and see how you progress with your friends!
✓ Tap て for て, again for で, and again for て. Cycle つ → づ → っ → つ
✓ Shake for new game
✓ No advertising

Developed in association with cooori: the future of language learning.

Graphic design: Ray.

09 February 2011

A Texas Hold'em 7-card evaluator: Part II.

(Part I is here.)

There are further significant performance gains to be had by exploiting thoughtful choices for the suit values.

We assign the integer values 0, 1, 8 and 57 for spade, heart, diamond and club respectively.

Any sum of exactly seven values taken from {0, 1, 8, 57} is unique among all such sums. We add up the suits of a 7-card hand to produce a "flush check" key and use this to find a precalculated flush suit value (in the case we're looking at a flush) or otherwise a defined non-flush constant.

The extraordinarily lucky aspect of this is that the maximum non-flush key we have, 7825759, is a 23-bit integer (note 2^23 = 8388608) and the largest suit key we find, 57*7 = 399, is a 9-bit integer (note 2^9 = 512). If we bit-shift a card's non-flush face value and add to this its flush check to make a card key in advance, when we aggregate the resulting card keys over a given 7-card hand we generate a 23+9 = 32-bit integer key for the whole hand. This integer key can only just be accommodated on a 32-bit system and yet still carries enough information to decide if we're looking at a flush and, if not, to then look up the rank of the hand.

We can therefore typically (about 97% of the time for a random hand) decide the rank of a 7-card hand with no more than six additions, as opposed to twelve (six for the flush check and another six for the rank key), extracting a performance gain in excess of 30%.

This optimisation features in Poker Ace 1.1 and later versions. It has also been implemented in the Objective-C, Java, C++ and Python versions of the open source code.

For what it's worth, with this optimization and some inlining I've seen the C++ version clock over 250M evaluations per second on my 2010 MacBook Pro.

03 December 2010

Poker Ace 1.2

An upgrade to Poker Ace 1.1.

This release is offered in Simplified Chinese in addition to English, French, German, Japanese and Thai.

22 November 2010

Open problem

If you have the time to waste, we invite solutions to the following problem:
"Can our algorithm for evaluating 7-card hands be substantially accelerated without increasing the total memory footprint, and/or can the total memory footprint be substantially reduced without slowing the algorithm at all? Or is there another evaluator which is substantially faster with no greater memory footprint or has a substantially smaller memory footprint and is no slower? 
The code must be capable of running on a 32-bit system. All look-up tables must be quick to load prior to evaluation. If we wish to try to quantify all of this, algorithms written in Objective-C, C, C++ or Java that are capable of evaluating 50 million or more randomly generated 7-card hands per second on a top-end early 2010 laptop with a total memory footprint of at most 1Mb, or algorithms that are likewise capable of evaluating say 300 million or more 7-card hands per second with a total memory footprint of at most 10Mb and whose look-up tables (if any) take no more than 5 seconds to load in either case are currently of interest to me. We're particularly interested in reducing the memory footprint."
As far as we're concerned, a 7-card evaluator is formally a (mathematical) function from the set of 7-tuples of pairwise distinct integers modulo 52, such as (0, 51, 4, 12, 8, 16, 20) but not (0, 51, 22, 22, 3, 41, 32), to the natural numbers such that the greater the image, or rank, the better the corresponding Texas Hold'em poker hand and two hands of equal rank always draw. The 7-tuples must not be assumed to be sorted although if you really wish a candidate algorithm is welcome to carry the overhead of sorting its input.

The algorithm may assume that the input is valid, that the responsibility for verifying this rests with the caller. The algorithm must not remember any aspect of its previous evaluations but this is something that can be added at a later stage. The algorithm can be regarded as a block of code, and need not be delayed by making any function or method calls and need not be thread-safe.

All related correspondence, regarding queries and solutions, is welcome here.