The Collatz conjecture, visualised in Clojure

Before I begin, watch the video that prompted me to do this in the first place.

Okay, now you know what I’m talking about, the Collatz conjecture. It’s scarily simple, you take a number, if it’s even you halve it, if it’s odd you multiply it by three and add one. Repeat this and you will end up at one, every time. Well, that’s the conjecture, maybe it doesn’t end up at one for some numbers, we just haven’t been able to prove it.

The video shows a beautiful way of visualising this problem and I felt it was a nice thing to try and render with some code. If you’ve read any of my previous things or know me even a little, Clojure is not a surprising choice of tool, I love the language and think it is well suited to most, if not all, problems I face.

I must warn you that I never reproduced the one from the video, just something that follows the same ideas and looks kind of similar from a distance. I honestly can’t work out what magic was used to get it to look that good, maybe some special rendering techniques that are just beyond me at the moment. Maybe you’ll be able to take my repository and perfect it!

Collatz in Clojure

Before I even attempt to render this, I’ll need some functions that generate the Collatz conjecture numbers. I will refer to these as a Collatz sequence or Collatz seqs. You can find the full code in Olical/collatz, but I will be breaking it down here for you.

This function provides a lazy sequence abstraction on top of the ideas the Collatz conjecture provides. It allows us to build more interesting things on top of the seq abstraction without worrying about memory or implementation details.

The next logical step from here, in my opinion, is to create a lazy-seq of Collatz seqs. So if I ask for (collatz-tree 10000) I will get a seq of seqs. The first item is the same as (collatz 10000), the second is (collatz 9999) and the third being (collatz 9998). You get the idea. What we are left with is a seq abstraction which, if fully realised, would be pretty huge. Luckily, thanks to the magic of lazy sequences, almost nothing will actually be in memory at any one time.

We can walk this tree, or seq of seqs, to render the visualisation you saw in the video. Or something close to it I hope, I’m no expert with Quil, but I’ll try my best.

The commit at this point was 4a155ed. Feel free to take this abstraction and do what you want with it, copy and paste it into your project if that’s easiest.

Visualising the tree

Now for the pretty part. I hope. I’m starting with the default Quil setup the lein template provides you with, this includes the functional middleware which makes it a bit nicer to work with (although I found I wasn’t really using the state management very much at all). After a little bit of tinkering I ended up with this rough attempt.

An early render. Kinda ugly and slow to render. Commit was 299f062.

Although if you squint, this sort of looks similar, I’m not very happy with it. For starters, my use of the Quil API is a bit questionable and it definitely doesn’t follow the same rules as the one in the video. My ideal goal is to basically mimic the original material including random colours. I really hope this doesn’t breach copyright or something, if so, I’m very sorry, send me an email.

Here’s what I had after some more tinkering.

It’s still not right, but it looks better. Commit was 8e5a42c.

Although I’m generating the bordered lines with a sort of hack (one bigger black line with a smaller coloured line on top of it), it actually leads to this neat hand drawn effect. So, although it’s not right, I actually like the outcome. It feels more organic than hard, anti-aliased, machine cut edges. To me, anyway.

It definitely looks better now, but it’s still not true to the original. A huge problem with this is that I’m drawing back over lines so many times, I need to optimise the tree so I don’t repeat myself, this requires a different approach to rendering though, I need a sort of linked list I can follow so I know when I’m back to somewhere I’ve been before and can stop rendering that path.

That’s going to mean forgoing a bit of laziness and building a big data structure that I can use as a lookup table, I think it’s worth it for the rendering optimisations. That should allow me to render the branches in different orders too instead of largest to smallest.

Epiphany time

Two things happened while developing this project and writing this post (I’ve been writing it as I developed it to capture every step, so it may seem a bit jumbled in places).

First, I realised that the tree was upside down. The end of any Collatz seq is always one (we think?), if you remember my code from earlier, I iterate over these sequences and draw the segments of the branch one at a time. This means every branch ends with one, but it needs to start with one.

The other thing that happened was one of the authors of the book that inspired the video that inspired me, Edmund Harriss, replied to one of my tweets with a couple of tips I’ll probably need after I fix the whole upside down problem.

Just as a reminder, this is what I want it to look like.

The original from the video, saved from this tweet.

Flipping the tree

So I want to get it looking semi-accurate before I try to optimise, maybe the optimisations won’t actually be required it it’s “good enough”. I’m going to flip the tree by reversing the Collatz sequences that comprise my “Collatz tree” sequence.

Sadly, even after flipping the tree over and playing around with more parameters, I just couldn’t match the awesome original design. I guess this is a testament to how good the original authors are at creating visualisations from math alone! Here’s a few things I ended up with to wrap up my stumbling in the dark.

It’s still wrong, but looks kinda nice. Commit was 185a3ff.
More curve, but not what I want. At e9dad26.
Thinner lines to illustrate just how many I’m actually rendering here. Could be a tad more efficient. Game programmers, avert your eyes. At 2cc37b1.
The spindly version with prime numbers highlighted in green. Pretty neat. At ba6700f.

From the thinner versions you can quite clearly see the need for deduplication, if you just draw everything over the top of each other, not only is it slow, but it also looks messy. I definitely needed to prepare my data a little better, but this post that was supposed to be a small little experiment was beginning to drag on by then.

Close but no cigar

I’m disappointed that I couldn’t get it quite right, although I think I probably could if I just put more time into it. Sadly, visualisations aren’t really my forte or main interest. I’m more of a “programming languages, data structures and text editors” kind of programmer. It’s a little bit niche, okay.

I may revisit this some day and attempt to deduplicate that tree since I think there’s value there in performance and style. Until then feel free to rip the repository to pieces, Olical/collatz, if you didn’t spot it earlier. I’ll post the visualisation code below too, just so you don’t need to go elsewhere to see how badly I messed up, I’m sure this is obvious to someone out there in the wide and wonderful world.

I hope you found this slightly interesting, and at the very least it has passed on the inspiration I had to do something far better than I produced.