Cheltenham Borough Council elections 2016-2021

The results of the 2021 CBC elections are in. An overview of the results can be seen on the CBC website. These tables are intended to help show the change in vote between 2016, 2018 and 2021. Note there was a change of boundaries in 2014, and so this was not included. The differences displays are in percentage points.

One of the biggest features of it was the increase in vote in the Green Party – although no wards were won. They stood in every ward except Prestbury:

The Conservative Party stood in every ward and made major gains in many:

The Liberal Democrats also stood in every ward. They generally lost out on vote share, but from a high base:

The Labour Party lost vote share in many wards, with the remaining being around equal to 2018. The exception was Swindon Village, where they did not stand in 2018.

Ramanujan’s “On Question 330 of Prof. Sanjana”

I have written an article that attempts to explain an interesting paper of Ramanujan’s. In this paper he evaluates certain infinite series. The technique is quite pretty in my opinion, and so I hope it is enjoyable.

Download it here.

Keypads with paint on the buttons

Near my home there is a door that is opened by a keypad. I know that it uses a four-digit code, where the order matters, but I don’t know what the code is.

An example of a keypad

When I walked past it the other day I noticed that there were blue fingerprints over three of the numbers on the keypad, but I did not look very closely and therefore there may have been four. If there were only three numbers with fingerprints on them then I would infer that one of the numbers in the code was repeated.

I wondered this: If I wanted to guess the code as quickly as possible would I prefer that there were three digits or four digits with paint on them?

Intuitively, most people (at least in my informal survey) seemed to expect that it is more constrained when there are only three digits, and so there are fewer combinations. After all, if there was only one blob of paint, so all the digits were the same, then there would be only one possible combination, so you may expect that each digit adds more freedom and thus more combinations.

In fact, this is not the case, and you would be better placed to guess the code if you knew it had four different digits.

The number of combinations to try if you know there are four different digits is of course .  If instead it is known there are only three different digits in the code then one of them is repeated. To calculate the number fo combinations, imagine choosing the two positions in the 4-digit code that are the same digit – there are 6 (i.e. ⁴C₂) ways to do this – and then choose which digit is the one which is repeated – there are 3 to choose from. The remaining 2 digits can be arranged in 2 ways – therefore there are  ways of doing it – 50% more!

I thought this was somewhat surprising.

---

In general, suppose the painted key-pad buttons are and the lock takes an M digit code. Of course, .

I think it is easier at this point to reason if we forget about locks and talk about functions instead. A function  is equivalent to a possible code if it is surjective. The code it represents is . As f is surjective every painted digit appears at least once, as is required.

We can therefore restate the problem as counting the number of surjective functions from {1,2,…,M} to {1,2,…,N}.

It’s easy to find out the number of functions if we drop the ‘surjective’ requirement – it is N_M. This number includes non-surjective functions – where the image of the function is some proper subset of {1,2,…,N} – as well. An inclusion-exclusion argument can be used to calculate the number of surjections.

In particular, define c_ito be the number of functions f from {1,2,…,M} to {1,2,…,N} such that at least i of elements of {1,2,…,N} are missing from the image of f (i.e. the image of f is at most N-i).C_i is then easy to calculate – choose the i elements to exclude (there are ^NC_i of them) and then assign to each f(j) one of the possible remaining N-i values. Repeat that for all M function inputs and hence:

Then, by inclusion-exclusion, the number of surjective functions is:

And hence the number of surjections, and hence the number of possible lock codes of length M using N different digits, each at least once, is:

This is related to Stirling Numbers of the Second Kind.

---

Not all keypads use four-digit codes. Looking online, most digital keypad locks can use between 1 and 12 digit codes. The following chart shows the approximate number of combinations that are possible if the length of the code is known (the number on the left-hand side) and the number of painted digits is known (the number on the top):

(Here a million is 10⁶ and a billion is 10⁹)

In reality, you may not know the number of digits in the code. Here is the number of combinations that must be tried if you know an upper-bound to the number of digits in the code:

---

A few additional thoughts:

• Many digital keypads also require a card to be presented and the code is associated with the particular card (i.e. is a PIN). Then you will need access to the card too.
• Most mechanical keypads, disappointingly, don’t actually require the digits to be entered in any particular order.
• There exist keypads that randomise the digits every time they are used. In addition, they can use special screens that can only be seen when looking straight at them.
• You may be tempted to think that the repeated digit, if there was one, might have more paint on it. However, it actually turns out that the first button pressed deposited much more paint on it than the others. By way of an example, if you are looking for a four-digit code and there are three paint splodges, then by identifying the first digit you reduce the 36 combinations to 12 (not 6, as the first digit may have also been the repeated digit).

Cheltenham Local Election Results 2016

In 2014 I wrote a long and detailed post on the Cheltenham local election results. I’m not doing it this year, as the council website has plenty of information now, but I have done a map of the results.

Yellow is Liberal Democrat, blue is Conversative, teal is People Against Beaucracy and gray is an independent who used to be a Liberal Democrat. This is only the 2016 results – the people elected in 2014 are still councillors.

 

April 2015 update of “Ini++ v1.5”

The Multimedia Fusion v2.5 extension manager now contains the April 2015 version of Ini++ v1.5. This is a small update that fixes a problem with one of the expressions.

This version is only available from the extension manager. My website no longer contains the latest version.

The description text for the latest version ends with the words “April 2015 build”, as shown below:

Cheltenham Local Election Results 2014

On 22nd May 2014 there were elections in Cheltenham, as in many other parts of the country, for local councillors. One councillor was up for election in each ward.

There are 20 wards in Cheltenham but one of the wards – Charlton Park – did not vote as one of the candidates died shortly before the election. The other 19 wards did vote but there were hardly any changes in terms of which parties were elected; Park went from Tory to Lib Dem and Leckhampton from an independent to Tory. In addition, some of the parties fielded different candidates. The full results are here.

The following picture shows the vote breakdown across the whole of Cheltenham (in the 19 ward elections which took place) for voters and for those eligible to vote:

N.B. “People Against Bureaucracy” are a local party.

The results of the individual wards are displayed visually in the following pictures. The colours are the same as in the pie-charts above.

As voter turn-out can be quite low, it is interesting to see what percentage of those people they are representing (i.e. those eligible to vote in the ward) voted for them.

N.B. The number in grey to the right is the number of spoilt ballots.

Only the Liberal Democrats and Conservatives stood in every ward. It is therefore interesting to ask what percentage of voters who could have voted for a particular party actually did? That is, the sum of the votes that a party as a proportion of the sum of the voters in the wards that they stood in. It looks as follows:

The map of councillors from this election hence looks as follows:

 

Each ward actually has two councillors of course, although only one of them were up for election at this time. The following map shows both the newly elected councillor and the other councillor which was not up for election this time around. A solid colour means that both councillors are from the same party.

N.B. As Charlton Park is awaiting election one of the councillors has been drawn in white. It was previously conservative and is likely to remain so when the by-election happens.

Edit 27th May 2014: The results posted on the Cheltenham Borough Council website were originally slightly incorrect due to a transcription error. Two of the figures had been changed and the changes have now been reflected on these diagrams. I also took the chance to make “People Against Bureaucracy” separate from “Independent”, as this seems more instructive.

 

String Replace object updated

I’ve updated the String Replace extension for Multimedia Fusion in order to support a new action that clears the list of rules.

I did look at updating the extension to support Unicode and properly support the Unicode version of Multimedia Fusion (which includes the new Fusion 2.5). However, the SDK I was using is too out of date and so it would’ve been quite a lot of effort. Therefore the object does not support Unicode and also the array and global string functionality does not work in Fusion 2.5 or the Unicode version of Multimedia Fusion 2.

When the Fusion 2.5 SDK is released I may look at rewriting the object (in a compatible manner) so that it does support Unicode, and also perhaps get it to work on other platforms. I’m not sure yet, but it seems like it’d be a good way to get back into extension development for a possible future Ini++ Lite object. I have mentioned this idea in a previous post on this blog.

Download

New version of Ini++ fixes crash

I have updated the Multimedia Fusion 2 extension Ini++. The update fixes a crash. This crash only occurred when both encryption and disk access were enabled, as far as I know. This build hopefully fixes the problem. It is referred to as the October 2013 build (sorry for it taking until mid-November to release it!)

Thank you to Logan Apple for his extremely useful help in reproducing this problem.

Update: It was reported that Build 258.2 and higher of Multimedia Fusion breaks this extension. I could not reproduce this and it appears to work fine in Fusion 2.5.

Download Link

MMX Instructions

In 1997 Intel added a set of instructions to their Pentium processor that were expected to be useful for audio and image processing. This was called MMX. The major feature it allowed was the adding of four 16-bit variables in one instruction (or alternatively eight 8-bit values or two 32-bit values).

It also features a mode where the value of the addition  ‘saturates’ rather than wraps. For instance, 100+200 = 255 using unsigned 8-bit saturation arithmetic. This is particularly useful in image and audio processing as wrapping often does not make sense in these cases. For instance, suppose we have a bitmap image where, after a header, every value is stored as 3 bytes in a row. Suppose we wish to make the image a bit lighter. It is simple to achieve this, as shown below.

// Assume 'data' is a character array holding the bitmap data, excluding
// the header. len holds the length of this array.
for ( int pos = 0 ; pos != len ; ++pos )
{
 int newValue = data[pos] + 50;
 if ( newValue < 0 )
   newValue = 0;
 if ( newValue > 255 )
   newValue = 255;
 data[pos] = newValue;
}

If I run this on my test image (which contains 844,048 pixels) it takes about 3.1ms, excluding the time to read to and write from file.

I wondered how much faster it would be using the MMX byte-wise saturated adding function. I shall be using the MSVC compiler and so MASM style inline assembly will be used. The instruction required is paddusb. The first parameter is a MMX register and the second location is either a MMX register or a memory location. The result is written to the first parameter.

So the basic idea is that we loop ‘data’, send the current 8-bytes chunk into an MMX register, call the saturated add function and then put the resulting variable back into the memory location we found it in. This gives us something like this:

unsigned char* end = data + len;
unsigned char toAdd[] = {50,50,50,50,50,50,50,50};
while ( data < end )
{
   __asm mov eax,data
   __asm movq MM0,[eax]
   __asm paddusb MM0,toAdd
   __asm movq [eax],MM0
  data += 8;
}
__asm emms // Restore state
// If data != end the last few should be adjusted without
// the use of these special instructions. I won't do this
// for demo purposes

Note that the ’emms’ instructed is required after we have finished with MMX, as otherwise floating point calculations won’t work properly (MMX and the floating point instructions use the same registers). ‘movq’ accepts a memory address as the second parameter, so we use the location that ‘data’ is pointing to. (We have to dereference it and so it must be in a register. It is not allowed to have an instruction like ‘movq MM0,[data]‘)

The same example now runs in 0.4ms – nearly 8 times faster.

Finally, we can optimise this a little. We are using ‘data’ as a counter and then keep transferring it to ‘eax’. Why not just use ‘eax’ directly? Finally, since we are not short on registers, we should make sure that ‘toAdd’ is always in a register. Let’s leave it in MM1. This gives us the following final code:

__asm
{
 // eax will contain the current offset
 mov eax, data
 // ebx will contain the final offset
 mov ebx, data
 add ebx, len
 // MM1 contains the constant to add
 movq MM1,toAdd
TOP:
    // load in the value to MM0
    movq MM0,[eax]
    paddusb MM0,toAdd
    movq [eax],MM0
    add eax,8
    cmp eax,ebx
    jl TOP
  // Again, deal with remaining bits here
  // for real production code
  emms
}

It now runs in 0.3ms – over 10 times faster than the original version.

Nothing clever was done here – just some (now) standard instructions were used in the most basic and standard way. However, the increased speed was incredible and so I thought I would share it.

Update to Ini++ v1.5 and thoughts about a new extension

I have issued an update to Ini++ v1.5. It fixes a couple of memory leaks do with the undo stack. The memory leak applied even if the undo stack was disabled. For this reason it is important that every user update to the latest version.

In addition, a minor bug is fixed where the undo and redo stack size could be set to 128 layers. This would actually register as infinite. Now the properties panel will not allow any values greater than 127. If you previously choose 128 it will stay selected, so you ought to be aware of this.

There are still known bugs. I have been able to reproduce a crash with the encryption. Hopefully I’ll  be able to fix this in future, but I do not have the tools available to do so quickly. I apologise for the instability. Thank you to HitmanN and XStar for sending me examples of these problems.

The new version can be downloaded here.    It has since been updated again, see here.

In addition, I wanted to float a new idea. Many people have asked for Ini++ to be ported to other platforms. This will not happen. Ini++ is a monster of an object with many, many features. One only has to look at the file size and options to realise this. Therefore it would be a lot of effort to port to any other platform.

There is a demand for a data storage object on other platforms though, and it seems the format of Ini++ is one that appeals to people. Therefore I propose a cut-down version of Ini++ be created and ported to every platform. This is obviously a fairly big project for me to undertake, and I’m not sure yet that I want to do this. But I wanted to ask people what features are important to them.

Some of the features that Ini++ support are:

• Compression
• Encryption
• Built in features to save the file in specific directories
• Setting initial data
• Debugging tools, including a dialog that can be opened at runtime
• Case sensitive/insensitive options (including the ability to change it at runtime)
• Repeated groups and items via renaming
• The ordering of the file is preserved (but comments, etc. are not)
• Options to auto-save or not
• Searching features
• Sorting and reordering features
• Merging functions
• Half-baked ‘subgroups’
• Global data, including across sub-apps. (Is the latter even possible in other runtimes?)
• Hashed values
• Get/Set as text, CVS
• Listing groups and items
• ‘Perform calculation’ expressions that allows summary information to be easily extracted. Has anybody ever used that?
• Undo and redo stacks
• Escape characters
• Alphanum sorting that puts, say, “Hello 12” before “Hello 3”
• Interaction with the chart object, array object
• Functions to get the ‘part’ of a string directly
• Lots of actions had custom dialog boxes in MMF
• Saving objects and global values directly
• Ability to allow/disallow empty groups, etc.
• ‘Current group’ set of features

Some extra features I was going to add were: Filtering of the object (so that it would changes what the object lists and so forth without actually changing the object), proper subgroups, saving to formats other than Ini files (in particular, making the whole thing work the same but write to the registry or via a server) and full preservation of white space, etc. Unicode support everywhere would be good, too. Encryption is memory was an idea too, but it is questionable how useful that is.

Which features are the most important? If people could tell me (on the Clickteam Forums) their top 5 or so features in order I would find it very useful. Remember, it would take too long to add every feature to every platform, so be conservative.