Accurate budgeting (by alaric)

If you are paid monthly, then it makes sense to work on a monthly budget. Many expenses are paid monthly, so this works out quite nicely.

However, some things are paid quarterly, or even yearly. If those things are big enough that they can't just disappear into the noise of your monthly budget, you need to budget for a share of them each month, and put that money aside somewhere to save up for the annual costs.

And some things are paid weekly, or (worse) every four weeks. We used to have a self-storage room that cost us about two hundred pounds every four weeks, which was a royal pain as sometimes this meant we paid £200 a month, and sometimes £400. It was hard to lose THAT in the noise.

So, I decided to write some software to work all this out for me.

Read more »

Old Papers (and maths!) (by alaric)

This weekend, I've been going through old papers and dealing with them. This involves sorting them into three categories:

1. To be shredded and turned into logs with our log maker
2. To be filed in the cabinet (with many subcategories corresponding to the files therein), and sorted by date where applicable
3. Demanding some action (which, for now, means putting them into my in-tray, rather than disrupting the activity in progress)

The magnitude and importance of this task is not to be underestimated - when we moved here I had a new baby, a very sick wife, and two jobs to deal with; unpacking and properly setting up my office never really happened, as opposed to setting up a desk and digging through boxes to find the things I needed to get started. So my once-pristine filing system was never quite established, and my "to file" tray grew fat with paperwork I needed to put somewhere. There was slow progress, of course; but then two years later the house flooded, so we had to rush a lot of furniture and stuff from downstairs up into the office, then pack a lot of stuff up and send it into storage while the house was repaired... and we weren't living in the house for nearly a full year, so more often than not I was working on my laptop from wherever I could get an Internet connection. Once again, my paperwork was in disarray.

But, three years on, we're finally catching up. I've gone through my filing cabinet and re-filed the mish-mash therein, then gone through my to-file tray and the various piles of papers dotted around the place, and dealt with them all. "To shred" has been by far the biggest category; as I write, Sarah is sitting feeding sheet after sheet into the shredder. And I've found a bunch of interestings that need further action.

For one of them in particular, the action is to write it up. Many years ago, I bought and read a book on statistics in order to refresh my memory, as I was working on a system for analysing the actions of large numbers of people. Now, I didn't enjoy statistics much when I was doing A-level maths, and reading the book reminded me why: I find the random-variable notation unnecessarily vague and confusing, and the various other notations used in statistics seem inconsistent to me.

I recall reading this book on a long bus journey (the bus from Tottenham Court Road to Gallows Corner in Romford, to be precise), and deciding to take matters into my own hand, and designing m own notation for statistics based on set theory. I like set theory and find it sensible and logical, so this was an obvious choice. I wrote my notation down on a sheet of paper, tucked it into the book, and took it home.

Many years later, I found the sheet of paper inside the book, and put it in my TODO pile, as I needed to take a second look at it and do something with it. This never happened. Until now.

So without further ado, here's the content of the sheet. It still needs more thinking about, but if I write it up into the computer now, this is more likely to happen than waiting for me to encounter this bit of paper again.

Let L be a multiset of real numbers.

• SUM(L) = sum of x, where x is an element of L.
• |L| = the number of elements in L.
• L(n) where 1 <= n <= |L| = nth largest element of L
• MIN(L) = L(1)
• MAX(L) = L(|L|)
• MEDIAN(L) = L(|L| / 2) if |L| is odd, (L(floor(|L| / 2)) + L(ceil(|L| / 2)))/2 otherwise
• SUM^2(L) = sum of x^2, where x is an element of L
• VAR(L) = SUM^2(L) - (SUM(L))^2 etc.
• L ~ D iff L is distributed as per D (D is a distribution as per normal stats notation)
• SRn(L) is a multiset of all possible sets of n random samples from L with replacement
• SWn(L) is a multiset of all possible sets of n random samples from L without replacement

Let L be a multiset of records (named tuples) of real numbers (a,b,c,...)

• La is a multiset of just the as
• Lab is a multiset of the products, a*b
• sigma(L) f(a,b,c) is the sum of f(a,b,c) across all the elements in L
• pi(L) f(a,b,c) is the product
• L ~ (D1, D2, ...) iff. La ~ D1 and Lb ~ D2 and so on
• cov(a,b)(L) = sigma(L) ab - M(La)*M(Lb)

...and there it ends!

Electricity bills and heating (by alaric)

We changed electricity supplier recently, which is great, but the downside is that I've just noticed a bounced direct debit from NPower (the old one) for £661 on our joint account, to clear our remaining balance 🙁

We were paying a regular direct debit of £130 a month, which we tried to keep to by not being wasteful with the hot water (electrically heated) and by rationing the use of the fan heater (which at 3kW costs just under 50p an hour to run, which at the planned four hours a day comes out to £60 a month, the rest being our normal 'summer' power consumption)

I've no idea how we've gone £661 over in the past year 🙁 I can't find my old workings, but I know my estimate of our summer power consumption involved a lot of guesswork, and I was uncertain as to how many months of the year we'd run the heater for... but it looks like we won't be able to afford to run the fan heater at all this winter; thankfully, we've managed to plug a lot of the draughts in the house, and I'm going to try and arrange secondary double glazing (be it nice sheets of plastic mounted properly... or bubble wrap pinned to the window frames), so hopefully we'll be able to get by with the coal fire downstairs, which normally gets through something like £5 worth of coal a day.

I'll be more frugal with the gas heater in my office, too - last winter, it was used to great effect (especially once we'd managed to close the warped window properly so there wasn't a huge draught), but the office is a high-ceilinged room so a lot of empty space has to be filled with warm air before I feel much of it. I budgeted for one £15 cylinder a month, but we ended up using one about every ten days, from memory.

By comparison, Sarah's electric blanket only uses a sixty or so watts, and keeps her toasty warm all night! Which just goes to show how much of the heat from a room heater goes to heating the walls and air, rather than heating us. I need to get some time to refit Sarah's heated jacket with a cable to plug into a plugtop PSU so she can be kept warm without needing to get through batteries like they grow on trees...

Portable computers (by alaric)

I like the iPad hardware; shame about the crippled iOS software. Similarly, I like the Kindle hardware - shame about the restrictive DRM system.

But the biggest shame is that I'm actually tempted to own three or more different computing devices, purely because of different situational specialisations in the hardware. A smartphone (or, more ideally, a wearable computer) for real-time pervasive tasks. A tablet device for portably viewng stuff on (whether it's ideally electronic ink or a nice colour LCD really depends on what I'm viewing) . A laptop for actually working on... ideally a small one for portability and a larger one for power (both in terms of CPU+RAM and in terms of more screen real estate). Plus remote servers that store a significant part of my data since it needs to be available to others in some way (this blog, my email, etc).

But this sucks - there's a lot of duplication of hardware (mass storage and CPU power) there, when I'll only really be using one device at a time. And there's an annoying duplication of data that needs to be "synched" between things. And an annoying variation of user interface, as different devices often have very different models of storage management.

Here's what I'd love to have:

In my pocket sits a smartphone. It might have a Blackberry-style keyboard or an iPhone-style touchscreen, depending on taste. It has a small computer to run its apps, and a battery, and the usual Bluetooth/USB/GSM/etc interfaces. And it has a wodge of Flash to store my stuff.

Maybe it has enough Flash to store all my stuff. Maybe it doesn't in which case, I might also carry a featureless cuboid that contains batteries and a lot of flash, or even a hard disk, or some combination of the two. In which case, my phone is slaved to it - using its own internal flash to cache resources fetched from the storage box, and accessing it via Bluetooth or some more advanced personal-area radio network; but when it's plugged into the storage box via USB, it can access it more speedily, and suckle power from the larger battery.

Perhaps I'm lucky enough to also possess a head-up display (which also functions as a headset for audio), and/or a chord keyer, that talk to the smartphone via radio or wired links. They're just extra I/O devices that plug into it, though.

But maybe I own a tablet computer, or an electronic paper device. They might have their own internal storage, but I'd slave them to my phone, or direct to my storage box (slaving to the phone, if the phone is slaved to the storage box, just slaves them to the storage box, in effect), and use their local flash as a cache. Also, if I don't like their file-browsing interfaces, I can just use the phone to select a file and "send" it to any willing device reachable through the slaving relationships, which causes it to access the file (from the original source) and open it up. The file isn't actually "sent", it just seems that way (except faster, and with a single central copy if I start editing it).

But what of the laptop? Or my big, powerful, desktop machine? Let them be slaved to my phone or my storage box, too. Take my home directory and installed apps from my central storage. Then there's no synching of address books and all that. There might be files in my phone that only laptop-scale software can manage, which I then can't open on the go, but I can at least use my portable devices to email a copy to a colleague who needs one, and to open simpler types of files that happen to be associated with the same project. They can talk to my storage box via a wireless link within range, or I can hook my storage box, phone, etc. up to it via cables for high-speed communications and power distribution.

What will it take to do this? Some cleverness to negotiate which device should give which power when they're joined by a cable (easy if one of them has access to mains power, trickier to decide if they're both battery devices; perhaps the default should be to not share power at all unless asked to by the user or unless the battery of one device is flat, turning it into a non-self-powered device). But it's mainly down to standardising file systems and protocols. Working at the "USB mass storage device" level is a bad idea, as only one device can have such a filesystem mounted. It needs to be more like NFS. And, mainly, devices and desktop OSes need to let go of managing their own filesystem and learn to use a shared standard for home directory layout - which will NEVER happen for legacy systems, but at least they can mount your mobile data store as "My Documents" or something like that, and perhaps make some effort to invisibly sync between their own personal-information databases and whatever's in there.

There'll still be some need for syncing - my email and blog, and shared work stuff like Git repos and group calendars, have to be on servers somewhere. And there's a good reason to mirror my portable storage to somewhere else whenever I can, as a backup. But the less syncing, the better!

Syntax diagrams (by alaric)

I've always liked syntax diagrams as a way of describing languages. They make it clear what options are legal in any given situation.

However, drawing them by hand is tedious, so after a moment's thought, I realised it would be pretty trivial to design a reasonable layout algorithm to generate them automatically.

And so, on a train journey, banterpixra was born!

It's quite simple. It takes a BNF-esque grammer, encoded in s-expressions like so:

(rule
 . (choice
    rule-label
    literal
    (seq "(elidable" " " literal ")")
    (seq "(optional" " " rule ")")
    (seq "(zero-or-more" " " rule ")")
    (seq "(one-or-more" " " rule ")")
    (seq "(seq" (one-or-more (seq " " rule)) ")")
    (seq "(choice" (one-or-more (seq " " rule)) ")")
    (seq "(optional-choice" (one-or-more (seq " " rule)) ")")
    (seq "(comment" " " literal " " rule ")")))

...and it turns it into a nice syntax diagram, rendered as an SVG file. I found producing an SVG to be a very easy way of generating vector images - SVG is quite a decent format to generate, and inkscape will happily convert .svg files to .png and .pdf from the command line, so it's easy to automate rendering.

The layout algorithm is quite easy. The BNF is parsed, and a tree of layout objects generated from the bottom up. Layout objects may contain other layout objects, recursively, and cover a rectangular extent of the two-dimensional plane. New layout objects are created at the origin, and then the parent layout looks at the sizes of the child layouts within it, and relocates them to appropriate locations within itself. When the layout object tree has been generated, it's processed top-down to generate actual SVG. Each different type of layout object renders its children recursively (unless it's a terminal, in which case it just renders itself at the chosen location), then it adds the arrows and lines that join the children together.

That's really all there is to it.

The output is quite decent, if your browser supports SVG!