Home

Research

Geek

DVDs

CDs

Books

Nabla

Nabla is Not A Blog, Alright? It's just my random online ramblings, and any similarity is obviously some kind of coincidence. Nothing to see here, move along...

Art in Summer 2010

It's that time of time of year again, so we've been doing our limited art seeing thing. Specifically, we went to the BP portrait competition at the National Portrait Gallery, followed by the Summer Exhibition at the Royal Academy, both of which I tend to enjoy. David came along, and was wonderfully quiet throughout (sleeping through most of the RA!).

The portait competition was happily a bit more varied than last year. Not so much in the way of photo-realism, so there was a bit more opportunity for personality to be expressed. There were a few I didn't care for, but on the whole I really rather enjoyed it.

After brunch at the NPG's rather nice restaurant, we decided we'd attack the Summer Exhibition. We wondered if they'd cope with a push-chair, but it turned out to be fine. Critics have panned it, but I enjoy it pretty much for the same reason as they hate it. I love looking through the higgledy-piggledy of the entries from the hoi polloi in the Weston rooms, and I enjoy looking on in horror at the overpriced rubbish from the more famous artists (special prize here for Tracy Emin's awful, awful tat). Generally, though, I enjoy trying to find those few items I think utterly lovely.

The prices have rather increased this year - what that's doing with a recession, I don't know. So instead of looking at my favourite things that are almost on the edge of affordable (ha!), I thought I'd just ignore price and list my favourites:

Permalink. Posted 22:48, Mon, 19 Jul 2010.

Electronics for Newbies: Oscillator practice

Some people might suggest that the theory of crystal oscillator design should perhaps precede constructing such an oscillator. I thought a) I'd have a go by doing, and b) It's easy, anyway, right?

Consulting Horowitz and Hill plus a minimal bit of research on the internet indicated that I wanted a Pierce oscillator, that you need to get capacitors which match the crystal, and that otherwise the series and feedback resistor hardly matter.

So, I got myself a 4MHz crystal and 32kHz crystal, both with their appropriate capacitors. I used a 10k series resistor, and a 10M feedback resistor. I breadboarded up the circuits, attached my 'scope and... nothing. Hurrah. The 4MHz generated nothing, and the 32kHz generated noise.

So, I lightly investigated the theory, to see which tweaks might make the things work. The 4MHz crystal wasn't too difficult to twist into working. Replacing the 10k series resistor with 220 Ohms (!) made it work, at least some of the time. 220 Ohms is about all I have, otherwise, as most of my resistors are either pull-ups, or current limiters for LEDs - That's all I needed for simple logic circuits, I thought. Either way, it worked, as can be seen in my little picture.

The yellow trace is the power supply. Perhaps I should have put more decoupling in? I'll experiment later. My skimming of the internet, trying to find clues as to the problem lead me to a couple of useful application notes - Microchip's AN849 and ST Microelectronics's AN2867. The former seems to concentrate on debugging broken oscillators, while the latter on using maths to design them right! In my current situation, the former was what I approached first. With the small resistor, I was worried about overdriving, so I moved the resistor to the other side of the capacitor and measured either side of it to get the potential across it (using the exciting 'maths' mode of my 'scope).

It looks like it could be just a little overdriven, or it could just be the way I'm measuring. Of course, measuring all this stuff with an oscilloscope probe is rather fun, since the probes have similar capacitance to the caps actually designed into the circuit! The other fun point is that as it's really just a little feedback circuit, with different gains at different frequencies, the oscillation in a badly designed circuit (e.g. mine) can vary on a per-startup basis. Sometimes there might be no oscillation, and at other times a different mode may appear. I have much to learn!

Finally, I tried my hand at getting the 32kHz crystal working, which had been much more uncooperative. With much faffing, I got it to work (unreliably) with 18pF capacitors, 30M of feedback resistance, and 115k of series resistance. As you can see from the screenshot, it's incredibly noisy. Next stop, I'll look up the theory and do some maths to see if I can make it work better!

Permalink. Posted 21:12, Sun, 27 Jun 2010.

Electronics for Newbies: Oh, silly scope

David L. Jones apparently has too much influence on my life, as for my birthday I got one of those lovely Rigol oscilloscopes. It's still not modded to 100MHz, as I'm not playing with those kinds of frequency. Indeed David Frankau's also having a huge influence on my life (unsurprisingly), since I've hardly played with it, and my birthday was more than 2 months ago.

Still, the use I've had out of it has been terribly helpful. Starting off, I can see the bouncing when I flip a switch, or the logic delay propagation through a chip. I've got a photo of the latter, which just happens to show off my new pride and joy.

Really, though, it's been most useful when debugging, of which I've done more than anything else recently. As a demo, I've now got lovely little screenshots of my wallwart power supply's output, before and after smoothing.

It's interesting to see the way the rectified waveform doesn't have a massively sharp bounce, and the top of the waveform isn't super-smooth-and-symmetrical. Once I've added a smoothing cap, all that's left is a little ripple - about half a volt by the looks of it.

Lovely. Then I tried to show the result of regulation with the MCP1826S. Mucho weirdness. The output level was about right, but it was somehow pulling the input voltage way down, too. And this was with a very light load. That's not right, is it? Hmm. It's getting really hot, too. Since I'm using the dual channels of the scope as voltmeters, it frees my actual multimeter up to measure the current. Several hundred milliamps. That's really not good.

It's pretty happy when I run it off an old 9v battery, but this mains supply makes it go nuts. What does this tell me? It tells me to read the data sheet properly! While these regulators are nicely low drop-out, and are capable of driving pretty big currents, they can only take 6V in. That may be useful for driving low-voltage circuitry, but it seems a little lame for what a 5V regulator can handle. Silly me for not reading the datasheet, and after I've stuck 12-13V across them I'm now left with a couple of TO-220-packaged heaters. They certainly don't do a sensible job of regulation any more.

Anyway, now that I have a little more experience with oscilloscopes, I think it's time for me to go off and play with crystal oscillators....

Permalink. Posted 06:40, Sun, 27 Jun 2010.

Bureaucracy and Broken Hinges

From time to time, I try to keep up my text adventure habit. After a period of being stuck in Guild of Thieves I decided to have a go on the Infocom side with Bureaucracy, which has the added advantage of having had Douglas Adams's input into it.

It's a fun enough game. The plot does have Adams's fingerprints on it, and the puzzles are varied and interesting. However, I think I've been spoilt by Magnetic Scrolls! I'm not too worried by the lack of pictures, but Bureaucracy is comparatively... spartan. The descriptions are short, the number of locations limited, and the structure quite linear. To compare, the total points in the game is 21, versus 500 or so for some other adventures. Admittedly, it gives out points one at a time, rather than in lumps of fives or tens, but this is still small.

Difficulty-wise, Bureaucracy is reckonned to be rather difficult. I found it straightforward with lumps of difficult. Of the twenty or so puzzles in the game, I got stuck on three. As I'm annoyingly time-limited nowadays, I resorted to spoilers. Rubbish me! Reading the answers generally made me feel rather silly - I should have got them! On the other hand, they really weren't straighforward. The game's sadistic sense of humour stretches to the puzzles. You might see how to solve a puzzle, but it'll set an obstacle in the way, and another. Oh, and the puzzle may involve an item from way earlier in the game you didn't know you needed. Nice.

Still, it really was a good pile of fun.

In other news, my MacBook Air continues to give hardware problems. I think the warranty-expiration timer must have fired. Closing it, the hinge made a funny noise, and it failed to shut. Further inspection revealed that the little metal bits had, well, kinda got out of sync. A bit of fiddling did get them back. However, the hinge cover ('antenna cover') is plastic, and the dislocated metal was levered into it, weakening the plastic. It's now broken, leaving a little hole in the hinge area. I think it provided a certain amount of pressure on the hinge, so the hinge is now a little weaker, and the screen tends to fall back.

Looking at the internet, I don't appear to be the only one - see here, for example. The replacement parts are hideously expensive, and to fix it involves removing pretty every internal component. I think I'll hold off for a while, after the last fix....

Permalink. Posted 21:32, Sun, 06 Jun 2010.

Return of the Mac

Hurrah! My Macbook Air is finally fixed! And it only took a month... The hard drive died when we went on holiday to Cheltenham (apparently it's still a bad idea to travel with them in suspend mode - I thought things like that were pretty ok, now?). Fortunately, the failure mode was that it eventually succeeded when doing most reads, so I managed to back up most of the stuff I wanted after the event.

Things I have learnt include:

Permalink. Posted 14:18, Sat, 08 May 2010.

Electronics for newbies: Voltage regulation

Once I realised my Nokia 'PSU' was outputting a decent number of unregulated volts, I thought it'd be good to get some voltage regulation in the picture. Given I'm living in a world of slightly retro CMOS (Z80s, etc.), I got a few 5V regulators. I bought myself a few Microchip MCP1826S-series linear regulators, and for fun a couple of switchers - National Semi LM2574N-5.0's.

The linear regulators are really straightforward to deal with and, in conjuntion with a decent-sized cap to smooth the supply from the wall wart, worked nicely. I thought that I'd be fine without heatsinks - after all, how much power will they be putting out? - and indeed it has been fine so far, but it does rather seem an omission now. These little regulators get awfully hot, even when supplying small circuits.

When I do the numbers, this does make sense. Powering a decent number of LED segments can put you in the region of a hundred milliamps. If the regulator's starting with a supply around 10V, the regulator's putting out a decent fraction of a watt. This may not seem like a huge power output, but the thermal resistance of one of these regulators without a heatsink is pretty high. The result is a regulator which is, ahem, 'noticably warm' to the touch. Fortunately, I doubt it's anywhere near a failure temperature. Nonetheless, there'll be a few 'sinks in my next parts order.

The switching regulators are much more fascinating devices. Vastly more efficient, they don't need a heatsink, and as you can get them in 8-pin DIPs, the combination of size and efficiency makes them sound perfect for running off a battery. Or so I thought. Enter Exhibit A.

Er, yeah, that's the kind of size of component I want in a portable, battery-powered device. *sigh*. I think I over-specced it slightly, at 470mH, and perhaps I should have checked the dimensions before ordering, but that's not what I had in mind. I've seen inductors before on PCBs, but... nothing like that.

I notice that my EPROM programmer has an MC34063A to step 5V up to VPP, with a super-tiny (comparatively) 100uH inductor on it. The LM2574 datasheet is really quite dummy-safe, and is very explicit about which inductors to buy for it. I'm wondering if there's basically a trade off between idiot-proofing and designs using cheap, small components, and I've landed in the 'idiot' end. Ho hum. In any case, I've yet to actually build a circuit using the switchers, put off as I am by these huge coils....

Permalink. Posted 13:26, Sat, 03 Apr 2010.

To the dark side

I now have an entry on Facebook. Years of resistance have come to naught, and I'm shoving my communications through a commercialised, centralised doodah for the sake of convenience. Go me. On the other hand, it's very convenient.

Permalink. Posted 10:42, Sun, 28 Mar 2010.

Electronics for Newbies 3: Faffing with memories

Skipping the fun of voltage regulation, which I'll come back to, I've been mostly playing with SRAM and EEPROM. I'll need these for my plan of building a simple microcomputer. First up was the SRAM. I built a simple circuit to allow me to load values into the SRAM and then read them back:

The structure's probably not terribly clear, so I've since done a schematic:

The schematic's messy because I'm too lazy to make it look really pretty. I've skipped decoupling caps and the power supply.

One thing I discovered that while building circuits directly is the easy way to go for simple designs, it doesn't stop you making simple mistakes. For example, when setting up a switch as a CMOS input, connect the switch and resistor in series, and then wire the input line from between the two components. Otherwise it doesn't work so well. Duh. Not so easy to spot in a rat's-nest of wires.

The resistors between the switches and the inverting buffers/SRAM side prevents me shorting an SRAM output to ground through a switch while reading its contents, and it seemed to be a source of surprising weird behaviour. Without enabling the SRAM, toggling some of the switches back and forth a bit left the LED glowing, as if the whole thing had got into some kind of metastable state or something.

Take the SRAM away (even thought it's supposed to be Hi-Z), and the problem goes away. Disconnecting a line from the SRAM and measuring its voltage (with a voltage divider attached, to make sure I'm not seeing some Hi-Z rubbish) showed the SRAM driving the line slightly (even though the thing's supposed to be in high impedance), once I've annoyed it enough on the other lines.

Reducing the size of the connecting resistors from 10k to 220 ohms (they are supposed to be simple current-limiters, after all) reduced the problem, but didn't make it go away. Sticking a small cap (0.1uF, IIRC) on one of the data lines made the problem go away completely! Then I could happily write patterns into various addresses and read them back. Woo.

I still have no idea why it was doing this. Given this was supposed to be a really straightforward circuit, and I'm hoping to build something much more complex involving this chip, running at actually reasonably fast speeds, I'm more than a little unnerved. I'm hoping a shedload of bypass caps will do the trick.

Then my EEPROM programmer arrived, from China, no docs at all. Still, it didn't look too dodgy, so I plugged it into my computer, downloaded some approximately-right looking software from the net, and it worked first time. I wired my newly-programmed EEPROM into the world's simplest reader circuit:

It worked. I had a massively-overkill hex digit to seven segment display converter. I am now officially back to first year undergraduate digital electronics level. Woo-hoo!

Permalink. Posted 10:18, Sun, 28 Mar 2010.

E-book Reader Review: The Sony PRS-300

I've been watching the whole eInk thing for a while and finally gave in at the start of the year, going for the entry-level Sony PRS-300. It doesn't have any form of wireless, or any snazzy note-taking features, 'cos all I really want to do is pre-load it with books and read them.

Specifically, I don't want to load it with papers or highly-mathematical books. Novels and maybe some light compsci, yes. The reason for this was the eInk technology - page refreshes are slow (a noticable fraction of a second), and eInk (and indeed most electronic book readers) is really bad for flicking around and browsing, which comes up a lot with the heavier reading where you can't just start at the beginning and read through.

My experience so far has justified this, which is kind of ironic as it's actually a lot better for light novel reading than for the kind of technical text a gadget early-adopter might read. As a novel-reader, this kind of technology is excellent, as it's smaller and lighter than a chunky paperback, let alone a hardback, and it can store a decent number of books. On a commute, you needn't be stuck if you've finished one book and want another.

So, on to the specifics of this device. It's a standard Sony product. So, the hardware feels pretty nice. The firmware is mediocre, and the PC-installed software is dire. Starting with the PC software, it's taken a leaf out of iTunes's book, but copied it very badly. iTunes on Windows imports an Apple look-and-feel... the Sony software on a Mac has a nasty, inferior widget set that e.g. gives really ugly context menus. The software is laggy when it's not downright locking up, and it seems to manage to screw up syncs as often as it can, and have random arbitrary limitations. Yay.

On to the firmware. I've not been using 'proper' ebook formats, since I have little interest in buying DRM rubbish. The formats which look most convenient to me were therefore PDF, RTF and plain text. Most PDF documents render too small to be readable on the 800x600 display in normal portrait mode, but the firmware does fortunately have a landscape mode, viewing a single page in two chunks. If your document has a big margin, it'll happily display this, but fortunately Apple's Preview application allows easy cropping of PDFs, so that it'll take up the entire reader screen. Why is this not built in?

PDF display is not all fun-and-games, though. It can be really very laggy to switch pages. Why not pre-render and cache the adjoining pages, to remove the render lag? Moreover, it's sometimes rather difficult to tell when an operation has started. The eInk is no good at quick updates, but why not have an LED for 'I'm thinking'? There's a charging LED built in already - why not use that? Some buttons require you to hold them down for alternate operations. So, a tap for next page, a press for skip 10 pages. Of course, there's no feedback for when you've reached the 'press' period of time, and it will only start grinding away once you've let the button go, so you've got to guess the minimum hold time that'll get you forward 10 pages as quickly as possible. Argh! So simple features implemented so badly!

Having said that, PDF's been pretty reliable for the docs I've got in that format, although if I had a document in a different format I wouldn't convert it to PDF. I've seen one or two rendering bugs (cheers, Sony), but they've not been killers. So, what's a good format if you have the choice? The software doesn't allow you to specify an author name on a plain text document, and when I briefly looked at it it had some particularly braindead handling of paragraphs, so I quickly dumped it. The RTF support is certainly good enough for novels - 'A Deepness in the Sky' (one of my favourite-est novels, evar) worked very nicely for the 1000+ pages it had. However, I tried converting an RTF with lots of pictures in, and it gave up rendering the text part (but kept the pictures!) after a hundred pages or so. Useless. Oh, and HTML support? I switched to RTF because the HTML support was pretty dire.

Finally, the hardware. It feels very pleasant. The eInk really is very pleasant to read - I've been reading various documents off it for a couple of months now in every morning and evening commute, and it's much more pleasant than the alternatives. The build quality is good. It claims 'up to 7500 page turns', and I can support this claim. Specifically, there's absolutely no chance of it exceeding 7500 turns on one battery charge. I'd be surprised at 2k, and given one paperback can come in at over 1000, I'd strongly recommend taking a charger if you want to take this thing on a holiday. It's surprisingly irritating to be unable to read a book you're carrying because its battery is flat!

All-in-all, it's definitely immature technology. It's too expensive, slow, the particular implementation has Sony's renowned software, and the ebook market is still screwed-up. However, it makes a great novel-reader, and it really does look like the thin end of a very long wedge which will eventually make my lovely bookshelves look as useful as a vinyl collection. I'd give it 15 years.

Permalink. Posted 21:42, Tue, 23 Mar 2010.

Electronics for Newbies: Random catch-up

I've been playing about with a few more electronics bits and pieces, but haven't had the chance to write them up (yay, babies!), so to keep up the momentum I thought I'd put up a few notes:

I've played a bit with voltage regulators, SRAM and EEPROM since writing last, so hopefully I'll manage to write those up soon...

Permalink. Posted 09:39, Sun, 21 Mar 2010.

Electronics for Newbies: The LCM555

Having not played with any electronics for something over a decade, I thought it'd be time to whip out the breadboard again. So, I thought I'd start with the bog-standard newbie construction, a 555-based blinking LED. This time round, for fun, I thought I'd use an LCM555 CMOS-based 555, since it apparently wouldn't do bad things to the power rail, which is nice, as my eventual goal was to use the 555 as a clock for some sequential circuitry while testing. I looked at the reference circuit design, plugged it into a surplus Nokia phone charger (the LCM555's got a nice, wide supply range, so I didn't think too hard here), plugged it all together, and... nothing.

So, yay, electronics debugging time! For the first time in my life, I actually bothered to learn how the 555 works, rather than treat it as a magic incantation for making something blink. It's actually rather straightforward and neat, but I'd never bothered getting the datasheet before. Once I understood how it worked, I realised I'd been choosing resistor values that were basically shorting it. You'd have hoped something might mention not to do this, but noone seems to bother. D'oh.

I fix that up and... nothing. Even a fresh chip doesn't work. I'm now a little frustrated, but at least I understand how it's supposed to work. I now set up a simple test circuit which removes all that faff with capacitors, so that it should basically run in a steady state and show its hysteresis:

I plug this in, and it behaves weirdly. The the lower level switches on, but then it immediately switches off above this level - there's no hysteresis up to the higher level. Why this asymmetry between the levels? Could it be something to do with the adjustment pin ('CV')? Nope. The circuit should be quite static, without a capacitor, so I shouldn't be seeing any glitchy behaviour. However, when I put more bypass caps in, it goes from on/off to on/slight glow. Hmmm.

Argh. Sticking a multimeter in min/max mode voltage on the power supply reveals a rather high max, and a min of zero. Frequency? 100Hz. Yay, we have a fully-rectified but unsmoothed, yet alone regulated power supply. I'd really assumed that thing would be regulated. Apparently not!

The attachment of a 9V battery (they're convenient in that you can attach them using crocodile clips, if you don't have a proper snap), and everything works fine!

So, now I've been learning up on power supply theory. Horowitz and Hill has been sitting on my shelf for years - I tried reading it front-to-back before, and wedged somewhere near the start of Chapter 3, but I've now zipped through the whole of the power supplies chapter. I only needed about 3 pages, but it's fascinating, and each chapter seems to be about as self-contained as it can be, so it's been surprisingly engrossing.

I could just power my future projects off batteries. Not a 9V, since many of the digital chips I'm looking at max out not far over 5V, but maybe a set of rechargeable AAs. However, I now want to play with all the options, so I've ordered a few battery holders, plus the chips, caps etc. for both linear and switching regulators. I think the switching regulators should be overkill, but at least fun to play with.

We'll see how it goes.

Permalink. Posted 08:39, Wed, 03 Mar 2010.

Python is the new BASIC

This is not an original blog post title. Others have said the same thing, followed by a post body saying 'but I don't mean that in a disparaging way'. Let's get one thing clear. I mean this in a disparaging way.

Ok, it is a good beginner's language. And unlike Dijkstra thought about BASIC, you can learn it as your first language, and you won't be scarred forever (just like BASIC). However, you will eventually need to move on from this language and be rehabilitated into society before you can be fixed up. You need to acknowledge that it's not a real language, and so few Python programmers admit this. :p

The problems I have with the language are, basically, that it's a dynamically-typed grab bag of ideas from all over the place. So, its core design isn't particularly coherent. As the ideas were copied without real understanding, they're done wrong, and there are unpleasant bodges. Dynamic typing means there are whole classes of error you can pointlessly leave in, waiting for the appropriate runtime failure. Yeah, you can do insane amounts of testing and run other tools, but... a solid, static type-check from the get go is just so much cleaner and safer. And that matters.

The problems I have with Python programmers is that they think they know something. The language is neither low-level, nor cutting edge. It doesn't show you the hardware, or bring you to neat theory. It just gets the job done, and because it's so pragmatic, it gets the job done badly. So Python programmers, having chosen this particular sub-optimal point in the space of programming languages for themselves, are either ignorant or deluded.

(I'm still programming Haskell for my day job. It's an impractical and basically ludicrous language. However, the right language doesn't exist, and it certainly doesn't have an excellent compiler and set of libraries. In the meantime, I love Haskell.)

Permalink. Posted 23:58, Mon, 21 Dec 2009.

Finding bugs in the GHC runtime

Race conditions are always a pain. We just spent the better part of two days tracking down a race condition which caused our production executables to hang once in every few thousand invocations. Surprisingly, it wasn't the normal DllMain deadlock.

On the other hand, it was a nice excuse to play with WinDbg and binary patches.

See GHC Trac for details.

Permalink. Posted 14:13, Sat, 12 Dec 2009.

Magnetic Scrolls

My Project Euler addiction has been effectively destroyed by taking away my mathemtical ability. A new baby has had that effect on me. But I still have a puzzle urge and time between feeds. So, I've been looking at the old Magnetic Scrolls text adventures. I tried Fish! and Guild of Thieves nearly 20 years ago, but never really got very far, so I was intrigued about having another go. Jinxster looked like a lot of fun, so I had a go...

And generally, it was! As with so many adventure games of the era, it's unforgiving and pedantic. You have to spell things out, and if you make a mistake it'll let you keep playing even though you can't play to completion. Having said that, it's friendly as far as the genre goes. In-game characters sometimes provide subtle hints, and the structure of the game allows progress even if you're stuck on one puzzle.

On the whole, the puzzles are rewarding. Initially, I thought there were a number of evil red herrings in the game, but it looks like a number of puzzles can be solved multiple ways! I'm almost proud of myself. I made it through the whole game except the last puzzle without spoilers. When I read the spoiler for the final puzzle, it basically told me how to do what I was already trying to do. *sigh*

In fact, I found the whole ending section disappointing. The last puzzle was put together slightly shoddily, and the ending might have tried to be a clever twist but... no thanks. It's a shame, really, as I rather enjoyed the game as a whole. I may have to play another.

Permalink. Posted 16:09, Mon, 07 Dec 2009.

David Alexander Frankau

Having now announced this to most of our friends directly, this is now unembargo'd!

Caroline and I are delighted to announce the safe arrival of baby David Alexander Frankau, who was delivered safely at home at 8.04am on Friday 30th October 2009. He weighed 7 pounds 11 ounces at birth and is, in the opinion of his completely unbiased parents, the cutest baby ever!

Permalink. Posted 23:25, Tue, 10 Nov 2009.

Fun with pipes on Win32 (3)

So far I've talked about the irritation I was seeing on the C++/Win32 parent process side. However, we also saw weirdness on the Haskell side. Everything is done inside a System.Timeout.timeout call, so that the process really should never wedge. The parent process, being buggy, was doing a blocking read on stdout. The child process was writing to stderr. We saw weird behaviour:

The first piece of behaviour is expected... but what's going on in the other two cases? In the last case, the OS buffer is filled, the write call blocks, and as the write is inside the timeout block the timeout occurs. We might expect this, but why only over 4608 bytes? Haskell internally buffers 512 byte blocks. So, if you write over 4608 bytes, it'll fill up the internal buffer 9 times, write out 4096 bytes (to fill the OS buffer), and then trigger a final write, inside the 'timeout' block. The process times out.

Between 4097 and 4608 bytes, the internal buffer will be drained 8 times, writing out 4096 bytes to the OS, and filling its pipe, but leaving the internal non-empty. We leave the 'timeout' block, and start to shut the process down. Our stderr internal buffer needs flushing, so we perform a blocking write, this time outside the 'timeout' block. Deadlock.

What's the upshot of this? If you want to know what's going on, you need to understand the details of your system, as abstractions leak. Oh, and if you want 'timeout' to work quite as you expect, you might want to flush your handles before the end of the block.

Permalink. Posted 22:33, Tue, 15 Sep 2009.

Fun with pipes on Win32 (2)

Previously, we'd moved from using anonymous pipes to communicate with our subprocess, to named pipes with unique names. Problem solved, right? Sadly not!

Rather than create completely unique names, I created names that were guaranteed to be unique for the lifetime of the sub-process. Generating totally unique names just seemed like overkill! So, I create one sub-process, then the next one, and use the same unique pipe name each time. As long as the sub-process has died, and the parent's end of the pipes are closed, the old pipe will go away, and a new pipe with the same name can be created.

Furthermore, our sub-process manager is multi-threaded. So, we can fire off multiple sub-proceses at the same time. However, the pipes weren't being closed properly (so we couldn't reuse the names) when run in multi-threaded mode. Why?

It's all to do with the way Win32 passes handles to sub-processes. In order to get a handle into a sub-process, we have to make the handle inheritable, and then spawn the sub-process with 'inherit all inheritable handles'. Unfortunately, if you spawn two subprocesses around the same time, both children will inherit the handles (even if they're not wired up to stdin/out/err in that particular process). So, the other process is holding the pipe open.

We can reduce the window by closing the pipe as soon as the sub-process is fired off, but the race is still there. We could then hold a lock during the spawn step, but it's slightly icky to introduce the extra synchronisation. Personally, I think it'd have been nice to control exactly which handles are passed to which subprocess, but this looks like a weakness of the Win32 API. Unix-style APIs, using fork/exec allow you to control the exact handle (file descriptor) set-up for the child. Gah.

Another funkier approach that I didn't try is to spawn the sub-process suspended, use DuplicateHandle to poke the handles into the sub-process, and then unsuspend the process, to spawn a subprocess with exactly the handles required.

So what did I do? I just made the pipe names globally unique.

Permalink. Posted 22:07, Tue, 15 Sep 2009.

Fun with pipes on Win32 (1)

Most of my work nowadays is writing Haskell, but to interop with other systems we have COM server which fires off the Haskell processes and communicates with them through pipes - we could do things less indirectly, but this is a nice, simple way of decoupling the components. However, the pipes have been really quite irritating to deal with.

First off, Win32 anonymous pipes (the kind of pipes you'd expect to use to communicate with a child process) don't support WaitForMultipleObjects. This is really quite irritating if you want to support select-style reading from your sub-process. Why might you want to do this? Well, the alternatives are:

So, instead I tried WaitForMultipleObjects-ing on the handle. MSDN said I couldn't, but MSDN lies about lots of stuff. It turns out MSDN was telling the truth, although it wasn't immediately obvious. It basically immediately returns (without error), so we then perform a blocking read on the pipe, leading to the deadlock described above, as we wait to read one pipe, and the child waits to write the other.

The solution? Use named pipes, with unique names. This link contains the basic source, which you may want to adjust for your personal use, while complaining that the Win32 API really should do this right itself, especially since it's such a common usage case.

Permalink. Posted 21:43, Tue, 15 Sep 2009.

I own a Nokia 2630.

This is a rubbish phone. Fundamentally, the call quality is shocking. I assume the aerial is rubbish. The user interface lags - I push a button and have to wait to see something happen. I reckon there's a half-second lag betwen me hitting the keys, and the phone actually locking or unlocking, and ditto for most other operations. I previously had a 6230, and while it had its foibles, at least the text went in as you typed it, the keypad had less inconvenient buttons, and resuming an interrupted text was super-simple. How, given fewer constraints than previous generations, they've managed to make the interface worse, I do not know.

In fact, I only discovered how to change the volume on this thing today, thanks to googling, as I felt so silly being unable to do that. Left and right directional keys during a phone conversation, apparently. Makes me realise how much I liked dedicated volume keys. Even my 3210 used up and down, I think.

This is my fourth Nokia phone, as I've generally found them consistent and straightforward. Oh, and apparently they've had good sound quality, 'cos in comparison, this thing's rubbish. I try to choose simple, small phones, 'cos all I want to do is keep it in my pocket (small) and make calls and send texts (simple). So, I got this simple cheapo phone. It does admittedly deliver on the small side, but given it doesn't actually make phone calls very well, I should probably just keep my pocket empty instead.

I have a suspicion that they could make a cheap, high-quality phone, but they'd rather make their low-end model rubbish, to encourage you to upgrade. After all, they couldn't deliberately design something as bad as this, could they?

Permalink. Posted 23:18, Sat, 14 Mar 2009.

We had a skiing holiday

Not particularly exciting for anyone who wasn't present, but I enjoyed this sufficiently to talk to anyone who'll listen to me about it. Caroline and I went on holiday to Courchevel with a couple of friends. Caroline doesn't ski, and so hung around and absorbed the ambience. I went on the slopes and just massively enjoyed it. We were last in the area a couple of years ago (La Tania last time, 1850 this year), and at the time I did one red run and was petrified. This time we spent most of our time on the reds, and it really opened the place up and was just so much fun that I have a giant grin on my face writing about this, just thinking about it.

Outside of the skiing, our gap-yearing chalet host was fantastic, and our friends' toddler upped the cute factor (so glad I didn't have to play any role of responsibility, though ;). A wonderful break. But gosh, Courchevel's expensive!

Permalink. Posted 22:57, Sat, 14 Mar 2009.

I'm going to have a paper published!

For the first time in years, I'm going to have a paper published ("Going Functional on Exotic Trades" in the Journal of Functional Programming), which is remarkably pleasant. It's my day-job in paper form, and it's mentioned at the bottom of my now-recently-updated research web page. Yays.

Permalink. Posted 23:26, Tue, 09 Dec 2008.

The C++ Standards Committee Hate Me

This is the only possible reason I can think of for the fact that the default "precision" value for an ostream is 6. What does this mean? It means that any floating-point number it prints out will be rounded to 6 significant digits.

What?! Why?! Let's put this into perspective. A double-precision floating-point number commonly has a 56-bit mantissa. Let's be generous, and say that each decimal place requires 4 bits to represent it. We'll even ignore the hidden bit. That's still 14 digits. Even if you then go and assume that your calculations have destroyed half the precision, pretty much a worst case unless you're either doing something wrong or are in hardcore numerical-analysis land, that's still 7 significant figures. And that's a very generous worst-case analysis.

Let's look at it another way. 32-bit ints go to 10 significant figures. They can be stored exactly in normal doubles. They can be printed directly, and that's fine, but if you cast them through a double first, the default will truncate them when you print them.

I have a program that reads in numbers and prints them out again. I assumed sensible defaults for precision. I lost. I have had to fix the precision on my ostreams before writing to them, and I have no idea why. I'm sure there are situations where 6 significant figures are what you want. On the other hand, I would very much like it if that were something you had to select, and the defaults weren't incredibly stupid for default use.

Pah.

Permalink. Posted 22:36, Sun, 07 Dec 2008.

Rules of thumb in writing code

There are a number of rules of thumb when writing code. Things that are generally accepted as good style and ways to work. You know, things like employing abstraction and making stuff data-driven. What they don't tell you is that there's too much of a good thing. This is patently obvious - you can always make things more data driven by adding an extra interpreter, and you can always stick more wrappers in for 'abstraction'. Put another way, you're trying to find a maxima of style in program space, and this isn't going to happen by heading traipsing off to infinity.

They're called 'design decisions' for a reason. There's a decision to be made. You can't hide behind just doing commonly accepted 'good' things. If you do that, you're going to end up producing 'enterprise' code which runs around in circles, reinvents all kinds of wheels and/or pulls in every library you can think of, bloats out to infinity, and is still a complete pain to actually maintain. And then I have to review the code and explain what's wrong. And guess what? Every single decision will get justified as doing what is commonly accepted as good practice. *sigh*

Permalink. Posted 22:07, Fri, 12 Sep 2008.

On Rewriting Code

This note is somewhat bitter. It's about the software event horizon, beyond which a piece of software sucks and there is nothing you can do about it. It's something I encountered a couple of years ago, so hopefully it's far enough away, and I've filed off all the serial numbers. It was in another team. And besides, the project is dead.

It has been claimed that the single worst mistake you can make you can make on a big software project is to rewrite it from scratch. On the other hand, I believe there are situations where the best thing you can do is to throw it all away and start again. Presumably, these two situations are distinct, and the sign of an experienced developer is one who can choose the best course?

No. Sometimes, the code base is just screwed. It's dead, and you don't know it yet. You can rewrite from scratch, and it'll fail. You can maintain the existing code, and it'll just bog down and become a programmer trap, a developer black hole. In retrospect, you'll say you should have done the other thing.

However, you're just in a no-win situation. What can you do? Well, often it's not actually that bad. It'll be painful, but you can start retrofitting test harnesses, decoupling components, and pull the code base back to something where sensible decisions can be made. However, if your code has plenty of race conditions, relies on 'strategic leaks' and generally has bodge upon bodge upon bodge, it may be a no-hoper. I suggest firing the management involved for letting it get into this situation. Then fire their management for letting them do that. For bonus points, trawl through the source control logs for the very worst bugs introduced, and put the developers involved on the 'do not rehire' list (obviously they won't still be with you - such a project requires high turnover).

In summary, the best thing to do is to steer clear of such projects. For some reason, no-one believes it can be that screwed up, so whatever you do people will be unimpressed. Run away from a zombie code base while there's still time!

Permalink. Posted 11:21, Tue, 29 Jul 2008.

Yellow Peril

I made a hideous discovery in Heffers, the Cambridge bookshop, just before I got married: The Springer Yellow Sale. A very dangerous event for the wallets of wannabe mathematicians. In the Yellow Sale, plenty of Springer maths books are pretty much half price. This reduces them from eye-wateringly expensive down to just plain expensive. Who can resist half-price introductions to p-adic numbers? Suffice to say that, despite my already huge maths book backlog, I've now got a few more lined up. Ho hum. I'm weak. Sale ends at the end of July!

Permalink. Posted 22:49, Sat, 26 Jul 2008.

Protocol Buffers

You may well have heard of Google's Protocol Buffers, the latest and trendiest way to treat everything as a nail. The logic goes something like this: XML is complicated, verbose, expensive to process and ubiquitous. So, let's use something completely different for everything instead!

What's XML good for? It's a decent representation of structured data. So, we get to use it as an insane way of writing RPC requests and obfuscating data better put in a CSV file. Oh, and serialising objects. This is all obviously rubbish, and Google's protocol buffers will solve everything. Until we realise the weaknesses of the new format, that is.

What might be nice is if people actually applied sensible tools for the job, and didn't conflate different requirements. Protocol buffers are a lightweight IDL implementation, so it's probably best to use it for that. Use it to generate RPC requests. Maybe use it for inter-language communication of data-structures, and limited persistence.

Then notice that protocol buffers aren't self-describing, aren't easily human readable or editable, and things like that. Note that you might want to use JSON or even XML for appropriate situations. CSV maybe. And notice that object serialisation (as opposed to data structure serialisation) is something you don't want to conflate with other stuff, because if you do it'll become some kind of interface, and if you're really unlucky people will be editing the serialised structures by hand, and it's all a mess.

Please. Use the right tool for the job.

Permalink. Posted 00:05, Sat, 26 Jul 2008.

Fun with CoLoadLibrary

This is for the 3 other people in the world still using COM.

We're writing a 'front-end' COM server which wants to delegate work to back-end DLLs. Specifically, it will load up a DLL and pull out an object with the appropriate interface. It sidesteps CoCreateInstance, so we avoid lots of painful registry look-ups when we know exactly which server we want to implement the thing. Why would we do this? Because it allows us to supply our own version of DLL hell, rather than the COM-server-registration one which comes free as standard.

So, is all light and fluffy? Not quite. Normal COM object creation gives you appropriate cross-apartment marshalling and proper DLL unloading. The marshalling isn't a problem - the newly created object just ends up living in the same apartment as the loader object. What about DLL unloading? COM normally allows libraries loaded for the sake of accessing COM servers to be unloaded after a period of unuse through CoFreeUnusedLibraries(Ex). So, if COM didn't load our library, it won't unload it. Argh.

What's specifically the problem? Suppose we have a COM server in the back-end with instances still alive in it. Then it can't be unloaded. Moreover, it can't unload itself when the last instance goes away (FreeLibraryAndExitThread being the nearest thing, but with nasty race conditions). The only thing that knows it needs unloading, and that can unload it, is the front-end library which LoadLibrary'd the back-end. So, this thing must be prevented from unloading until all the back-ends have disappeared.

It looks a mess, since the loaded DLL has to somehow inform the front-end when it's done with, so that the front-end can unload it, and in turn be allowed to unload. Quite a faff. Why can't we just tell COM to unload the back-end for us when all the objects are gone?

Back in the day there was CoLoadLibrary, which had an 'AutoFree' parameter, which did just that. COM would take control of the unloading of the DLL at the appropriate point. Except... it no longer works. MSDN helpfully notes this, after explaining how it would work if it did. In practice, no error is raised if you use this flag. Effectively, it just silently leaks the DLL.

So, how did the COM unloading mechanism work anyway? It calls DllCanUnloadNow on all the COM servers loaded through CoCreateInstance, and on any that return true, it then unloads the DLLs. In the end we just used this mechanism to fake up the COM unloading system. COM would ask our front-end DLL if it could unload, and this would trigger a cascade of DllCanUnloadNows on the back-end DLLs. If they could be unloaded, they got unloaded, and our front-end DLL finally gets unloaded only if it's supporting no objects, and all the libraries it loaded are now unloaded.

It works, but WHY OH WHY COULDN'T THEY JUST LEAVE POOR COLOADLIBRARY ALONE?

Permalink. Posted 22:56, Wed, 23 Jul 2008.

On the Naming of Climbing Shoes

In an attempt to improve my health, I'm trying to get a bit more exercise. Specifically, I'm trying to take up climbing (we'll see if I keep it up). Since rental shoes are, er, pretty grim, I bought myself some climbing shoes. I got them from Rock On at Craggy Island, the climbing centre in Guildford. I recommend both the centre and the shop to beginners. I can't tell if the guy in the shop was actually knowledgable, as I'm a novice, but he did a very good impression and was very helpful!

But what shoes did I get? I got a pair of 'Ballet "Gold"'. Yes. The quotes are in the name. I checked, and they are men's shoes. I love the combination of macho-ness and class that comes from combining the word 'ballet' with a precious metal in quotes. Presumably they feared that if they didn't use the quotes someone would sue them for the lack of valuable metals. Taking this line of reason, I assume it must actually be possible to do ballet in these shoes, although it does seem unlikely.

In short, I suspect the marketing department involved do not speak English.

Permalink. Posted 21:08, Sun, 20 Jul 2008.

Best Art For Under 10 Grand

We went to the Royal Academy Summer Exhibition the other week. It was rather good, although we didn't come away with anything (some of the works are fairly cheap, and pretty good, but nothing affordable really connected with us). However, it did give us a chance to find a few artists which we really rather liked. So:

Disqualified on price were Ken Howard and David Tindle.

When we win the National Lottery, these guys better beware.

Permalink. Posted 22:45, Mon, 07 Jul 2008.

Wedded!

Caroline and I are now married! We got married at St. John's College chapel, Cambridge on 7 June, and have just returned from a little honeymoon in the middle of nowhere. While we have tonnes to say on the subject, I think we'll leave it at that for the moment!

Permalink. Posted 16:03, Fri, 13 Jun 2008.

Solving Rubik's Cube

A few weeks ago I went on a recruiting thingie at the Cambridge Computer Lab. As well as trying to recruit grads, it's a chance to grab freebies from other stands. I got a nice Rubik's Cube, which gave me a bit of a flashback.

When I was small, I got a Rubik's Cube, but never solved it. Fun, but frustrating. When the Rubik's Magic came out, I sidestepped the whole puzzle element, and got it with a book solving it. I think I missed the point a bit there, but it was a good fun toy. When the Rubik's Clock came out, I finally solved one. Got it Christmas Day, solved it Boxing Day, my family thought it wasn't good value for money, but I rather enjoyed it. A couple of years later, I got a little book on solving the Rubik's Cube, but didn't actually work out how to solve it myself. Ho hum.

So, this time round I thought I'd solve it properly. My plan was to grab a few basic sequences, and then build it up into a full solving sequence. First, a bit of notation. The front and back faces are F and B. L and R for left and right, and U and D are the top and bottom. Edges pieces can be specified with two letters (e.g. UR), and corners with three (e.g. URF). I'll write a particular face rotation with either a positive sign (e.g. +U) for that face being rotated clockwise, or minus for anticlockwise. I'll use '3X' to mean repeating the sequence 'X' 3 times.

So, after a few simple experiments, I find the sequence 3(+L+L+U+U) swaps FU and BU, and FL and BL. The other sequence I used was based on explicitly trying to shuffle some of the squares around. The sequence is +L+F+F-R+F+F-L+F+R-F, and what it does to the top is... complex. We'll call this sequence 'X'.

It's easy enough to get one face sorted, so that one third is right. Put that face on D and then line up the centres of the non-U faces to match the colours on the lower edge. Then all you need to do to get the middle sorted is to fix the edges in the middle layer. You can do this by arranging it so that the ones you want to swap are at FR and UL, and then do +L+U 3(+U+U+F+F) -U-L. Once you've done that for all the middle edges, it's only the top to go!

We can now use this 'X' sequence to tidy up the top. X will shuffle around various edges and corners, and change which face of them faces where, but main thing to note is that URB stays where it is (turning in place), while the other corners rotate round. So, by putting the appropriate top corner into URB and applying X, you should be able to get the corners into place for the appropriate colours. However, they won't yet be facing the right way up.

Applying X 3 times shuffles puts the corners back where they started, but facing different ways up. More specifically, URB is identical to how it was before, but the other three corners are turned clockwise on the spot. By repeatedly carefully choosing the corner to be URB, and then applying 3X, you'll now have everything complete but the top edges. The top edges can now be completed by variations on the 3(+L+L+U+U) sequence. If you want to swap two pairs of faces, it then becomes quite simple: Find a short sequence which places those pairs you want to swap into FU/BU and FL/BL, apply the swap sequence, and then undo your original sequence by running it backwards (unturning faces in the reverse order). My group theory is more than a little rusty, but the operations you can create this way are the conjugates of our original swap operation. This is the technique we used to fix up the middle-layer edges.

This will do a certain amount of edge-swapping, but we can end up with situations where we want to rotate around three edges, and the swap operation doesn't make this look easy. Can we do it? We can't do it by just swapping top edges, but we can temporarily untidy the middle. Let's say we want to cycle UL, UB and UF. We'll choose two more 'victim' edges, whose roles are to be swapped at appropriate times, but end up where they started. These will be FL and FR. Then we arrange a pair of those conjugate-based swaps, to achieve the cycle. In the following table, each new row represents two sets of edges being swapped around. The swapped elements are in bold:

UBULUFFLFR
ULUBUFFRFL
ULUFUBFLFR

At the end, we've cycled those three pieces around. While I haven't proven it, this appeared to be the final piece I needed, and I've been able to solve the cube several times using the above toolkit. It is, however, a very unwieldy toolkit. The sequences chosen are built by incremental construction from smaller sequences, rather than finding the shortest sequence to do the job. The idea was to see how much I could build up starting with only a very small set of 'primitive' operations. If you're interested in solving the cube quickly, the booklet I bought all those years ago, 'Resolving Rubik's Cube' by Jon Millington, does the job most effectively, although not with much in the way of motivation. There's plenty of fun in finding your own way to solve the cube, though.

Permalink. Posted 08:55, Mon, 10 Dec 2007.

The St. Petersburg Game

The other day, someone I used to know at uni and I were discussing the "St. Petersburg Game". Basically, you repeatedly throw a coin until a heads appears, and then you pay out 2^n, where n is the number of tails thrown before the heads appeared. How much would you pay to play this game? In theory, the expectation of this game is infinite, so if you're fully risk neutral and everyone will always be able to pay up, you'd pay any amount.

So, there are two ways to generate a more realistic price to pay the game. My argument was that I'm risk-averse, and so I have some utility function for my money. I might buy a 1 pound lottery ticket with a million-to-one odds for a million pound payout. I wouldn't buy a thousand pound lottery ticket with a thousand-to-one odds of a million payout. My argument was that for one go at the game, I wouldn't want to pay more than 3 or 4, because I'm not really interested in remote chances of earning vast amounts, I'm interested in a reasonable chance of not making a big loss.

His argument was that credit needs to be taken into account. Beyond a certainly point, you would go bust. So, I might as well truncate the series that generates the expectation at that point. In other words, if you can only pay out a million, (2^20), the fair value is 11. This only makes sense if I'm playing repeatedly, but apparently that's the case he was thinking about. Certainly, if I'm playing repeatedly, I'd pay more than 3 or 4, since I'd have a much better chance of seeing some of the big payouts which make it worth it (this may sound woolly, but I'll try to make it a bit more concrete later on).

So, if we're playing repeatedly, fair value isn't what we care about, really. What we care about is the end-state. We assume that the two players will keep going until one of them gets wiped out. Unfortunately, my maths isn't good enough to work out closed form solutions for probabilities of wipe-out given different starting account values, so I wrote a simulation instead. I hacked it up fairly quickly, so it's probably annoyingly buggy, but I hope I haven't made an error fundamental enough to invalidate the whole thing.

What I'm doing is a set of simulations, where for each simulation I find the break-even level, where if I paid more I'd go bust first, and if I paid less you'd go bust first. I collected the results for 1000 simulations, assuming that I have one million and you have one million, to start with. I then took some percentiles, and prices:

PercentilePrice
10%9.948271666
20%10.18424126
30%10.43704421
40%10.66959518
50%10.98563359
60%11.36414737
70%11.84457506
80%12.97528121
90%16.04786940
PricePercentile
10.532.90%
1150.20%
11.562.7%

So, 10% of the time, if we both start with a million, I'd lose even if I paid 9.95, and 10% of the time, you'd lose even if I paid 16.05. It looks like the price which gives us even chances of wiping out our opponent is actually near 10.99, which looks suspiciously like our fair value!

This is, of course, assuming that I'm willing to risk losing a million in order to gain a million. What happens if my pockets are much deeper, or shallower, than my opponents' (Or that I just want to place my stop-loss closer)? Why, I'll just run my simulation again with different parameters... first up, I have 100K with which to steal your million:

PercentilePrice
10%8.288661462
20%8.560000916
30%8.744448393
40%8.959470526
50%9.151535916
60%9.403354633
70%9.664265445
80%10.00022710
90%10.78195451

So, even if I paid 10, rather than the fair value of 11, I'd still get wiped out 80% of the time. And if I have 1M with which to try to remove your 100K?

PercentilePrice
10%10.13697085
20%10.64982176
30%11.07549714
40%11.53903907
50%12.14243862
60%13.05499767
70%14.48813500
80%16.87636127
90%25.58518196

So, if I were willing to lose 1M half the time, in order to win 100K the other half, I'd be happy to pay about 10% over the fair price associated with you having 1M. Not surprising that I'm willing to pay more if I'm happy to take the same risk for less reward. However, another way to look at it is that if we both had 100K, I'd be willing to play around 9.3 to play for a 50% chance of winning - i.e. an expectation of 0. At the 1M level, this price is now 11. If I want the expectation to be zero for winning 100K or losing 1M, I need to win 90.9% of the time. At that percentile, I'd be willing to pay 10.1. This happily sits between the two bounding situations. No real shock, there.

Switching tacks, one of the things I noticed when running these simulations is that it can take several million plays to bankrupt someone if you start with a million each. If you really are throwing coins, you'd be giving up rather sooner. Another way of approaching the problem is to see what the percentiles are for the break-even prices if make each game consist of a certain number of plays. I've plotted the percentiles of prices for 1K, 10K, 100K and 1M plays per game:

PercentileBreakeven on 1KBreakeven on 10KBreakeven on 100KBreakeven on 1000K
10%4.5526.19097.833479.517169
20%4.9466.66378.359549.914645
30%5.2757.09398.6994010.315357
40%5.7397.52919.0915310.684029
50%6.1587.97149.5443911.188397
60%6.8028.540610.3450311.798191
70%7.6269.570011.0293612.726459
80%9.01211.057612.5820514.213793
90%13.25814.526315.8342518.443645

As you can see, the amount it's worth paying per go to break even at each percentile level even increases with the number of goes you play before stopping. Why is this? As I said woollily before, the longer you play, the more likely you are to actually see one of the big payouts. In a way, the behaviour of this thing is rather like a log-normal distribution, where the mean and median are in different places, but more so. In each case, the mean payout is infinite, but the median starts to slide upwards with the number of goes.

Another thing to notice is that the increase in payout with number of steps matches the appearance of less-likely cases. So, if you're truncating at a certain level of unlikeliness, doing 1000 times as many games means truncating 10 steps later (2^10 being approximately 1000), and thus the price being 5 greater. Look at the price difference between the 1K and 1M column, and this is what you see. Extrapolating back, if I'm willing to pay 3 or 4 to play the game once, I'm effectively at the 75 percentile price. Which sounds about right - I would only be willing to lose three quarters of the time in order to get a hopefully pretty impressive payout that last quarter of the time.

I think this approach provides a slightly different way of looking at the game. Remember, the above prices are without bounding the pay-offs, so we're not taking the credit approach. The expected payout is still infinite. However, if we're only interested in what happens in sensibly common cases, this is more useful. This is basically a VaR approach. The credit approach can also be looked at as finding the expectation, contingent on being in particularly large percentile. Mathematical modelling of finance has always been rather poor at getting the behaviour in the tails right....

Permalink. Posted 16:03, Sun, 09 Dec 2007.

Engagement!

I am now engaged. So is Caroline. We are engaged. To each other. It's great. This is actually surprisingly old news, having happened on 30 June, but I've just been taking my time getting around to writing this up. This says less about our excitement at getting engaged, so much as my incredibly slack process of writing things up.

I think it was all rather good. We'd gone up to Cambridge for a long weekend to celebrate our third anniversary, and had a nice meal at Midsummer House. Then I proposed, and Caroline accepted. We were both very happy. The food's really very good.

So. Hurrah. We're now looking at a wedding date of 7 June 2008, at St. John's College chapel.

Permalink. Posted 21:47, Sat, 24 Nov 2007.

Enterprise Middleware Development

I wrote this a few weeks ago, but never stuck it up:

I'm reading Joel on Software at the moment. It's quite interesting, and I'll no doubt review it at the appropriate juncture. What I have noticed, however, is how product-focussed he is. With user interfaces and stuff. We don't really do that. While we kind of have users, we really have people who interface with our code, and in the distance we have the angry shouts of actual end users. In other words, we are doing Enterprise Middleware Development. It's that polysyllabic. We're also not coding for the long term - the codebase isn't static and requirements are always changing. Anyway, I thought I'd share some of the thoughts I've had:

Permalink. Posted 22:33, Sat, 21 Oct 2006.

Further Congratulations to Matt and Cat!

Matt Kelly and Cat White got married. I was present. It was great. I don't really have a huge amount to say about this beyond the fact it was in Wales, the service was lovely, the food was tasty, and the evening was most entertaining. Especially Ben. I hope the couple are enjoying themselves in, um, Thailand, I believe.

Permalink. Posted 23:50, Mon, 18 Sep 2006.

Software Reliability

It's a bit of a random link, but I've recently been trying to remember a talk I saw at the Computer Lab about the horrendous state of software reliability. I've finally tracked the author down, and Professor Les Hatton has a fascinating view on this stuff that just makes you want to give up and do something completely different. He's a bit of a polymath, so it looks like there's some other cool stuff there, but I haven't really had an in-depth dig. The paper on optimising your phone tariff versus the phone companies' obfuscated talk plans, for example, is quite fun.

Permalink. Posted 23:10, Thu, 20 Jul 2006.

New York, New York!

We went to New York just over a couple of months ago. I've just finished writing it up. On the other hand, it's about 5000 words scraped out of odds and ends of time. There are pictures, too, so don't worry too much. So, without further ado, what we did on our holidays

Permalink. Posted 01:05, Wed, 26 Apr 2006.

Congratulations to Matt Kelly and Cat White! (and other random bits)

On Saturday, I attended Matt and Cat's engagement party in the relatively spiffy surroundings of New College, Oxford. It's not bad, as far as the Other Place goes. Matt was a housemate in St. John's Road when we were grad students, and Cat was his girlfriend then. So, it's great news and a good excuse for a catch-up. I'm very much looking forward to the wedding in September.

Matt berated me for not putting more random rubbish on my website, so presumably I'm supposed to mention things like last week Caroline bought me a deep-fat fryer for my birthday, and today the kitchen cupboards fall down (well, only partially - we took them down before they totally collapsed).

I'm probably also supposed to mention pet peeves, like the chunky protective cases people have for ipod nanos, and other similar goods. Why do these thing exist? These electronic goods are designed to be small, and will be worthless in a couple of years anyway. So, you're adding totally unnecesary and pointless bulk. Nice.

Permalink. Posted 01:23, Mon, 24 Apr 2006.

Sore Throats Suck

They do. You may think being off work sounds fun, but it's actually surprisingly boring and you don't get to catch up on the stuff you'd like to because you're actually lying around in bed. Even the Winter Olympics is inaccessible because the TV is downstairs and that's basically too big a move to shuffle a duvet/blanket/whatever. Darn.

So, if you're thinking of getting a sore throat, my advice: Don't.

Permalink. Posted 15:46, Tue, 14 Feb 2006.

I am a Doctor, Oh Yes

Dr. Simon Frankau, I'll have you know. I've been doctorified for about a month now, and the novelty still hasn't worn off. Well worth however many years of my life it was... :)

Permalink. Posted 00:11, Wed, 16 Nov 2005.

Mail me at random.user@arbitrary.name.