IB Computer Science IA: Word Count Advice

The word count is 2000. If you go over this then the moderator has the right to stop marking the extra. Some parts of the IA have no word count but there are nuances.

What is not included in the word count:

  • The success criteria (in Criterion A)
  • The record of tasks (Criterion B)
  • The design overview (Criterion B)
  • The video, obviously (Criterion D)

This means that the only parts of the IA that do have a word count are:

  • Criterion A (all except the success criteria)
  • Criterion C
  • Criterion E

Since Criterion A and Criterion E are both worth 6 marks, and Criterion C is worth 12 marks, it makes sense to divide the word count accordingly:

  • Criterion A and E: 500 words each
  • Criterion C: 1000 words

A few words of advice:

  • Source code should be included in an appendix and obviously does not contribute to the word count.
  • Diagram annotations will not contribute to the word count unless they are flagrantly being misused to cram in extra content.
  • The design overview (Criterion B) should not include extended writing; it should be mostly diagrams, tables, schematics, flowcharts, pseudocode, etc. If you add a lot of explanatory text to Criterion B then the moderator is free to add it to the word count.

Please free to ask any questions in the comments section.

IB Computer Science Case Study 2019: A Word of Warning

When students are faced with a research task, a common strategy for weaker students is to just “google it” and take notes on the first few search results. Another poor strategy that affects IB Computer Science students is to exclusively revise from one IB Computer Science website, on the assumption that everything on it is correct.

While examining this year’s Case Study, “A new computer aided dispatch system for Bangbai”, I found that a great many students were giving the same, wrong answers to some of the questions. In some cases students were giving the same answers, word-for-word.

I decided to see if I could find where these answers were coming from and I tracked them down to one IB Computer Science website. Reading through the case study notes on that site, I found a whole range of notes that were quite wrong. It is bad luck that a question came up this year on which this website’s notes were particularly bad. I won’t reveal the question or the name of the site but suffice it to say that I have awarded zero marks to literally hundreds of students this year because they wrote down, word-for-word, what was written in the case study notes of this website.

To students, please use a range of sources and cross-check them. Make sure in particular that the definitions you find are correct in the context of the case study.

To teachers, please continue to share your notes online, but be as careful as you can to make sure they’re correct and urge students to use a range of resources.

The Halting Problem

Is it possible to write a program A that takes another program B as input and which determines if B will halt or loop forever?

Well it turns out that an assumption that the answer is “yes” leads to a paradox and hence there is a proof by contradiction that the correct answer must be “no”.

The proof goes like this:

Assume program A can determine if program B will halt or loop forever.

Now I write a program C that calls program A as follows:

B = input_program
if A says B will halt then
   loop forever
end if

And I now feed program C to itself as input.

The result is that if C will halt, then it will loop forever, but if it will loop forever, then it will halt.

Disassembling C code to see the assembly language

We’ve been talking about assembly language in class recently and I’ve found a nice way of comparing source code with the assembly that the compile outputs. This is C, a compiled language.

int main() {
  divmod(26, 5);

int divmod (int dividend, int divisor) {
  int quotient = 0;
  while (dividend - divisor >= 0) {
    dividend = dividend - divisor;
    quotient = quotient + 1;

The code divides 26 by 5 to give a quotient of 5 and remainder of 1, which is left stored in the dividend variable.

(This file was saved as divmod.c and then compiled using gcc, which is probably already installed on Mac computers. If you’re on Windows, you are advised to install the Community Edition of Microsoft Visual C++.)

Now, using a utility called objdump, which is preinstalled on my Linux laptop, I can now output the assembly code that was generated by the compiler. The output file of the compiler is called a.out, so that is the input to objdump. The flags tell objdump to include the source code intermixed with the assembly code, which is very handy for us!

The command to disassemble the compiled code is:

objdump -Sd --dwarf=info a.out

This provides a whole load of output, but in amongst it you can find the assembly code for the divmod function:

objdump output

Ordered Array Class

Arrays are static data structures, so their size is fixed when they are created. Array elements are contiguous in RAM. This means that if you want to slot a value into the middle of an array, you need to shift the other values first. Imagine trying to slot yourself in between two people in a crowded cinema.


A good exercise is to code an OrderedArray class. This is a wrapper for an array of Integer object (use Integers not ints so that we can check for nulls) that has an insert method that slots new values in ascending order.

I would say that the complexity of this code is about as tough as it gets at SL. If you need some scaffolding, use the class template below. Otherwise just have a go at it yourself. In addition, code a constructor that allows you to set the size of the array.

class Main {
  // This main class is just for testing.
  public static void main(String[] args) {
    OrderedArray oArr = new OrderedArray(50);
    for (int i = 0; i < 30; i++) {
      java.util.Random r = new java.util.Random();
    // You will need to code this method.
    // The numbers should be in order.

class OrderedArray {

  // What instance variables will you need?

  public OrderedArray(int size) {
  // Use the size parameter to set the size of the array.

  void insert(int n) {
  // Insert the new number in the right place.
  // 1. Find out where it should go.
  // 2. Make room for it.

  void print() {
  // Print the numbers to the console.


Interfaces and functional interfaces

Java interfaces are not in the IB syllabus, but if you want to call yourself a higher level computer scientist you should at least have some idea about them.

An interface is like a class but it doesn’t have code in its methods. What is the point of that? Well imagine that I am on your team of programmers and you want me to do some coding for you. By creating an interface, you can specify what methods my classes should have, without actually coding them. This means you can go ahead and write code that calls those methods before I have even written them, and therefore we can both be programming at the same time, taking advantage of concurrency.

Some well-known Java interfaces are Serializable, Iterable and Comparable. Here I define an interface called Flickable. In order for a class to be Flickable, it should have a flick() method:

public class FunctionalInterfaceDemo {

    public static void main(String[] args) {
        Switch s = new Switch();
        Flickable f = new Flickable () {
            public void flick() {
                System.out.println("Anonymous inner flickable class flicked.");

class Switch implements Flickable {
    // This class MUST implement a flick() method, otherwise
    // the code will not compile.
    public void flick() {
        System.out.println("Switch flicked.");

interface Flickable {
    // This states that if you want to call yourself flickable,
    // you have to implement a flick() method.
    void flick();

This is a powerful aid to object-oriented programming because you can anticipate the behaviour of classes that claim to implement an interface safe in the knowledge that if they don’t implement the interface the compiler will already have detected the problem.

But there is a different problem. Suppose now I make a change to my Flickable interface and add a line void unflick();. I have now moved the goalposts and said that any class that claims to be flickable must implement not only a flick() method but an unflick() method. The upshot is that all code that implements the flickable interface is now broken and will no longer compile!

From Java 8 onwards, you can declare an interface to be a functional interface. The reason for this is well beyond the scope of this post, but has to do with Java’s push to incorporate more practices from a programming paradigm called functional programming. The good news is that with the @FunctionalInterface compile directive, we can tell the compiler that our interface cannot have more than one method. This substantially reduces the possibility of breaking code by making a change to an interface, because the compiler will prevent it.

interface Flickable {
    // This states that if you want to call yourself flickable,
    // you have to implement a flick() method.
    void flick();

    // If you uncomment the next line you will break
    // break all classes that implement Flickable:    

    // void otherMethod(); 

interface Proddable {
    void prod();

    // If you uncomment the next line you will get a
    // compile error. You can't have more than one method 
    // in a functional interface.
    // void otherMethod();