Dynamic Huffman


The adaptive Huffman algorithm as described by Vitter had three constraints that were compelling to relax.

The first is the size of the table.  The size of the table was constrained based on initial knowledge of the set being compressed—typically constrained to 256 for a single byte alphabet size.

The NotYetTransmitted sequence never adjusted its weight based on its own frequency so clusters of new characters would not benefit from reduced sizes of this sequence.

Once new characters become rare, it makes sense to reduce the NotYetTransmitted weight and therefore demote it farther down the Huffman tree.


The source for these changes can be found on GitHub. The implementation is C#. C/C++ implementations will be added in the future.
Continue reading

Two Responsibilities in the .NET TPL Scheduler Class

I like parallel programming.  Most of my experience comes from developing on Windows in C/C++ and C#.  I haven’t yet had the pleasure of doing so functionally (which I plan to correct).

I prefer task/job based parallelism using threadpools rather than explicit threads performing a suite of tasks (such as FIOS or Kinect).  I could delve into this further, but that is not the purpose of this post.

The Task Parallel Library hinted at an opportunity to build logic I have always wanted with a job based implementation.  I wanted to be able to define my own schedules for task execution.  Unfortunately there is a flaw.

The Scheduler class has two responsibilities.  The Scheduler class not only handles scheduling of tasks, but their execution as well.  Combining these two responsibilities inhibits scheduler composition beyond inheritance and encapsulation.  Furthermore any external libraries that create tasks based on their own schedulers cannot have the scheduling of their tasks altered by any other schedulers.

Continue reading

Green Programming – Intimate Affairs with the Wall

I have been thinking about green programming for the past six months.  As I see the battery on my phone die over and over, and now the iPad too.  I can’t help but think: what is using up all the power?

Miniaturization, more efficient components, and better batteries can go a long way.  Unfortunately this kind of improvement sometimes mean we use our phones, tablets, and other devices more as they become faster and easier to use (Jevon’s paradox: http://en.wikipedia.org/wiki/Jevons_paradox).

I believe there are opportunities to improve hardware utilization at the software level by minimizing unnecessary use of hardware.  There are some barriers however to achieving this and the first is measuring the energy cost.

Continue reading