## Fractional Bits (Part II)

March 4, 2014

In a previous post, we started discussing the subject of encoding values using fractional bits. This is quite counter-intuitive as we usually think that encoding asks for whole bits, furthermore that we think of bits as being essentially atomic—unsplittable.

However, bits can be fractioned, helping us devising efficient encodings, something not unlike a primitive form of arithmetic coding, for a variety of data. Let’s consider a simple case that illustrates the principle: encoding the date.

## No post today

February 25, 2014

Well, obviously, except this one. A bit too busy right now to mind the blog, I’ll be back on track for next week.

## Universal Coding (part III)

February 18, 2014

In Universal Coding (part II), we explored the idea of variable length codes that encode integers of any magnitude in $O(\lg n+\lg\lg n)$ bits, but the encoding requires (somewhat) complex arithmetic, and we concluded that sometimes, it’s better to use a simple code that sacrifices some coding-efficiency in exchange for machine-efficiency. Let’s now look at one of those, MIDI VLQ and how we can make it a bit better.

## Around The World

February 11, 2014

Intuition does not always help us getting mathematical results right. Au contraire, some very simple results are blatantly counter-intuitive. For example, the circumference of a circle of radius $r$ is given by:

$c(r)=2\pi r$

Let’s say we’re interested in the Earth’s circumference. The radius $r$ is something in the order of 6400 Km, so $c(6400\text{ Km})\approx 40200\text{ Km}$. Now, what happens to the radius if we add just 1 meter to the circumference? You’d expect the radius to vary infinitesimally. Wrong!

## Short Pointers

February 4, 2014

One good thing with 64 bits addresses, is that you can, in principle, use essentially as much memory as you want—the address space certainly exceeds today’s computers’ capabilities. One bad thing, especially when you create lots of objects and need plenty of pointers, is that 64 bits pointers are big. They use 8 bytes of memory. One or two pointers aren’t a problem, of course, but what if your data structure is a sparse graph, each node being mostly pointers, and that you need to create a very large graph?

One solution is to use stretch codes, as I proposed a while ago, trading off precision of addressing for shorter pointers. However, unless you rewrite the memory allocator, the technique won’t play well with the default new. Another solution is to store just barely the number of bits (rounded to bytes) necessary to hold an address. Can we do this? If so, how?

## Enumerating Enums

January 28, 2014

Every programming language has its defects; sometimes large, sometimes subtle; often causing irks. One thing that has been bugging me for a while (and many others, as you can see if you use Google) is the impossibility of enumerating enums from basic language constructs. You just can’t. Using the STL (and C++ 2011), however, you can have a somewhat elegant solution.

The solution I propose in this post is robust as it does not depend on the actual values of enums nor on that they can be mapped onto integers. We arrived at this solution (we being me and people on the ##c++ channel on Freenode, especially user “moonchild”) and I think it (almost) solves the problem of enumerating enums.

## Yet More __builtins

January 21, 2014

So last week we saw how to use some of GCC’s built-ins, this week, let’s have a look at how we can create our own, if need be. Say because you need to have access to some instruction and that GCC does not offer the corresponding built-in.

To do so, we’ll use a bit of the C preprocessor and GCC’s inline assembly extension.