Background

A blog post on predictive modelling in Euchre proposed a hand-scoring formula and a set of position-dependent bidding thresholds for UK Euchre. The scoring system assigns each hand a numeric value based on four components:

• A — trump count bonus (0, 1, 2, 6, 9, or 12 for 0–5 trumps)
• B — individual trump card values (Benny=10, Right Bower=8, Left Bower=6, Ace=5, King=4, Queen/10=3, 9=2)
• C — offsuit aces (4 each) and kings (1 each)
• D — dealer penalty (Jack worth −5, Ace worth −2 in Round 1 only)

The blog derived position-specific bid thresholds — for example, the Dealer needs only 16 points to bid in Round 1 (because they pick up the turn-up card), while the player to the Right of Dealer needs 31. It also proposed separate, higher thresholds for going alone.

The question I wanted to answer: are these thresholds actually optimal, or can we do better?

The project itself was to use Monte Carlo simulation techniques to discover things about the phases of idealised liquid crystals, modelled as ellipses and ellipsoids in 2 and 3 dimensions. The original code was written in C (much to my tutors chagrin who wanted me to use FORTRAN).

For some reason, last weekend I though it would be a good idea to rewrite it Julia. So I did and it worked so much better (faster) than back in 1997. Maybe I’ll be able to finish the original aims of the dissertation, 25 years later!

One of the properties of liquid crystals is that, at low enough temperatures and high enough pressures, they align with each other in much the same way they do on LCD displays when a voltage is applied. My simulations were able to recreate this effect (see Figure 1). They measured the density of the simulated material, which obviously increases the more the crystals align. I did notice that there wasn’t a direct measure of alignment… so why not invent one?

I needed a formula that I could sum pairwise over all the crystals (ellipses). Ideally the measure should be 0 if all the ellipses are totally unaligned and 1 if totally aligned. Taking two ellipses first, the obvious choice matching these criteria is the cosine of the angle between them, basically cosine similarity. This gives exactly 1 if ellipses are aligned and exactly 0 if they are perpendicular. The ellipses have a symmetry where they should also be measured as aligned if the angle is 180º. I this case the cosine is -1 when it should be 1. A simple way to achieve this is to take either the absolute value of the cosine or its square. This latter option has a nice symmetry to it. Averaging over the terms we have a first stab at an alignment formula, :

Where an enumerate over the ellipses to be measured and is their respective orientation. To test my formula I generated different configurations and tested their alignment. If all the angles where the same then the alignment did indeed come out as exactly 1. However I realised that there is no way to make more than 2 ellipse totally perpendicular in 2 dimensions. They will always align somewhat with the first or the second. When there are more ellises the situation is worse.

Obviously, the minimum posible alignment of 2 ellipses is when the angle between them is radians, orthogonal. After scratching my head for a while and running different tests, I realised that 3 ellipses is when the angle between them is exactly radians (see Figure 2).

A similar thing happens with larger numbers of particles where the minimum has then dividing the circle equally. This is obviously true for 2 ellipses and I can prove it for 3. I’m taking it to be the case for now.

After a bit of thinking the way to calculate this minimum, , is to make the following sum:

Where is the angle of the kth ellipse and there are ellipses with that angular separation. We divide by the number of pairs counted. With a bit of help from the internet this is solvable and has a simple closed form. Using the identity:

and the orthogonality of the cosine funtions we have:

Validate: , , , etc.

Also: as required.

I wanted to factor out this minimum alignment bias from the calculation so that the alignment would always be in the range from 0 to 1. To do that we calculate the proportion between and . So the new formula is:

I’ve tested this with different distributions of angles and it gives a reliable indicator of the alignment. The only thing is that the cosine squared makes it quite non-linear having a tendency to be closer to the extremes, 0 and 1. To counteract this an inverse straightens out the results for a smoother gradient, so

might give better results depending on the application.

As a reminder, here we generate an array of random 3-bit numbers using the nshots parameter to specify how many, in this case 1000.

using Yao
n=3
numbers = zero_state(n) |> repeat(n, H) |> r -> measure(r, nshots=10000)

1000-element Array{BitBasis.BitStr{3,Int64},1}:
 100 ₍₂₎
       ⋮
 110 ₍₂₎

To see the histogram of results we could do something like this:

histogram(numbers .|> bint, legend=:none, xticks=(0:7))

This is OK but it has a few things I don’t like, for one the ticks don’t really line up properly with the bars. Also the ticks have to be manually set. Also the bins often have to be tweaked manually as well. These things are easy to fix and put inside a Plots.jl recipe for easy reuse.

Looking back at the results, Yao.jl gives us an array of BitStr results and the full type Array{BitBasis.BitStr{3,Int64},1} is parametrised by the number of bits. That turns out to be quite useful. Defining the recipe function like this:

@recipe function user_recipe(measurements::Array{BitStr{n,Int},1}) where n

We now have access to the number of bits in . The maximum possible value is then max = (1<<n)-1. Then we can calculate the histogram using standard Julia tools:

hist = fit(Histogram, Int.(measurements), 0:max+1)
hist = normalize(hist, mode=:pdf)

Notice that this is where the conversion to Int happens and we one again use the max value that came via the type parametrisation. Next the plot attributes, basically the same as the histogram used above:

seriestype := :bar
bins := max+1
xticks --> (0:max)
legend --> :none

Again using the max value. Then we can return the histogram results, centering on the tick marks:

hist.edges[1] .- 0.5, hist.weights

Y voila. Julia will automatically dispatch to our recipe based on the type of the results:

plot(results)

To check with a different distriibution let’s try imitating a random 6-sided die by preselection of the unwanted values 6 and 7.

import YaoBlocks.ConstGate.P0

die = chain(4, 
    repeat(H, 1:3),
    control((2,3), 4=>X),
    put(4=>P0))

results = zero_state(4) |> block |> r -> focus!(r, 1:3) |> r -> measure(r, nshots=10000)
plot(results)

Distribution shows values 6 and 7 have 0% probability, as we expected.

Working code available here.

This post describes one of the first quantum algorithms to be discovered that gave a theoretically significant improvement over the classical equivalent. Having said that it’s not useful at all, its main value was that it served as inspiration for other more practical algorithms such as Grover’s search and Shor’s factoring.

f : (Boolean) -> Boolean

f(false) ⊻ f(true)

deutsch(Uf) = chain(2,
                put(2=>X),
                repeat(2, H),
                Uf,
                put(1=>H))

Uf₁ = put(2=>X)

zero_state(2) |> deutsch(Uf₁) |> focus!(1) |> measure!

Uf₂ = control(1, 2=>X)

f : (Int) -> Int

deutsch_jozsa(m, Uf) = chain(m+1,
                        put(m+1=>X),
                        repeat(m+1, H),
                        Uf,
                        repeat(H, 1:m))

perm = [(y ⊻ f(x))<<m + x for y in 0:1 for x in 0:2^m-1]

permute(sparse(I, N, N), perm.+1, collect(1:N)) |>
     Matrix{Complex{Float64}} |>
     matblock

f(x) = 1 # constant
zero_state(m+1) |> deutsch_jozsa(m, Uf(m, f)) |> focus!(1:m) |> measure!

Continuing the series of posts building the basic quantum algorithms with Yao.jl we come to Grover’s algorithm. There is a tutorial on Grover in the Yao.jl documentation but I found it a little hard to follow the code so I simplified it right down to the basics.

Remember that we have a binary function, , which is always equal except for a single value , when it is equal to . The challenge is to find with as few queries to as possible. As always, and with all the usual caveats, we take for granted that we have access to an oracle, , that provides a suitable quantum transformation based on .

The oracle consists of a transformation which reflects the target value, , and only this value, around the x-axis. All other values are left untouched.

function oracle(u::T) where T<:Unsigned
    n = ceil(Int, log(2, u)) # Use only as many bits as necessary
    v = ones(ComplexF64, 1<<n)
    v[u+1] *= -1 # Flip the value we're looking for
    Diagonal(v)
end

We work out the smallest number of bits needed from the value itself. In the Yao.jl tutorial this is all on one line and quite cryptic, hopefully this version is easier to read.

Notice that with this construction we don’t have to use an ancillary bit. As can be seen in the diagram we also have some reusable blocks, namely the , which for some reason the tutorial calls gen, and the repeating section which is a combination of the oracle itself followed by the diffusion operator. They are chained together like this:

    gen = repeat(n, H)
    reflect0 = control(n, -collect(1:n-1), n=>-Z) # I-2|0><0|
    repeating_circuit = chain(Uf, gen, reflect0, gen)

Inside the repeating section there is also the reflection circuit, reflect0 which is responsible for flipping the distribution about the average value which is what has the effect of amplifying values made negative by the oracle. To check that it is indeed the correct circuit it can be compared to the other form .

ZERO(n) = foldl(kron, fill([1, 0], n))
Int.(real.(sparse(I, 16, 16) - 2*ZERO(4)*ZERO(4)'))

It is indeed the same, although I’m still sure of the origin of the conditional Z transform version, it’s an identity to bear in mind.

Continuing with the algorithm, the repeating section is simply placed in a for loop applied to a prepared quantum register:

    reg = zero_state(n) |> gen
    for i = 1:iter
        reg |> repeating_circuit
    end

function grovers(Uf::AbstractBlock{n}, iter::Int) where n
...
end
grovers(matblock(oracle(0b11110011)), 10) |> measure!

And that’s it, not too bad actually. Working code is here.

Looking forward to applying to more interesting problems to it.

PS: Just for fun this is how the histogram of probabilities evolves between each iteration. It’s clear how the chosen value emerges in just a few steps.

If you’re interested, this is the code to generate the histogram. Run with 6 bits over 6 iterations and 1000 shots at each iteration to get the probability.

using Plots
...
  anim = @animate for i = 1:iter
    numbers = reg |> r -> measure(r, nshots=1000) .|> bint
    histogram(numbers, normed=true, legend=:none, xlims=(0,63), ylims=(0,1), nbins=64)
    reg |> repeating_circuit
  end
...
gif(anim, "grovers-search.gif", fps = 1)

As you might expect, it’s beyond trivial.

using Yao, BitBasis
n=3
zero_state(n) |> repeat(n, H) |> measure! |> bint

Here Yao is the base package. BitBasis contains the tools for dealing with bit strings which Yao returns.

We pass a zero_state with n qubits, i.e. , through n hadamard gates and then measure the result. Each bit has a 50/50 chance of being 0 or 1. In this case we use the bint function from the BitBasis package to convert the measured bits to a number.

The result is indeed a random number between 0 and 7.

Let’s go a little further and make sure the numbers are uniform by plotting the distribution of the results:

results = zero_state(n) |> repeat(n, H) |> r -> measure(r, nshots=10_000) .|> bint

The only difference here is the nshots parameter passed to the measure function to repeat the measurement that many times. This is much faster and cleaner than using a comprehension of something. the .|> operator converts the individual results.

The result is an array of 10,000 measurements which should be uniformly distributed. Let’s check:

histogram(results, legend=:none, xticks=(0:maximum(results)), bar_width=0.9)

Gives us

Which is good.

Edit: I did the talk laid out in this post on the 10th of October 2019. It mostly followed the outline presented here but in the heat of the moment I accidentally skipped the ice-breaker and much of the introduction, I guess because of nerves. Of the feedback that I got, one person felt that it had lacked a better narrative structure, which is exactly what I did try to do, unsuccessfully it seems. Next talk will be about Conway’s Law at the “Papers We Love” Meetup group. Let’s see how that goes.

One of the nicest things about working at Codurance¹ is the bi-weekly catch-ups. Those of us who are working mainly at client offices go to the Codurance office, meet other Codurancers who we haven’t seen for a while, eat together and share our experiences. We also do lightning talks about things that interest us and at the same time get a chance to practice our presentation skills. After doing many of these internal talks, someone said in a peer review that maybe I should take it up a notch and do a talk externally. Always trying to push out of my comfort zone (aka a sucker for punishment) I proposed a talk at the Barcelona Software Crafters conference, with a very short synopsis.

How predictable is your code? How predictable is your system, your project or your business? What does it mean to be predictable? Knowing this will help us write better code, create better systems and run better projects and help us understand why agile practices work and when they may not be enough…

To my astonishment it was accepted.

The theme of the talk was clear to me and I had (in my head) a clear narrative to explain.

• Predictably unpredictable code (traditional complexity metrics)
• Predictably unpredictable systems (Game of Life, deterministic complexity)
• Predictably unpredictable complex adaptive systems (human systems, Systems Thinking and Cynefin)

However, as I tried to nail down the actual slides I realised it wouldn’t be as easy as I had anticipated. For one, as I added individual ideas which I wanted to cover I couldn’t find a clean, linear arc for the presentation (things seem much cleaner in one’s head). What’s more, during the research, more and more related topics came up and I couldn’t cover them all. And all the while I still had to be true to the original proposal.

So I wrote down a new possible arc:

• Connection
• Interaction
• Systems/Adaptation

With this outline I had the same problem, I had simply pivoted what was essentially a two-dimensional idea:

So I can traverse this row-wise or column-wise, top-down or bottom-up, right to left or left to right. I chose column-wise, left-right, top-down.

• Code - Connection (traditional complexity)
• System - Connection - Interaction (dynamic complexity, Systems Thinking)
• CAS - Connection - Interaction - Adaptation (adaptive complexity, Cynefin)

Wrapping in an introduction and a final section which rewinds the talk, I have the high-level, linear arc I needed.

• Ice breaker (local feedback demo with clapping)

• Introduction

  • drop pen
  • if only we could predict the future (BTTF II)
  • tireless search for predictability doesn’t always work
  • raising the bar (Alex Bolboaca)
  • recipes vs principles (Heston Blumenthal)

• Connections in code

  • condition separation (coupling)
  • gilded rose
  • duplicated code
  • first definition of complexity
  • common in TDDed code
  • importance of refactoring to reduce implicit connections
  • doing things more than once

• Connections in systems

  • system connections and coupling; a system is not a tree (Henney)
  • indirect coupling
  • Relationship between things as well as the things themselves (Mary Poppendick (here) (The dance as opposed to the dancers)
  • “dynamic” (Scorpios quote) (monitoring)

• Interactions in systems

  • self-reinforcing coupling (logging CPU -> scaling -> problems -> logging CPU)
  • Netflix scale (vizceral screenshot)
  • second definition of complexity
  • many failures identified only in retrospect
  • resilience (modularity, redundancy, diversity, anti-fragile)
  • dangers of interfering with such a system (mosquitos, unexpected consequences, cobra effect)
  • Systems Thinking (outside looking in)

  ---

• More interactions in systems

  • pushing complexity: Game of Life and friends
  • third definition of complexity
  • emergence; phases
  • in nature (you; weather, on Jupiter, sun spots, three-body problem, galactic filaments; hexagonal columns, traffic jams, washboarding, ripples, petri dishes, gravity or even time itself)
  • The End of Certainty

• Connections in CASs

  • crowd dynamics (eg. Mecca: “simulation is part but not enough”)

  • social systems are another level (families, communities, social networks, cities, countries) -The realm of policy and politics

  • adaptive, independent agents - inside looking out

  • fourth definition of complexity

  • predictable irrationality (confirmation bias, success bias, etc.) (computer learns to predict unpredictability)

  • Self-organising (back to clapping)

  • Cynefin; decision landscape (mapping), catastrophic fold, disorder domain; pre-scrum

  • agile in complicated or simple domain is wasteful; safe-to-plan

  • predicting things in the complex domain is futile. Design for serendipity, deliberate connections, coherent probes and experiments; safe-to-fail

  • Link with OODA, 3X

  • Dancing with systems; future of agility

• Summary

  • Rewind back through different types of complexity

• Questions

Using tools from number theory, the algorithm consists of a procedure which transforms the problem of prime factorings into a problem of period finding. The advantage of this is that the period finding part, which is exponentially hard on classical computers, can be implemented efficiently (i.e. in polynomial time) with a quantum computer.

The details of the algorithm can be found across the internet. Here’s a video of a talk by James Birnie but I recommend you to also look for your own research material. There’s some non-trivial maths going on and it’s not easy to understand all of the different elements involved in the algorithm. It helps to read multiple different tutorials and explanations.

Anyway, for the moment, let’s just implement the classical parts in Julia. It turns out to be quite simple. These are the steps:

• Step 1: choose a random number 1 < a < N
• Step 2: find r, the period of with respect to x
• Step 3: check that r is even and
• Step 4: calculate the factors (p,q) as

Obviously before we can do anything we need a number to factor. Let’s use 37 * 41 = 1517.

# Number to factor, a multiple of two prime factors > 2
N = 1517

The first step is to choose a random number . Also we don’t want to use the degenerate case of .

a = BigInt(rand(2:N))

We use Julia’s arbitrary precision integers (BigInts) because the exponents get very big very quickly and even 64 bit integers will likely overflow.

The next step is to find the period, say , of with respect to . This is the operation that will be done with a quantum computation. For now we’ll do it with a brute force approach but remember that this would be prohibitively time-consuming when the number to factor is large.

r = 1
while a^r % N != 1 && r < N
    global r
    r = r + 1
end

After running the above code let’s look at the results:

> @show N, a, r
(N, a, r) = (1517, 1371, 180)

So we have our period, 180. Lucky we used arbitrary precision integers, is a very, very big number!

Next, for the calculation to work we need to check that the period is even and that: . If it isn’t then we just try again with another value for .

if r % 2 == 0 && a^(r>>1) % N != 0
   ...
end

Finally we calculate the factors, and . Julia gives us an implementation of the greatest common divisor algorithm as part of its base functions, so no need to worry about that. The factors are and . To keep the types as integers we can use the bit shift operator rather then dividing by 2. In Julia this is simply:

    p = gcd(a^(r>>1)-1, N)
    q = gcd(a^(r>>1)+1, N)

So what’s the result?

> @show p, q
(p, q) = (41, 37)

Which are the numbers we first thought of!

Right, that’s the easy part and with Julia it was very straightforward due to the native arbitrary precision integers and exponent operators. The hard part is the actual quantum algorithm which we’ll come back to in a later post.

So here’s the classical algorithm ion it’s entirety. There are some edge case that are not being checked but this is basically it.

# Number to factor, a multiple of two prime factors > 2
N = 1517

# Step 1: choose a random number 1 < a < N
a = BigInt(rand(2:N))

# Step 2: find r, the period of a^x mod N
r = 1

while a^r % N != 1 && r < N
    global r
    r = r + 1
end

@show N, a, r

# Step 3: check that r is even and a^(r/2)+1 != 0 mod N
if r % 2 == 0 && a^(r>>1) % N != 0

    # Step 4: calculate the factors
    p = gcd(a^(r>>1)-1, N)
    q = gcd(a^(r>>1)+1, N)

    @show p, q
end

function qft(n)
   N = 2^n
   ω = exp(2 * π * im / N)
   a = 1 / sqrt(N)
   [a * ω^(i*j) for i in 0:N-1, j in 0:N-1]
end

Here is the number of bits and the size of the matrix, which as we know grows exponentially with the number of bits. is the first complex root of unity and the normalising factor. The comprehension runs over both axis and computing the element at each position.

We can test this against the example from the Wikipedia article:

@test qft(2) ≈ 0.5 * [1 1 1 1; 1 im -1 -im; 1 -1 1 -1; 1 -im -1 im]

In the above it’s going to generate complex numbers with Float64 precision. For our quantum gates this level of precision is not necessary and uses more memory. A few tweaks to the function will use Float32 instead.

function qft(n)
   N = 2^n
   ω = exp(2f0 * π * im / N)
   a = 1f0 / sqrt(Float32(N))
   [a * ω^(i*j) for i in 0:N-1, j in 0:N-1]
end

And test that it does indeed generate the correct type.

@test typeof(qft(2)) == Array{Complex{Float32},2}

What about the performance? Let’s generate the QFT for different numbers of bits.

> @time qft(11)
0.384501 seconds (6 allocations: 32.000 MiB, 11.74% gc time)
2048×2048 Array{Complex{Float32},2}

> @time qft(12)
1.469458 seconds (6 allocations: 128.000 MiB, 3.34% gc time)
4096×4096 Array{Complex{Float32},2}

> @time qft(13)
6.037579 seconds (6 allocations: 512.000 MiB, 0.74% gc time)
8192×8192 Array{Complex{Float32},2}

> @time qft(14)
25.163830 seconds (6 allocations: 2.000 GiB, 0.20% gc time)
16384×16384 Array{Complex{Float32},2}

The exponential increase in time and space is evident and we quickly reach practical limits. The array is dense because the values are always non-zero but since the calculation time is relatively small there could be considerable advantage using a ComputedArray instead of a normal array in this case.

We want something like this, remembering that Julia is 1-index based:

deutch(Uf) = register(ZERO, ONE) |>
                gate(H, H) |>
                gate(Uf) |>
                gate(H, eye) |>
                measure(1)

We already have most of the machinery to make this work. We need an overloaded register function to create a register with the given states. This is straightforward and very similar to the gate function we defined in the last post.

register(x...) = foldl(kron, x)

Next a pipeable measure function that takes the bit k that we want to measure (1-indexed).

measure(n, k) = (qubits) -> measure!(n, k, qubits)[1][k]

To avoid having to pass in the size of the register, we can calculate it from the length of the qubits vector. We know that the length, , of the vector is so . In code that becomes:

size(qubits) = Int(floor(log2(length(qubits))))
measure(k) = (qubits) -> measure!(size(qubits), k, qubits)[1][k]

All that remains is to define the oracle . For 2-bit inputs there are four possible functions:

|| | | | |

|:-:++:—–:+:—–:|:—–:|:—–:| | 0 || 0 | 0 | 1 | 1 | | 1 || 0 | 1 | 0 | 1 | |||constant|balanced|balanced|constant|

The transformation we need for the oracle is from to which we can write out explicitly.

0 0		0	0	1	1
0 1		1	1	0	0
1 0		0	1	0	1
1 1		1	0	1	0

Reading off the columns we have:

|:—:|:-|:—–: | | y | I | | x?~y:y | Controlled NOT | | y?~x:x | Reversed Controlled NOT | | ~y | NOT

The matrices that do those transformations can be written as direct sums,which is available in Julia as the blockdiag function:

Uf1 = blockdiag(eye, eye) # I
Uf2 = blockdiag(eye, NOT) # C-NOT
Uf3 = blockdiag(NOT, eye) # Reversed C-NOT
Uf4 = blockdiag(NOT, NOT) # NOT

If the function, , is balanced then the measurement will always be true, if constant then the measurement will always be false. Let’s evaluate them all together:

julia> map(deutch, [Uf1, Uf2, Uf3, Uf4])
Bool[false, true, true, false]

We can see that this is exactly the result we expect.

Extending to multiple bits, the generalised quantum circuit in this case is:

This is known as the Deutsch-Jozsa algorithm. The wikipedia article has much more information about how this works. In our Julia DSL we can easily extend to 2-bit functions:

deutchJosza(Uf) = register(ZERO, ZERO, ONE) |>
                gate(H, H, H) |>
                gate(Uf) |>
                gate(H, H, eye) |>
                measure(1:2)

We could determine the transformations like before by writing them out explicitly but new we have 8 possible permutations. Rather than writing them out let’s write a function to do it for us:

oracle(n::Int, f) = begin
    perm = Dict{Int,Int}()
    for x in 0:2^n-1
        for y in 0:1
            xy = (x << n) + y      # |x>|y>
            fxy = y ⊻ f(x)         # |y⊕f(x)>
            xfxy = (x << n) + fxy  # |x>|y⊕f(x)>
            perm[xy+1] = xfxy+1    # mapping (1-index based)
        end
    end
    permmat(map((it) -> perm[it], 1:2^(n+1)))
end

permmat(π) = sparse(1:length(π), π, 1)

This function goes through the possible values of and the two possible values of and builds a transformation table, perm, of the values to . This table is then used to create a (sparse) permutation matrix for the transformation, e.g. . This is a very brutish way of doing it but it gets the job done.

Finally we can run the algorithm and check it works

deutchJosza(Uf) = register(ZERO, ZERO, ONE) |>
                gate(H, H, H) |>
                gate(Uf) |>
                gate(H, H, eye) |>
                measure(1:2) |>
                (y) -> reinterpret(Int, y.chunks)[1] != 0


Uf1 = oracle(2, 1, (x, y) -> y ⊻ 0)
Uf2 = oracle(2, 1, (x, y) -> y ⊻ (x & 1))
Uf3 = oracle(2, 1, (x, y) -> y ⊻ (x & 1 ⊻ 1))
Uf4 = oracle(2, 1, (x, y) -> y ⊻ 1)

@test map(deutchJosza, [Uf1, Uf2, Uf3, Uf4]) == [false, true, true, false]

The line reinterpret(Int, y.chunks)[1] != 0 converts the binary result to an integer and checks if it’s different from 0.

That’s the Deutch-Jozsa algorithm complete. Next one will be Grover’s algorithm, then Simon’s algorithm before we get into the QFT and finally Shor’s famous factoring algorithm.

Take for example the statement “I believe God exists”. We often implicitly or explicitly assume it has only one possible negative, “I don’t believe God exists”.

There are, in fact, three alternative statements: - I have no belief that God exists (weak atheism, or, sometimes, agnosticism, especially in the UK) - I believe that God does not exist (strong atheism) - I have no belief that God does not exist (An even weaker form of agnosticism form of agnosticism but as rational a statement as any other)

We can look at which of these statements are mutually exclusive (hint: the affirmative ones) but in any case, in many arguments about God (for example on Twitter or Quora) these distinctions will likely be forgotten. The reactions to David Mitchell’s explanation of his agnosticism are a good example of this happening.

These failures of logic, called logical fallacies, are everywhere from politics to family arguments. Take this famous exchange between Will Self and Mark Francois: > Will: your problem, Mark, is not that you have be a racist or an anti-semite to vote for Brexit, it’s just that every racist and anti-semite in the country did.

Mark: I think that’s a slur of 17.4 million people [who voted Brexit].

We have a politician provoked into mixing up the negative forms of a statement to reach a non sequitur that makes the conversation valueless to the point of being funny.

Once you start thinking about it, confusion of the inverse is everywhere.

This short post is to see if we can improve the simple functions we wrote to increase the performance.

The first obvious thing to try is to use sparse matrices instead of dense ones. This is especially important when lifting the operators over large registers because the dense matrices are full of zeros. For example take a hadamard operator lift into the 2rd position of a 3-bit register. The lifted matrix becomes:

julia> lift(3, 2, H)
8×8 Array{Float32,2}:
 0.707107  0.0        0.707107   0.0       0.0       0.0        0.0        0.0     
 0.0       0.707107   0.0        0.707107  0.0       0.0        0.0        0.0     
 0.707107  0.0       -0.707107  -0.0       0.0       0.0       -0.0       -0.0     
 0.0       0.707107  -0.0       -0.707107  0.0       0.0       -0.0       -0.0     
 0.0       0.0        0.0        0.0       0.707107  0.0        0.707107   0.0     
 0.0       0.0        0.0        0.0       0.0       0.707107   0.0        0.707107
 0.0       0.0       -0.0       -0.0       0.707107  0.0       -0.707107  -0.0     
 0.0       0.0       -0.0       -0.0       0.0       0.707107  -0.0       -0.707107

This matrix has a high density of zeros, something which indicates that a sparce representation may be better. Luckily Julia includes support for sparce matrices as part of the SparseArrays package and then we can simply start creating sparse matrices with a couple of simple changes:

using SparseArrays

ZERO = sparsevec([1], [1f0], 2)
ONE = sparsevec([2], [1f0], 2)

eye = sparse(I, 2, 2)

julia> lift(3, 2, H)
8×8 SparseMatrixCSC{Float32,Int64} with 16 stored entries:
  [1, 1]  =  0.707107
  [3, 1]  =  0.707107
  [2, 2]  =  0.707107
  [4, 2]  =  0.707107
  [1, 3]  =  0.707107
  [3, 3]  =  -0.707107
  [2, 4]  =  0.707107
  [4, 4]  =  -0.707107
  [5, 5]  =  0.707107
  [7, 5]  =  0.707107
  [6, 6]  =  0.707107
  [8, 6]  =  0.707107
  [5, 7]  =  0.707107
  [7, 7]  =  -0.707107
  [6, 8]  =  0.707107
  [8, 8]  =  -0.707107

We have reduced the memory footprint of the matrix by a factor of 4. In fact the saving is exponential: a array becomes a sparse representation with entries.

Trying the same benchmark again gives us much better results:

for n in 1:11
@time print(toInt(measureAll(n, hadamard(n) * register(n))[1]))
end

0  0.000075 seconds (23 allocations: 1.047 KiB)
3  0.000034 seconds (41 allocations: 1.969 KiB)
0  0.000019 seconds (51 allocations: 3.016 KiB)
15  0.000029 seconds (73 allocations: 5.516 KiB)
12  0.000030 seconds (84 allocations: 11.422 KiB)
46  0.000038 seconds (102 allocations: 31.031 KiB)
62  0.000103 seconds (119 allocations: 102.750 KiB)
143  0.000190 seconds (134 allocations: 374.313 KiB)
301  0.000605 seconds (150 allocations: 1.396 MiB)
130  0.002381 seconds (159 allocations: 5.463 MiB)
666  0.016114 seconds (202 allocations: 21.679 MiB)

Lets see how far we can go…

for n in 12:16
@time print(toInt(measureAll(n, hadamard(n) * register(n))[1]))
end

1131  0.064576 seconds (199 allocations: 85.922 MiB)
430  0.296749 seconds (252 allocations: 342.593 MiB)
12847  1.547630 seconds (285 allocations: 1.336 GiB, 32.59% gc time)
24906  4.267627 seconds (317 allocations: 5.340 GiB, 4.51% gc time)
63277 39.087846 seconds (787 allocations: 21.372 GiB, 6.12% gc time)

It turns out that we’ve improved the performance by a factor of about 32! Not a bad for a 3 line change :)

There are more things to do like in-place multiplications but I’d like to implement some of the standard algorithms first to compare performance in more varied circumstances. That’ll be for next time.

val qubits = Qubits(3).hadamard(0..2)
print(qubits.measureAll().toInt())

Written in Julia this becomes:

qubits = hadamard(qubits(3), 1:3)
print(toInt(measureAll(qubits))

Some things to notice. Firstly we’ve moved to a functional style. As typing is optional there is no need to define the variable. Also the range specified by 1:3 is using 1-based indexing.

repeatedly = (n, f) -> map(x -> f(), collect(1:n))
sample = (n, f) -> count(repeatedly(n, f))

@test sample(1000, () -> measure(qubit())) == 0

qubit = () -> nothing
measure = (qubit) -> false

qubit = () -> Float32(1) * [1, 0]

M₀=[1 0]' * [1 0]
measure = (qubit) -> rand() < abs(q' * M₀ * q)

julia> @test sample(1_000_000, () -> measure(qubit())) == 0
Test Passed

julia> H = Float32(1/sqrt(2)) * [1 1; 1 -1]
2×2 Array{Float32,2}:
 0.707107   0.707107
 0.707107  -0.707107

julia> hadamard = (qubit) -> H * qubit
julia> hadamard(qubit())
2-element Array{Float32,1}:
 0.70710677
 0.70710677

julia> qubit() |> hadamard
2-element Array{Float32,1}:
 0.70710677
 0.70710677

julia> repeatedly(3, () -> qubit() |> hadamard |> measure)
10-element Array{Bool,1}:
 false
  true
 false

coinToss = () -> () -> qubit() |> hadamard |> measure
toInt = (b) -> reduce((acc, v) -> 2*acc + v ? 1 : 0, b)

julia> toInt(repeatedly(3, coinToss))
6
julia> toInt(repeatedly(3, coinToss))
3

qubits = () -> kron(qubit(), qubit())

julia> qubits()
4-element Array{Float32,1}:
 1.0
 0.0
 0.0
 0.0

register = (n) -> foldl(kron, fill(qubit(), n))

julia> register(3)
8-element Array{Float32,1}:
 1.0
 0.0
 0.0
 0.0
 0.0
 0.0
 0.0
 0.0

hadamard = (n) -> foldl(kron, fill(H, n))

julia> hadamard(3)
8×8 Array{Float32,2}:
 0.353553   0.353553   0.353553   0.353553   0.353553   0.353553   0.353553   0.353553
 0.353553  -0.353553   0.353553  -0.353553   0.353553  -0.353553   0.353553  -0.353553
 0.353553   0.353553  -0.353553  -0.353553   0.353553   0.353553  -0.353553  -0.353553
 0.353553  -0.353553  -0.353553   0.353553   0.353553  -0.353553  -0.353553   0.353553
 0.353553   0.353553   0.353553   0.353553  -0.353553  -0.353553  -0.353553  -0.353553
 0.353553  -0.353553   0.353553  -0.353553  -0.353553   0.353553  -0.353553   0.353553
 0.353553   0.353553  -0.353553  -0.353553  -0.353553  -0.353553   0.353553   0.353553
 0.353553  -0.353553  -0.353553   0.353553  -0.353553   0.353553   0.353553  -0.353553

julia> hadamard(3) * register(3)
8-element Array{Float32,1}:
 0.35355335
 0.35355335
 0.35355335
 0.35355335
 0.35355335
 0.35355335
 0.35355335
 0.35355335

eye = () -> Matrix{Float32}(I, 2, 2)

lift = (n, k, op) -> foldl(kron, map(it -> (it == k) ? op : eye, collect(1:n)))

julia> lift(3, 2, M₀)
8×8 Array{Float32,2}:
 1.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
 0.0  1.0  0.0  0.0  0.0  0.0  0.0  0.0
 0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
 0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
 0.0  0.0  0.0  0.0  1.0  0.0  0.0  0.0
 0.0  0.0  0.0  0.0  0.0  1.0  0.0  0.0
 0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
 0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0

measure = (n, k, qubits) -> rand() > qubits' * lift(n, k, M₀) * qubits

julia> qubits = hadamard(3) * register(3)
...
julia> measure(3, 2, qubits)
true

M₁ = [0 1]' * [0 1]
measure = (n, k, qubits) -> begin
       result = rand() > qubits' * lift(n, k, M₀) * qubits
       (result, normalize(lift(n, k, (result ? M₁ : M₀)) * qubits))
end

measureAll = (n, qubits) -> begin
         results = []; 
         for k in 1:n
           result, qubits = measure(n, k, qubits)
           push!(results, result)
         end
         results, qubits
       end

using LinearAlgebra

ZERO = Float32(1) * [1, 0]
ONE = Float32(1) * [0, 1]

eye = Matrix{Float32}(I, 2, 2)
H = Float32(1/sqrt(2)) * [1 1; 1 -1]
M₀ = ZERO * ZERO'
M₁ = ONE * ONE'

register = (n) -> foldl(kron, fill(ZERO, n))
hadamard = (n) -> foldl(kron, fill(H, n))

lift = (n, k, op) -> foldl(kron, map(it -> (it == k) ? op : eye, collect(1:n)))

measure = (n, k, qubits) -> begin
         result = rand() > qubits' * lift(n, k, M₀) * qubits
         (result, normalize(lift(n, k, (result ? M₁ : M₀)) * qubits))
       end

measureAll = (n, qubits) -> begin
         results = [];
         for k in 1:n
           result, qubits = measure(n, k, qubits)
           push!(results, result)
         end
         results, qubits
       end

toInt = (b) -> reduce((acc, v) -> 2*acc + (v ? 1 : 0), b, init=0)

qubits = hadamard(3) * register(3)
print(toInt(measureAll(3, qubits)[1]))

for n in 1:11
@time print(toInt(measureAll(n, hadamard(n) * register(n))[1]))
end

1  0.834134 seconds (1.63 M allocations: 90.474 MiB, 2.38% gc time)
0  0.063235 seconds (15.49 k allocations: 813.162 KiB)
7  0.004201 seconds (9.11 k allocations: 281.986 KiB)
11  0.002534 seconds (27.13 k allocations: 623.813 KiB)
30  0.011686 seconds (122.15 k allocations: 2.509 MiB)
7  0.023647 seconds (634.68 k allocations: 12.326 MiB)
1  0.086709 seconds (3.05 M allocations: 58.193 MiB, 5.11% gc time)
185  0.362644 seconds (14.04 M allocations: 265.855 MiB, 1.72% gc time)
237  1.746489 seconds (63.02 M allocations: 1.163 GiB, 6.29% gc time)
504  7.655970 seconds (279.03 M allocations: 5.145 GiB, 11.96% gc time)
490 31.689085 seconds (1.29 G allocations: 23.612 GiB, 4.77% gc time)

So, I started looking again at complexity theory. I was lead via logistic maps, and other dynamic systems to a library called DynamicSystems.jl written in a language called Julia. I remembered having seen Julia two years ago from another talk on simulating spiking neural networks using Julia.

The things that were bothering me in Kotlin and Clojure when building the QPU simulator were complex numbers and linear algebra, specifically the Krondecker product, and it turns out that Julia supports both natively! So it was worth giving it a try¹.

Installing Julia on a Mac is as simple as you might expect²

> brew install julia
...

Like Clojure, Julia has a nice REPL for developing and testing ideas quickly. Built-in support for vectors means that defining a qubit is easy³:

julia> qubit = Float32(1) * [1, 0]
2-element Array{Float32,1}:
 1.0
 0.0

Julia has dynamic typing so the variable type doesn’t need to be set explicitly. The Hadamard operator[^hadamard] is similarly easy to define with Julia’s matrix syntax:

julia> H = Float32(1/sqrt(2)) * [1 1; 1 -1]
2×2 Array{Float32,2}:
 0.707107   0.707107
 0.707107  -0.707107

julia> H * qubit
2-element Array{Float32,1}:
 0.70710677
 0.70710677

Taking it a step further we can use complex numbers natively. For example, we are able to define the gate[^sqrtnot] almost as easily:

julia> halfX = Float32(0.5) * [1+im 1-im; 1-im 1+im]
2×2 Array{Complex{Float32},2}:
 0.5+0.5im  0.5-0.5im
 0.5-0.5im  0.5+0.5im

julia> halfX * qubit
2-element Array{Complex{Float32},1}:
 0.5f0 + 0.5f0im
 0.5f0 - 0.5f0im

We can test that it’s unitary using the conjugation operator, ', and the @test macro:

julia> using Test
julia> @test halfX'*halfX ≈ [1 0; 0 1]
Test Passed

It’s normal in Julia to use Unicode characters directly. This is strange at first but makes formulas very succinct. In the above test we used the ≈ character⁴ to perform a machine-precision equality test.

Being a functional language, it’s straightforward to turn our operators into functions. X is the quantum NOT operator:

julia> X = (qubit) -> Float32(1) * [0 1; 1 0] * qubit
#3 (generic function with 1 method)

julia> @test X(X(qubit)) ≈ qubit
Test Passed

This language really is a close to perfect for my project! Serendipity[^serendipity] is a wonderful thing.

> brew cask install anaconda
...
> brew postinstall python3
...
> brew install jupyter
...

To use Julia inside Jupyter you need to have Julia itself installed locally, if you don’t then install it with Homebrew:

> brew cask install julia
...

To link it up then go into the Julia REPL julia and then import the IJulia package:

julia> import Pkg; Pkg.add("IJulia")

Then should then be able to run Jupyter jupyter notebook and Julia will be amongst the options when creating a new notebook.

After seeing an article come up again on the subject it got me thinking about its title caption: how long can it be maintained? Or, more concretely, can I compile and run a COBOL program on my laptop? I’d only ever see it running on Mainframes behind green-screen terminals and choose-your-own-adventure-style TSO screens. Well, it turns out the answer is YES, and in fact it’s very simple. This is how I did it.

> brew install gnu-cobol

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLO-WORLD.
000300 PROCEDURE DIVISION.
000400      DISPLAY 'Hello, world!'.
000500      STOP RUN.

> cobc -x hello.cob
> ./hello
Hello, world!

First let’s make the leap to Neanderthal so that it can do our matrix manipulations for us. It turns out to be quite straight forward. The first step is to add the dependency:

(defproject qucl "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.10.0"]
                 [uncomplicate/neanderthal "0.23.1"]]

  :exclusions [[org.jcuda/jcuda-natives :classifier "apple-x86_64"]
               [org.jcuda/jcublas-natives :classifier "apple-x86_64"]])

A couple of the libraries required by Neandertal don’t have native builds for Mac in the standard repositories which gives us dependency errors. Since their not needed right now, we can safely exclude them.

To work with Neanderthal the Qubit will be a vector of floating point numbers fv, rather than a map. The choice of floats rather than doubles is deliberate, floats are faster but, more importantly, take up less memory than doubles and the exponential nature of quantum vectors means that quantum simulators tend to be memory bound.

(defn Qubit []
  (fv 1.0 0.0))

For the measurement we’ll just use the first entry of the vector:

(defn- prob-zero [qubit]
  (* (entry qubit 0) (entry qubit 0)))

And for the gates we’ll use Neanderthal’s built-in matrix multiplication functions, in this case multiplying a dense matrix (created with the fge function) with the qubit vector using the mv function. For example or X gate becomes:

(defn X [qubit]
  (mv (fge 2 2 [0 1 1 0]) qubit))

And the Hadamard gate is similar but scaling with the in-place scal! function:

(defn H [qubit]
  (mv (scal! oosr2 (fge 2 2 [1 1 1 -1])) qubit))

With these changes the tests continue to function without change and we’ve been able to remove own own linear algebra implementation and replace it with Neanderthal instead. Happy with that.

The next step is to build some more gates but for that we’ll need to use complex numbers. Essentially a quantum computing simulation is linear algebra using complex variables. Neanderthal is a fast and efficient linear algebra library but it uses doubles and floats as approximations of reals so we need a way to manipulate complex vectors and matrices. How can we use Neanderthal to do that? Well first note that a complex vector can be separated into real and imaginary parts. We can take a pair of matrices or vectors and store them in a simple map of real and imaginary values.

(defn- complexify
  ([real]
   {:real real :imag (zero real)})
  ([real imag]
   {real real :imag imag}))

If we receive only one initial value then assume it’s the real part and set the imaginary part to zero. Once we have the separate real and imaginary values we can multiply, for example A and x like this:

In computational terms, that’s four floating point multiplications and three floating point additions. We can take advantage of Neanderthal’s compound add and multiply function axpv as well. Let’s see what that looks like in code:

(defn- complex-mv [A x]
  (complexify (axpy -1 (mv (:imag A) (:imag x)) (mv (:real A) (:real x)))
              (axpy (mv (:real A) (:imag x)) (mv (:imag A) (:real x)))))

A bit complicated but there is a lot of symmetry there. We use the new complexify function to convert the Qubit along with the H and X operators into complex valued functions:

(defn Qubit []
  (complexify (fv 1.0 0.0)))

(defn X [qubit]
  (complex-mv (complexify (fge 2 2 [0 1 1 0])) qubit))

(defn H [qubit]
  (complex-mv (complexify (scal! oosr2 (fge 2 2 [1 1 1 -1]))) qubit))

Also the probability calculation must be adapted to calculate the absolute value of a complex number:

(defn- sqr [x] (* x x))
(defn- prob-zero [qubit]
  (+ (sqr (entry (:real qubit) 0)) (sqr (entry (:imag qubit) 0))))

Our tests are passing again using the new complex implementation. So far so good. We’re now in a position to implement some other gates. But we have a problem. Neanderthal doesn’t have a mechanism for performing the Krondecker product and we’ll need that for creating the composite operators. Not sure what to do about that so I’m going to leave it there for now until I come up with a better plan ;)

Quko worked out pretty well and I was able to repeat some of the standard results with a small number of qubits. A naïve implementation will never be particularly efficient but I didn’t really care as that wasn’t the goal. Not long ago, however, I stumbled upon a Clojure library called Neanderthal² for doing high performance mathsy stuff and after playing with it for a while I was impressed by how easy it was to get started³. Since I’m also learning Clojure I thought I’d rewrite Quko in Clojure to practice the language and get a more powerful simulator to boot. This blog series will be my way of remembering what I did, the mistakes and the successes along the way.

We’ll start with a simple case of an 8-sided quantum die. This is the code written with the Quko library (from the README):

val qubits = Qubits(3).hadamard(0..2)
print(qubits.measureAll().toInt())

Written in Clojure this becomes⁴:

(def qubits (H (Qubits 3) (range 0 2)))
(print (to-int (measure-all qubits)))

Obviously this doesn’t compile because we’ve not written any code yet (see appendix) so lets start building out the implementation with unit tests. In fact we will start with a very simple test for a single qubit which ensures that its default value is 100% true. Remember qubits are probabilistic animals but we don’t want to expose the underlying implementation to the outside world. For that reason in the test we’ll take a count of multiple samples and compare the result with what’s expected rather than interrogating the qubit’s internals directly.

(ns qucl.qubits_test
  (:require [clojure.test :refer :all]
            [qucl.qubits :refer :all]))

(defn sample [source-function num-samples]
  (count (filter true? (repeatedly num-samples source-function))))

(deftest measure-should
  (is (= 0 (sample-qubit #(measure (Qubit)) 100)))

We can make that pass trivially, of course, just returning 0 from measure.

(defn Qubit [])

(defn measure [qubit] false)

Next we’ll triangulate to get some more behaviour. The simplest way to do that is to apply a not or X operation⁵ and expect the opposite result.

  (is (= 100 (sample-qubit #(measure (X (Qubit))) 100))))

The easiest way to make this pass is to make Qubit have a binary value and negate it.

(defn Qubit [] false)

(defn X [qubit]
  (not qubit)

(defn measure [qubit]
  qubit)

The tests pass. One nice thing about Clojure is that we can also take advantage of the REPL to try our code. In this case we get the answers we expect.

(measure (Qubit))
=> 0
(measure (X (Qubit)))
=> 1
(measure (X (X (Qubit))))
=> 0

Now we have our tests passing we can introduce some theory. The qubit is a structure with two (possibly complex) variables⁶, the absolute values of which are the probabilities of measuring 0 or 1 respectively. For the moment the variable will only need real values and is represented by two real numbers :0 and :1. This could be considered a vector with named indices. The X operation swaps the variables so the probability of measuring 0 becomes the probability of measuring 1 and vice-versa.

(defn Qubit []
  {0 1.0 :1 0.0})

(defn X [qubit]
  {:0 (:1 qubit) :1 (:0 qubit)})

The measurement will now be a random process which picks 0 or 1 with the appropriate frequency. The probability of measuring a 0 is |:0|.

(defn- prob-zero [qubit]
  (* (:0 qubit) (:0 qubit)))

(defn measure [qubit]
  (if (<= (rand) (prob-zero qubit)) false true))

The implementation of X is a degenerate case of a more general fact. One of the central tenets of quantum operators or gates is that they can be represented by matrix multiplication⁷. Let’s do it that way so that we can slot in other gates much more easily. We define a matrix which inverts the two numbers:

And a test to ensure that our code does indeed invert the entries:

(def X {00 0 :01 1 :10 1 :11 0})

(deftest matrix-mult-test
  (is (= (matrix-mult X {0 0 :1 1})
         {0 1 :1 0})))

An implementation of that using the normal rules of matrix multiplication would be:

(defn matrix-mult [A x]
  {
    (+ (* (:00 A) (:0 x)) (* (:01 A) (:1 x)))
    (+ (* (:10 A) (:0 x)) (* (:11 A) (:1 x)))
  })

Now we can reimplement the X function using our matrix:

(defn X [qubit]
  (matrix-mult {00 0 :01 1 :10 1 :11 0} qubit))

Great. The tests are still passing and we are now in a position to add new gates, for example the very useful Hadamard (H) gate that we need for the die. The Hadamard gate takes the qubit to the equator of the Bloch Sphere and, since it’s unitary, applying it twice takes us back to the start. We can capture that in a test⁸:

(deftest measure-should
  (is (= 50 (sample 100 #(measure (H (Qubit))))))
  (is (= 0 (sample 100 #(measure (H (H (Qubit))))))))

In this case the matrix for the transformation (still real numbers) is:

We can implement it, for example, in this way.

(def ^:const oosr2 (/ 1 (Math/sqrt 2)))
(defn H [qubit]
  (matrix-mult {:00 oosr2 :01 oosr2 :10 oosr2 :11 (- oosr2)} qubit))

OK, so we have built our Qubit and a couple of gates, X and H, to manipulate it. With this code we’ve advanced quite a bit and can already simulate a quantum coin toss. In the REPL we can do:

(defn coin-toss [] 
  (measure (H (Qubit))))
=> #'qucl.qubits/coin-toss
(coin-toss)
=> true
(repeatedly 10 coin-toss)
=> (false false false false true true true true false false)

Going back to the original feature test, we can also now simulate an 8-sided die simply by tossing a coin 3 times and interpreting the result as binary. We could do this in the REPL:

(defn to-int [& b]
  (reduce (fn [acc v] (+ (* 2 acc) (if v 1 0)))
          0
          b))
=> #'qucl.qubits/to-int
(apply to-int (repeatedly 3 coin-toss))
=> 7
(apply to-int (repeatedly 3 coin-toss))
=> 3

Not a bad start but there’s still a lot to do. To implement our feature test completely we need to be able to combine Qubits. We’ve some way to go and the next steps will be to introduce Neanderthal and complex numbers but I’ll leave that for next time.

(defn to-int [qubits]
  (throw (UnsupportedOperationException)))

We start, as you might imagine, with a new project:

lein new hello-clojure

We need to add the dependencies to the main project.clj file as well as the name of the main class¹ that we’ll run to start the server:

  :dependencies [[org.clojure/clojure "1.9.0"]
                 [com.sparkjava/spark-core "2.7.2"]
                 [org.slf4j/slf4j-simple "1.7.13"]]
  :main hello_clojure.core)

Clojure is interoperable with Java but not to the same extent that Kotlin is. To overcome the differences I used a couple of adapters from neat clojure code to Spark’s Java classes².

(ns hello_clojure.core
  (:gen-class)
  (:import (spark Spark Response Request Route)))

(defn route [handler]
  (reify Route
    (handle [_ ^Request request ^Response response]
      (handler request response))))

(defn get [endpoint routefn]
  (Spark/get endpoint (route routefn)))

Then we’re ready to create the controller which we do from the main method so that it’s easy to invoke from the command line. Note also that in the above we used the gen-class directive to ensure the main class in the Manifest is correct:

(defn -main []
  (get "/sayHello" (fn [req resp] "Hello World!!")))

To simplify the generation of the service we can build a self-contained jar using Leiningen.

> lein clean && lein uberjar

As before, we first check that the service works as normal Java:

$ java -cp target/hello-clojure-0.1.0-SNAPSHOT-standalone.jar hello_clojure.core
...
[Thread-0] INFO org.eclipse.jetty.server.Server - Started @1033ms

> curl localhost:4567/sayHello
Hello World!

Compiling to a native image is as simple as the previous examples with Java and Kotlin.

> native-image -cp target/hello-clojure-0.1.0-SNAPSHOT-standalone.jar hello_clojure.core
Build on Server(pid: 35646, port: 53994)*
[hello_clojure.core:35646]    classlist:   2,704.82 ms
[hello_clojure.core:35646]        (cap):     909.58 ms
...
[hello_clojure.core:35646]        write:     647.23 ms
[hello_clojure.core:35646]      [total]:  54,900.61 ms

And run it:

> ./helloworld_clojure
...
[Thread-2] INFO org.eclipse.jetty.server.Server - Started @2ms

> curl localhost:4567/sayHello
Hello World!

Once again the native binary is roughly 15M but again the start-up time is almost instantaneous. This is a very attractive combination of technologies and worth more investigation.

To warm up lets compare these two different ways of defining a function in Clojure:

(defn greet [name] (str "Hello, " name))

(def greet (fn [name] (str "Hello, " name)))

With the Kotlin equivalent:

fun greet(name: String) = "Hello, " + name

val greet = { name: String -> "Hello, " + name }

The syntax is quite different, of course, and Kotlin requires typed parameters where Clojure is dynamically typed. This can be a blessing and a curse but that’s a discussion for another day. Idiomatic Kotlin would also use built-in string templates instead of concatenation but the similarities nonetheless stand out.

Let’s get into the example. First define the neighbour offsets. In Clojure vector instantiation is quite neat (this is formatted manually to show the pattern).

(def neighbours
  [[-1,  1] [0,  1] [1,  1]
   [-1,  0]         [1,  0]
   [-1, -1] [0, -1] [1, -1]])

(defn neighbours-of [x y]
  (set (map (fn [[x-offs y-offs]] [(+ x-offs x) (+ y-offs y)])
            neighbours)))

(defn generate-cell [neighbours y x]
  (if (contains? neighbours [x y]) 1 0))

In Kotlin to do the same is slightly more verbose². We can use Pairs (tuples) and typealiases here to improve the readability.

typealias Cell = Pair<Int, Int>
typealias Cells = Collection<Cell>

var neighbours =
        setOf(Cell(-1,  1), Cell(0,  1), Cell(1,  1),
              Cell(-1,  0),              Cell(1,  0),
              Cell(-1, -1), Cell(0, -1), Cell(1, -1))

fun neighboursOf(x: Int, y: Int) =
        neighbours.map { (xOff, yOff) -> Cell(xOff + x, yOff + y) }

fun generateCell(neighbours: Cells, y: Int, x: Int) =
        if (neighbours.contains(Cell(x, y))) 1 else 0

The thing to note is the use of the map function in both implementations. The parameters are effectively reversed. We’ll see some implications of this later. Next we’ll see some currying (the focus of the article):

(defn generate-line [neighbours width y]
  (map (partial generate-cell neighbours y)
       (range 0 width)))

(defn generate-board [dimensions neighbours]
  (mapcat (partial generate-line neighbours (dimensions :w))
          (range 0 (dimensions :h))))

And in Kotlin:

fun generateLine(neighbours: Cells, width: Int, y: Int) =
        (0 until width).map { x -> generateCell(neighbours, y, x) }

fun generateBoard(h: Int, w:Int, neighbours: Cells ) =
        (0 until h).flatMap { y -> generateLine(neighbours, w, y) }

Things to note: - The partial function in Clojure translates naturally to lambda expressions in Kotlin. - While the map function is the same, mapcat becomes flatMap in Kotlin. - It seemed easier in Kotlin to pass h and w as simple parameters rather that inside map. I wonder what the reasoning behind this is and whether it’s a common style in Clojure. - We can use the range operators directly in Kotlin. I actually prefer range as a function too but it’s less idiomatic in Kotlin.

The next bit is much the same:

(defn mine? [cell]
  (= \* cell))

(defn board-for-cell [dimensions y x cell]
  (generate-board dimensions (if (mine? cell) (neighbours-of x y))))

(defn boards-for-line [dimensions line y]
  (map (partial board-for-cell dimensions y)
       (range 0 (dimensions :w))
       line))

Compared to the Kotlin version:

fun isMine(cell: Char) =
        '*' == cell

fun boardForCell(h:Int, w:Int, y:Int, x:Int, cell:Char) =
        generateBoard(h, w, if(isMine(cell)) neighboursOf(x,y) else emptyList())

fun boardsForLine(h:Int, w:Int, line:CharSequence, y:Int) =
        (0 until w).map { x -> boardForCell(h, w, y, x, line[x]) }

Here we can again see the difference between the map functions mentioned earlier. Clojure allows multiple ranges for the map operation, essentially ziping them together for you. It’s an interesting idea. Note that Kotlin also requires that boardForCell() return a result where Closure does not, defaulting to nil. Kotlin spurns nulls and in any case I prefer this approach.

Now the fun part.

(defn sum-up [& vals]
  (reduce + vals))

(defn draw [input-board]
  (let [lines (str/split-lines input-board),
        dimensions {:h (count lines), :w (count (first lines))}]
    (->> (mapcat (partial boards-for-line dimensions)
                 lines
                 (range 0 (dimensions :h)))
         (apply map sum-up))))

This combines several concepts that were new to me, ->> and apply together with the tricky (for me) map function and some magic with the varadic arguments. It took a while to understand what was going on here and in fact my first couple of naïve attempts didn’t work at all. Since the aim was to get as close to the Clojure code as possible this is what I finally came up with:

fun sumUp(vararg vals: List<Int>) =
        vals.reduce { acc, v -> acc.zip(v) { a, b -> a + b } }

fun draw(inputBoard: CharSequence): List<Int> {
    val lines = inputBoard.split("\n")
    val h = lines.size
    val w = lines.first().length
    val boards = (0 until h).flatMap { y -> boardsForLine(h, w, lines[y], y) }
    return sumUp(*boards.toTypedArray())
}

Things to note: - Spreading of varadic arguments (with the * operator) only works for arrays in Kotlin so I had to convert the list to a typed array. In Clojure it seems that it’s very easy to spread varadic arguments and there is a big difference between spreading a list and taking a single List argument although it appears very similar. - It doesn’t help that there are no types on the Clojure version of the sumUp() method. I have found that I lean heavily on strong typing but I’ll struggle on :) - There is something attractive about that Clojure code, as compared to the Kotlin version, that I’m not sure I’m fully appreciating yet. However if we don’t make the sumUp function variadic (and make it an extension function instead) then the implementation becomes simpler and matches the Clojure version a little more closely.

fun List<List<Int>>.sumUp() =
        this.reduce { acc, v -> acc.zip(v) { a, b -> a + b } }

fun draw(inputBoard: CharSequence): String {
    val lines = inputBoard.split("\n")
    val h = lines.size
    val w = lines.first().length
    return (0 until h).flatMap { y -> boardsForLine(h, w, lines[y], y) }
            .sumUp()

The rest of the exercise consists of manipulating and merging the output to give the final result:

(defn cell-as-text [cell-value]
  (if (zero? cell-value) \space (str cell-value)))

(defn overlay-cell [top bottom]
  (if (mine? top) top bottom))

(defn overlay-boards [top bottom]
  (reduce str (map overlay-cell top bottom)))

(defn draw [input-board]
  (let [lines (str/split-lines input-board),
        dimensions {:h (count lines), :w (count (first lines))}]
    (->> (mapcat (partial boards-for-line dimensions)
                 lines
                 (range 0 (dimensions :h)))
         (apply map sum-up)
         (map cell-as-text)
         (partition (dimensions :w))
         (map (partial reduce str))
         (interpose \newline)
         (reduce str)
         (overlay-boards input-board))))

Translated directly to Kotlin’s built-in functions it looks something like this:

fun cellAsText(cellValue: Int) =
    if (cellValue == 0) " " else cellValue.toString()

fun overlayCell(top: Char, bottom: Char) =
    if (isMine(top)) top else bottom

fun draw(inputBoard: CharSequence): String {
    val lines = inputBoard.split("\n")
    val h = lines.size
    val w = lines.first().length
    return sumUp((0 until h).flatMap { y -> boardsForLine(h, w, lines[y], y) })
            .map(::cellAsText)
            .chunked(w)
            .map { it -> it.joinToString("") }
            .joinToString("\n")
            .zip(inputBoard)
            .map { (a,b) -> overlayCell(b, a) }
            .joinToString("")
}

Here Clojure’s partition function is replaced by Kotlin’s chunked function and str with string functions like joinToString. Once again Clojure’s multi-argument map function does not have a direct translation in Kotlin so we use zip to merge the result with the initial board to generate the final results. To get something more closely resembling thr Clojure code we can take advantage of Kotlin’s extension methods. We’ll need to create some helper methods.

fun str(a: CharSequence, b: CharSequence) = listOf(a, b).joinToString("")

fun List<CharSequence>.interpose(sep: CharSequence) =
        this.flatMap { it -> listOf(sep, it) }.drop(1)

An then use them to build the data pipeline:

fun CharSequence.overlayBoards(other: CharSequence) =
        other.zip(this, ::overlayCell).joinToString("")

fun draw(inputBoard: CharSequence): String {
    val lines = inputBoard.split("\n")
    val h = lines.size
    val w = lines.first().length

    return (0 until h).flatMap { y -> boardsForLine(h, w, lines[y], y) }
            .sumUp()
            .map(::cellAsText)
            .chunked(w)
            .map { it -> it.reduce(::str) }
            .interpose("\n")
            .reduce(::str)
            .overlayBoards(inputBoard)
}

Using extension methods has allowed us to put the other functions like interpose and overlayBoards into the pipeline giving us an effect similar to Clojure’s thread-last operator.

We can check the output by calling the draw function from main:

fun main(args: Array<String>) {
    println(draw("*   \n *  \n  * \n   *"))
}

And it does indeed, in case you’re wondering, give us the results we expect.

*21 
2*21
12*2
 12*