Tuesday, 4 November 2014

Need to get In App Billing working for Android Lollipop?

Android 5.0, or 'L' requires explicit intents.

It appears that the bind service call fails on Lollipop because of an implicit intent being used instead of an explicit intent. I am not a Java developer, so this all sounded like voodoo to me. I looked about for ways to find explicit intents, found stuff about ResolveInfo, PackageManager, even found this nice website explaining what was wrong (but not literally how to fix it) Dealing with L Deprecations: bindService()

After a bit of hacking around, I finally found enough info in one of the stack overflow answers and implemented the final fix.

I feel like I hunted for quite some time before even knowing how to find out exactly what I needed to do to modify the google example code so that it worked. Here is literally how I have modified LicenseChecker.java in order to make it work in my project:

Saturday, 30 August 2014

Power/Order/Index - an intuitive approach

I think maybe I'm doing this just so I can have something to point people at when they are wrong on the internet... but still, some of you might find it useful to have a different perspective when you're messing around with powers. It's not rigorous, because I've forgotten how to write out proper deductions.

1) 2^2 = 2*2 = 4
2) 2^3 = 2*2*2 = 8
3) 2^4 = 2*2*2*2 = 16

4) 2^2 * 2 = 2*2*2 = 8
5) 2^3 / 2 = 2*2*2 / 2 = 4

sub (1) into (5)

6) 2^3 / 2 = 2^2
7) 2^3 / 2 = 2^(3-1)
8) 2^x / 2 = 2^(x-1)

sub 2 into x in (8)

9) 2^2 / 2 = 2^1
10) 2^2 / 2 = 2*2 / 2 = 2
10) 2^1 = 2

sub 1 into x in (8)

11) 2^1 / 2 = 2^0
12) 2^1 / 2 = 2 / 2 = 1
13) 2^0 = 1

sub 0 into x in (8)

14) 2^0 / 2 = 2^-1
15) 2^0 / 2 = 1 / 2
16) 2^-1 = 1 / 2

thus we see the reason why reciprocal (1/n) is also called ^-1

and now fractions:

17) 2^2 = 2 * 2 = 2^1 * 2^1 = 2^2 * 2^0
18) 2^(2-x) * 2^x = 2^2
19) 2^(n-x) * 2^x = 2^n

sub 1 for n in (19)

20) 2^(1-x) * 2^x = 2^1

sub 1/2 for x in (20)

21) 2^(1/2) * 2^(1/2) = 2^1

which explains why the square root is called ^(1/2)

for any positive value (a), (a^(1/2))^2 = (a)

to specify the cube root x of a (x*x*x = a) we need to divide the power into three (x = a^(1/3))

to specify the change in pitch of a semi tone, we know that the pitch doubles per octave, and that there are 12 notes in every octave, that's pitchchange = 2^(1/12)

If you have a game and you want something to increase in power, then you specify how much you want it to be finally at, and use power of 1 over the number of steps to get there to do it smoothly.

price of base thing (b) goes to price of super expensive (x), over four steps
price (step) = b * (x/b) ^ ((1/4) * step)
price (0) = b * (x/b) ^ ((1/4)*0) = b * (x/b) ^ 0 = b * 1
price (4) = b * (x/b) ^ ((1/4)*4) = b * (x/b) ^ 1 = b * (x/b) = x
price (2) = b * (x/b) ^ ((1/4)*2) = b * (x/b) ^ (1/2) = b * sqrt(x/b)

Monday, 9 December 2013

Looping back and forth, unsigned ranges.

I just saw this post about unsigned loop problems on Eli Blendersky's blog:


In it he tells a tale of woe with unsigned values not being easy to test when doing negative for loops, but one trick that I've used numerous times for checking ranges applies here too. I've marked the changes.

Positive loop:
for (size_t i = 0; i < SIZE; ++i)

Negative loop:
for (size_t i = SIZE-1; i < SIZE; --i)

What? Ah, unsigned types are unsigned, so -1 is really big. Cool. Go use this in your code. Ranges are handled the same way:

if ( (unsigned_value-RANGE_MIN) < (RANGE_MAX-RANGE_MIN) )

Wednesday, 4 December 2013

A Primer in Compressing things.

Encoding into bits

If you want to store a number in a computer, it has to be stored as a sequence of bits. These bits can be used to represent large numbers, but the number space represented by whole number counts of bits is always a power of two.

  • 1 bit = 2 options, or a range of 2 values = 2^1
  • 2 bits = 4 options, or a range of 4 values = 2^2
  • 3 bits = 8 options, or a range of 8 values = 2^3
  • 10 bit = 1024 options, or a range of 1024 values = 2^10

As long as you can fit your value in under the number of options, you can encode it in that many bits. You can encode numbers from zero up to 1023 in 10 bits as it is under 1024.

For example :

  • to store a 7 or a 4, you could use 3 bits (b111 and b100) as 7 and 4 are both under 8.
  • to store a 10, you could use 4 bits (b1010), as 10 is under 16 (2^4=16)

Using your knowledge

You don't have to store your numbers starting at zero. As long as you know the minimum and maximum possible, you can shift the options into your needed range.

For example, I know that the number of legs on any table I own is always three or four. That's only two options, so I can store it in 1 bit. I store the number of legs as 3+(encoded bit)

  • for 3 legs, encode a 0
  • for 4 legs, encode a 1
I know that the valid temperature range on a piece of equipment ranges from 45 to 55 degrees, so I can encode it as a range of 11 (so, really 16 as that's the smallest power of two above 11), so I encode the data at 45+encoded value
  • for 45 degrees, encode a 0 (b0000)
  • for 50 degrees, encode a 5 (b0101)
  • for 55 degrees, encode a 10 (b1010)

Wasting space

What's noticable from the temperature example is that the values 12-15 are never used. We're wasting potentially usable bits, except they aren't whole bits, so there is no obvious way of using them. How many options can you store in half a bit?

Using different bases

The reason for the waste is the number space being used. If we restrict ourselves to the number space of the computer, we make encoding and decoding easy for the CPU, but we waste storage space. If we use a base other than 2, we can pack the data really tight. In theory, it's possible to pack your data so that you only waste less than one bit of data.

A simple example is in order. Assume you have a list of booleans with an additional unknown state. These tribools come up frequently so this might be of practical use to some of you. Tribools require three options. How many can you store in a normal 8 bit byte? Using base 2, you have to use two bits per tribool, meaning that in 8 bits, you can store 4 tribools.

But 8 bits can store up to 256 different options, and if you slice it differently, you can pack more tribools in. Tribools (3) stored 5 times has less options than the bools (2) stored 4 times.
  • 2^4 = 256
  • 3^5 = 243
To store the tribools, we merely need to generate the "option" of that set of 5 tribools, and then encode that value instead. The trivial example is all tribools but the first are zero:

  • 0,0,0,0,0 => 0
  • 1,0,0,0,0 => 1
  • 2,0,0,0,0 => 2
what is interesting is what happens when we add to the other elements
  • 0,1,0,0,0 => 3 (1*0 + 3*1)
  • 0,0,1,0,0 => 9 (1*0 + 3*0 + 9*1)
  • 0,0,0,1,0 => 27 (1*0 + 3*0 + 9*0 +27*1)
  • 1,2,1,2,1 => 151 (1*1 + 3*2 + 9*1 + 27*2 + 81*1)
We multiply out the number by it's base. Element 0 * 3^0, element 1 * 3^1, element 2 * 3^2, element 3 * 3^3, and element 4 * 3^4. Now we can store 5 tribools in 8 bits because we are actually storing a number from 0 to 242 in 8 bits, but that number can be decoded into 5 different 3 option values. Decoding is handled by taking modulus and then dividing to remove that part of the encoded value.
  • 151 % 3 = 1
  • 151 / 3 => 50
  • 50 % 3 = 2
  • 50 / 3 = 16
  • 16 % 3 = 1
  • 16 / 3 = 5
  • 5 % 3 = 2
  • 5 / 3 => 1
  • 1 % 3 = 1
Decoding is just like figuring out the time of day from the number of seconds elapsed.

Probability of a value

Apart from knowing the range, we can also reduce the storage used by using our knowledge of how likely a thing is. This is known as probabilistic compression, where the chance of a value being selected affects how many bits it uses. The one you learn about first is Huffman coding, but an easier to swallow example might be useful.
Let's say we have a game about sewing seeds in a garden full of plots, and letting them grow. If I am trying to compress the type of seed planted in a plot, but most of the plots are empty, I can say that the most common type of plant is zero, the NULL plant. I can encode the plot data with only one bit for whether there is a plant, and then the actual plant type if there is. If we assume 8 types of plant, then:
  • no plant => (b0)
  • plant of type 4 (b1100) (bit 1 set because there is a plant, then bits 2-4 set as the plant type.
If the garden is empty, then the compressed sequence takes as many bits as there are plots. If all the plots are full, then the compressed sequence takes as many bits as there are plots more than a naive solution (actually, if there are 8 types of plant, then it's actually the same for a naive solution, as 8 types of plant means 9 options, which would require another bit as the lowest power of two greater than or equal to 9 is 4)

It's possible to encode like this automatically, generating the probability of each option, then generating a binary tree which defines how you encode and decode values. This is Huffman coding, and is very useful when you have no domain knowledge.

Compressing to less than 1 bit

If you have probability information, Huffman coding can be great, but it's not quite as efficient as it can be for the same reason why we found that we could save storage by changing the base when compressing the tribools. Huffman must encode at least one bit for even the most common data. As an example of how we can do better, let's compress a garden with an additional bit of information: whether there is anything in a whole row of plots.
  • no plants in row => (b00)
  • no plant in plot => (b01)
  • plant of type 4 => (b1100)
What happens here is that the save takes up two bits per row rather than 1 bit per plot. That might be a significant saving. You can probably think of many other ways to mark larger areas of empty data too. Gridding it out at a lower resolution, then setting bits for all cells that contain any data, for example. With domain knowledge comes much better compression. Huffman coding isn't readily adaptable to wildly biased data, but it can be if you give it more symbols to work with. Therein lies the tradeoff. If you have to send a large palette of symbols, does the palette cost more to send than the data? Run length encoding can get down to less than one bit per byte on some data because runs of 128 bytes can be encoded in a single byte, or runs of millions can be encoded in 32 bit RLE encoders.

Domain knowledge

Really powerful compression comes from understanding the probabilities and rules of data being compressed. If you have a look at the lossy compression algorithms, this becomes more easy to understand. In lossy compression, you have domain knowledge of what humans can and regularly perceive. If the computer is able to analyse the data and find the information and only compress that, then it can reduce a very large raw file down to something significantly smaller.

Let's compress our garden again. This time, we know that the garden cannot have any plant directly next to another plant.
  • no plant in plot => (b0)
  • plant of type 4 => (b1100)
  • plot where plan cannot exist because of following rules and relying on already encoded data => (b)
Yes, zero bits. Zero bits to encode the fact that a cell is empty when it's not possible to have a plant in it. It makes sense because the actual fact that the cell is empty was already encoded by the plot encoding a plant type. It's not really zero bits, it's 1/5th of a bit really as the plot with a plant in it defines the state for 5 cells. (the one following, and the three on the next row.

There are often many places where rules give you information for free, you just need to look out for them.

Friday, 30 March 2012

Bezier Curve template

Sometimes you just want some simple code you can drop in to do bezier curves:

Templated Bezier function:

static inline float CR40( float t ) { return 0.5f*(2*t*t-t*t*t-t); }
static inline float CR41( float t ) { return 0.5f*(2.0f-5*t*t+3*t*t*t); }
static inline float CR42( float t ) { return 0.5f*(4*t*t+t-3*t*t*t); }
static inline float CR43( float t ) { return 0.5f*(t*t*t-t*t); }
template<typename T>
T CRBez4( T a, T b, T c, T d, float t )
return CR40(t) * a + CR41(t) * b + CR42(t) * c + CR43(t) * d;


Well, now you can. Here's some rather old code I found, and recently reused.

Thursday, 24 November 2011

Existence checks

Let's say you have a large table of data, lots of rows with a few columns. You know that every row is unique because that's a basic feature of your table, no duplicates. There are only a few instances where non-unique elements are a good idea in tables, so we're going to ignore that corner case for now.

Let's look at what we have with an example:

Find out if Bob is the leader of team A
Name Clan Rank
alice team A leader
bob team B private
bob A team leader
charlie A team private

We can see that we can't just check for any one column and return on success, this is much like checking for a string, we have to check every element before we're sure we have a match. You could maintain the table's alphabetical order, reducing the string queries down to only the rows that match "bob" or "team A" (dependent on which column you sorted by). If you walk through the table, you have to string match at least one column.

But, we know that the table is made up of unique elements. There will be only one row returned if at all, so that makes this table a set. It's the set of Name Clan Rank associations that are known to be true. There are a very large number of potentially true values in this set, the product of the list of all potential names, all potential clans, and all potential ranks. Let's assume 4 billion names, 1 million clans, and 100 ranks. If we were to use a bit field to identify all the possible permutations, we'd not be able to fit the array into our computers. 400 trillion combinations would be quite literally, larger than we could handle. But sparse bit fields have better solutions than just simple array lookups.

What we've done is reduced the problem to its essential components. We're not looking for the row that contains the data, we're looking to see if the data exists. We don't want to access the data, only find out if it's in there. For this task, there are many solutions, but I'll just mention one.

I like hashes. My solution to this is to store the hashes of all the rows in an array of small arrays. I index into those small arrays by a small number of bits, the smallest amount of bits I can that differentiates the hashes enough that all the associated ones don't overflow the capacity of the cacheline sized mini arrays.

H1[bits0-n] -> index of array it should be in.

With this, I do one cache line load to get at the array of hashes, and if the hash is in there, then I can return that the row does exist. If not, then I can assert that it doesn't. And that's quick.

Monday, 31 October 2011


The static C++ keyword has multiple meanings based on context.

When used inside a function,

void foo() {
  static int i;
  printf( "%i", i );

it means that the declared variable is global in lifetime scope, even though only local to the function for reading and writing. Normally this is used to implement singletons.

When used inside a class,

class Bar {
  static void Baz() { ++foo; }
  static int foo;

it means that the declared member variable or function don't require a this pointer, and thus don't require an instance for operation. This can be useful for implementing class specific memory pools, or other types of class specific global state encapsulation.

When used in front of a variable or function,

static void Baz() { ++foo; }
static int foo;

it means that the global variable or free function are not destined to be used outside the current compilation unit, which reduces the number of symbols during link time, which can lead to better build times.

There is a missing functionality in that you cannot have a class defined that doesn't offer external linkage. You cannot specify that a class doesn't export its member functions. This is a shame as it guarantees that the link time of object-oriented C++ code gets worse, and you can't fix it.