Efficient Calendars and space-filling curves.

After demonstrating a useless method for implementing a square magnifier and writing this post, I think I’m going to start a category called Useless Mathematics.

So today, we talk about how to increase your productivity tenfold by revolutionising the traditional calendar layout. Take a calendar. The sequence of days isn’t continuous on the page: it’s broken when months change. You have to turn the page, or switch columns. So if some period of time in your overloaded planning spans across a month change, your calendar becomes messy. You have to write the same thing on both months, you lost track of how long it actually is. It’s a disaster. Wouldn’t it be nice to have a view of your calendar where the whole year is on one page, organised in a continuous fashion?

The idea isn’t new. The Compact Calendar is one solution to it (and a very good one. I use it), but it’s not quite optimal: the flow of days is still interrupted when weeks change. No, we need something better. Useless Mathematics to the rescue.

Basically we are looking for a path (one step per day) that runs continuously through a page, and so that any period of however many days is represented as compactly as possible. And indeed, there is research in mathematics interested in just that: the locality of space-filling curves. So we go to our dearest arXiv and find a good match: “Locality and Bounding-Box Quality of Two-Dimensional Space-Filling Curves“. And in there we learn about the complexity of measuring how compact a curve is, and what candidates are good. And we start up Emacs and do a little SVG+Ecmascript coding.

In the SVG attached (SVG, JS), we show 3 types of curves: Hilbert, Moore and Sierpińksi-Knopp (you can change which curve the program shows by commenting in/out lines at the top of the JS file). Hilbert and Moore are overall the best for our purpose. Sierpińksi-Knopp is conjectured in the paper to have the optimal locality, but has poor bounding-box performance, leaving holes in the calendar which may in fact be useful.

Hilbert:

Hilbert calendar

zoom on January:

Moore:

Sierpiński variations:

Fantastic, no? David Allen eat your heart out.

Notes
* one problem is that the number of days we obtain running the L-system n times is 22n+1. Which means that if you want to show 1 year, you have to have d ≥ 4, i.e. at least 512 days (1 year and 5 months). I don’t know if there are rectangular curves that could work better.

* The SVG uses a masked polyline which at the time of writing works only in Opera.

Appendix: the not-so-stupid part

The code uses the L-system definition of the curves we used. I started with Hilbert and Moore and found the definition in their respective wikipedia pages. Later I moved on to Sierpiński-Knopp, but couldn’t find an L-system definition for it, so I spent a few hours working one out. I don’t know if it’s been done before, but if it hasn’t perhaps this is actually new maths!

Rules:

A -> A+A-B+A

B -> B+A-B+A

axiom: A+A+A+A

terminals (final substitution done at the end applying the rules above):

A -> F+F-F+F-F

B -> F+F-F-F+F-F
F: move forward, -: Turn left 90˚, +: Turn right 90˚
This entry was posted in General and tagged , , , . Bookmark the permalink.