XML is a useful technology, sometimes: that's about as positive as I can be about it these days. While there was a period when I got quite excited about the idea of a standard syntax for, well, everything, time tempers such enthusiasm. See, 90% of the time, XML is just too damn cumbersome. When what you want to say is

Param1 = 3

or something of that complexity, then having to write

<param name="Param1" value="3"/>

is just a bit hefty.

Anyone who's ever tried using Ant or Maven will surely sympathise with the idea that XML is a pain in the arse way to write make-files. And XSL transforms? Phew, glad I'm not going back into that arse-end of software engineering gone mad. It's also a pain in the arse to read XMLified data in C++ or Fortran. Hell, even Python and Java make you jump through SAX or DOM-shaped hoops in their lowest common denominator implementations! Frankly, XML is a serious candidate for "no silver bullet"-type debunking: merely wrapping everything in angle brackets actually solves nothing, even if it looks totally SOAP-AJAX-Web 2.0, dude. Much of the time, something simpler is quite enough. Unfortunately, the message hasn't quite drilled through to everybody's cortexes (cortices?) yet, and I saw several HEP presentations recently where some data was marked up in XML as if that was an achievement in itself. What do you want... a biscuit? Sadder still, I was told by a starry-eyed student that this was a great way to provide a unified data format. To take this out of the HEP context, lets say I invented a new XML-oriented data format, EML. It's short for "Everything Markup Language", dontcha know?

EML is super-whizzy-clever: it's in XML for a start, which means immediately that it's 21st century (or beyond) and future-proof, unlike all those column-delimited plain text data files that insufficiently technical people keep bandying about. You can parse it with all sorts of tools (but not without pain if you use an old-style language whech actually compiles to machine code, duh), and there is future potential for some sort of Web services asynchronous HttPRequest coolness. Frankly, it's genius. And so simple! See, all you have to do to make a file in EML, is to take its normal binary representation, convert any accidental non-ASCII bits to XML entities, and slap <eml>...</eml> around it. Not forgetting an XML namespace declaration, of course: those are really useful, and really provide a good mechanism for schema evolution. Tada! Instant interoperability.

If this doesn't seem immediately stupid, please give yourself a good slap and get a job somewhere where you don't have the option to impose your half-wittedness on anyone impressionable enough to believe in this garbage --- the flow must be stemmed!

In short, if you have very hierarchically structured data, which is only likely to be processed in languages which provide easy XML parsing, and no-one is likely to have to write (or read, 90% of the time) the format by hand, then XML may be for you. Otherwise, you would do well to restrain that knee-jerk XML reflex and really think about how you would have best described your data in a world where XML never existed. Believe me, if this is news to you, you'll thank me for it.

I've recently finished reading Richard Dawkins' The God Delusion. I was pretty determined to not read it when it first came out since a) I object to specifically indulging in writing that I know I'll agree with --- I suspect that searching out compliant opinions leads to foam-mouthed Daily Mail reader behaviour and obstinate old man disease, and b) Herr Dawkins has been on a bit of an ego/PR trip in recent years, in an area which he's not really all that qualified to talk about. But then, as he points out in the book, it's not like religious "authorities" are really qualified to say anything meaningful about well... anything, so when Jo got a copy, I decided to steal it and finish it before her ;) On the whole, I have to say well done to Mr D. Okay, so the style is pretty rough --- much less honed than his sublime The Selfish Gene --- but I think that's a concious effort to come across as a nice and normal chap to all the Joe Faithfuls that he's hoping to convert. And he has done his homework --- lots of nice factoids and references, although one gets the impression that his library at home is entirely filled with books called "Why God Is A Big Fat Lie" and other, similarly subtle titles. (Incidentally, what a pity that aetheistic books tend to be as ravingly, lowest common denominator as their religious counterparts --- and even more of a pity that intelligent people like Dawkins and Christopher Hitchins don't try to buck the trend.)

Stylistically, it would also do the atheism case good if Dawkins could refrain from introducing any religious opinion with the prose equivalent of rolling eyes, nudges, winks and other unsubtle indications that he believes the religious speaker to be a credulous moron. Yes, Richard, we know you think the religious view is wrong --- the title rather gives that away --- but it would be much stronger and less infuriating to paint the opposing view in a neutral light and then destroy it on equal terms. Since his logical case is mostly robust (apart from some guff that seems to imply that any God must be so complex that He must have evolved Himself), the eye-rolling does him a disservice. On the other hand, especially in the later parts of the book where the style improves, Dawkins pleads rather nicely that he is a deeply non-confrontational person and that his passion for debunking dangerous and irrational points of view is what gets painted by others as militance. Undoubtedly the mix of ego and oft patronising tone don't help, but as a similarly non- confrontational person whose passion for debunking illogical or fallacy-laden arguments regularly gets them into trouble, I can certainly sympathise.

I've only encounted a few dodgy points in the argument, and there is plenty of new stuff to me, which surprises me. I suspect that a lot of people like me come to atheism from just observing the social structure of religion (as a way of controlling populations etc.) and the lack of need for a supernatural actor in well, everything outside the Church. I suspect that growing up in Northern Ireland, with its particular brands of religious nutters and the devastation of the pseudo-religious Troubles may have contributed to that view. But Dawkins has spent a good amount of time reading around and asking the a posteriori obvious questions... phrasing religion in terms of an evolutionarily stable strategy is a neat trick which he's well-qualified to perform, and happily his answer doesn't end up stinking too much of teleology. Dawkins does definitely have a talent for exposing the obvious questions that we just never thought about asking, and I felt as embarrassed at my short-sightedness reading The God Delusion as I did when reading The Selfish Gene. Incidentally, TSG is my favourite pop-science book for that very reason --- I initially didn't read it because I thought I knew everything it would say, but its elegant main point --- that the gene rather than the organism or group is the agent of natural selection --- immediately allows more complex behaviours at higher levels, such as altruism. Many of the same techniques (and, in fact, arguments) are re-deployed in The God Delusion to good effect --- it's not so much sleight of hand as a paradigm shift of the Necker Cube type. Dawkins also convincingly challenges ideas like the idiom that good scientists should state themselves as agnostic rather than atheist, making me wish I'd thought more about it than to buy into the initially appealing idiom: pretty much all of us implicitly use a prior-probability/Occam's Razor argument to not bother being religious, so the evidentiary basis clearly had something stringer than 50/50 to say on the existence of God.

One vague point is a possible misconception that characteristics of publicly elected individuals will be distributed with a spread representative of the public: this isn't actually correct if elections are run in a first-past-the-post style, which will have the effect of artificially clustering representatives around the modes of the public distributions. It's an interesting point, though, and I'll return to the issue with a speculative trudge through the deficiencies in the most prominent brands of democracy soon ;) Finally, in a nice touch, Dawkins doesn't have a particularly strong response to the suggestion that having all the squillions of electrons in the universe behave exactly the same way is weird, therefore God must be managing it. In fact, in quantum field theory it's completely natural to view electrons and other fundamental particles as excitations on a set of coupled manifolds distributed through spacetime. In a sense, there really only is one electron --- the whole manifold. It's particularly apt that this view was espoused by Freeman Dyson, who Dawkins awkwardly satirises (in a cringeworthy burst of excitement at his own comic genius) on the previous page.

So, on the whole, it's neither great literature, nor a patch on The Selfish Gene, but The God Delusion is fairly entertaining, well-researched and even those who are used to justifying their rationally-grounded lack of faith will find new, or more cogently-expressed, arguments to add to their arsenal. As for whether it will convert anyone else, who knows, but that such a book can both exist and shift so many goddamn units reflects well on the true distribution of public piety at a time when several prominent politicians in the UK have been declaring the importance of their faith and their belief in faith schools etc as a valid, and socially useful tool. Worth reading, whatever your prejudices.

I always have trouble submitting papers to the arXiv, on account of my tendancy to use a whole bunch of style files etc. that aren't in the standard arXiv collection. They aren't usually in my document source directory, either, but are spread around my system in various texmf trees. Accordingly, getting papers to upload is a pain (and if you try to upload just a PDF, arXiv detects that the PDF was made with TeX and refuses to accept it! Dang, foiled!)

So here's the method that seems to work for me.

1. Get the snapshot package, and use it in your document with the usual \usepackage{snapshot} 2. Run latex etc. on your document until it's happy (note, I use pdflatex pretty much exclusively these days, but arXiv will use good o' DVI-producing latex, so that's what you need to use when producing your submission) 3. If your document was called mydoc.tex, you will now have a dependencies file, mydoc.dep. This can be used to bundle your source files for submission. To do this, get bundledoc. 4. Run bundledoc on the deps file --- you may need to provide an explicit config file. Here's my command: bundledoc --config=$HOME/local/texmf/tex/latex/bundledoc/tetex.cfg mydoc.dep 5. You now have a tarball or zip archive, depending on whether you used the TeTeX/TeX Live or MikTeX config file. This should be okay for uploading to arXiv. Happy bundling.

Amazingly, the article on Python indentation I bashed out a year ago at the Manchester parallel programming workshop has become the most popular thing on this website. Even more than all the lovely night climbing stuff: it seems the 'net is an even stranger place than I thought! It's also been nice to have the occasional bit of fan mail about the article (and a "you're wrong" mail, which is fine, except that it really missed the point and got into a fight with the tabs-vs-spaces straw man).

Anyway, I was thinking about finally putting my head above the parapet and trying to suggest an explicit block ending scheme to the Python dev list, when I found this mail thread, the first of which which goes through all the same experiences and reaches exactly the same conclusions as I did some 13 years later. Blimey --- what a way to be behind the times! George Reynolds seems a fully sane individual in my view, of course, and even manages to mention the problem of using Python where indentation is inconvenient/impossible, or even where the program must be expressed on a single line: I have been considering adding this to my own article, if I could manage to do so without cluttering, but I'll now leave George as the definitive authority.

The pragmatic reason for this post (there is one, really) is that Guido van Rossum himself chips into the debate, and even provides the "pindent" script for converting (legally-indented) Python programs to an explicit block scheme and back. A shame that the suggestion that such a thing be included in the Python interpreter never came to anything... if it hadn't been for the ugly "comment end block", this could have changed the face of Python some 10+ years ago. Now, however, I think we're probably stuck with what we've got. Let's see if I can get up the courage to bring this issue up for Python 3000!

Alors... another long time since posting but content yourselves with the knowledge that I've mostly been busy but not in the sort of way that I feel compelled to tell y'all about. Nyah.

Anyway, I recently had a "working" holiday masquerading as a Times photographer for Tom Whipple's recent article about Mont Blanc. A good wheeze --- I jetted to Geneva with (Hardcore) Dave Williams, met Tom and Al Young and then proceeded to spend the next few days running ourselves ragged getting a bit of practice and acclimatisation: with an intention to get up Mt Blanc by the end of the week we only had 4 days for preparation! We got rained off the Chapelle de la Gliere just as it was getting interesting, but the weather behaved itself on the second day and we had a perfect day on the Aig de la Perseverance that at least convinced me that months of no climbing hasn't hurt my ability to swing around on alpine V multipitches too much. So far so good.

After a late descent, we popped back down to Chamonix the next morning and by evening were up high again --- this time camping on the glacier at the Col de Midi as a huge thunderstorm came in. Very impressive, if not exactly ideal... well over a foot of snow fell on the tent during the night, making it bulge disturbingly until we knocked it off! Oh well: with time so short there wasn't much of an alternative. Unfortunately I suffered from my first altitude sickness during the night, so Dave and I canceled our intentions of climbing either the Chere or Jager Couloir on Mt Blanc du Tacul: a real pity on both counts. By the time I was able to move, Anna Grocott had come up from Cham and we climbed the Cosmiques Ridge back up to the Midi, encountering a dangerous and arrogant twat of a guide on the way. Having watched him send novice clients down an abseil off a jammed overhand knot, I'm severely put of the prospect of hiring a guide for any trade routes: while most are excellent and safe climbers, there are some extremely bad examples around.

I was still feeling pretty crappy from my altitude sickness, and the snow stompy bits of the Cosmiques had been disproportionately hard work, given that I had climbed the rock pitch bits pretty effectively with a heavy pack and not felt out of breath. I felt better on getting back to the valley, but in retrospect we suspect I had a chest infection that was stopping me from breathing properly: I certainly felt like I was repeatedly burning up my anaerobic reserves and then crashing, and trying to breathe deeply made me hack and cough. It's so obvious in retrospect!

The next day, after a night camping in Cham, we took the Mt Blanc tram to Ni d'Aigle and hiked up to the Gouter Hut on the Mt Blanc normal route via the Grand Couloir and Gouter Ridge. By this stage I'd pretty much convinced myself not to go to the summit the next day --- the ridge itself had been much more enjoyable than the prospect of a 5+ hour snow trudge in a queue of tourist climbers. However, Dave persuaded me to go for it, and in practice the hut and most clientelle were much more "climbery" than the clueless tourist climbers I'd been expecting... and there were fewer of them, too. And no signs of the expected rubbish and excrement. Score several points for the "Mont Blanc is being destroyed" line being oversold.

Being serial cheapos (and more importantly, tragically disorganised) we bivvied illegally above the hut, with a few other cheapo British types. Tip: bivvying without a tent at 4000m is just fine, indeed maybe better than with a tent since the latter continually flaps through the night, but it is a bit cold! In fact, so cold that normal cooking doesn't really cut it: our pasta was a cold, congealed nightmare within about 20 seconds! Eat in the hut or bring a clever insulated JetBoil thing if you're planning it: I will in future. The view from the ridge is amazing --- what a place to camp! --- but by heck is it windy!

A good, but wheezy night followed, with some amazing views down onto the lights of Chamonix and St Gervais over 3km below as I went for a mid-night wee. I'd even be tempted to go back up for a night of long-exposure and time-lapse photography. At 2am, chains of people began to pass us, but by the time we had got up, packed and stuffed a bit of confectionery into ourselves they were mostly gone. Bivvying is faff-inducing but that's not always a bad thing! From higher up we had some very cool views of the sporadic chain of headtorch light winding up the route --- another good long-exposure photo opportunity for a later visit. I wasn't in a good way, though, and within 20 mins was finding the going very hard: I couldn't breathe properly and my legs had no energy at all. The best I could do was to wheeze upwards at the head of the party, counting my steps incessantly and aiming to get over 30 before stopping to pant air back into my lungs. In the end I hit a pace I could sustain for more than 70 steps, but it was painfully slow: I was playing the slowing-down end of Nine Inch Nails' Closer in my head and it was at about half-speed! Amazingly, we kept catching up with the main group ahead of us... god knows how unfit they were! Every now and again, small parties would give up above us and we would pass them as they descended, looking ashamed and defeated. Each time, I thought "Well, I'm better than them, so I'll get at least to their high point!" While I wanted to give up, I couldn't do so without forcing Dave to stop and descend with me, so we just kept going at the painful trudge pace. Sorry guys, I couldn't make my legs go any faster!

The mountain just kept on going: over the Dome de Gouter, up to the Vallot refuge, and then on and on up the steep powder snow ditch/path of the Bossons Ridge. As we got higher, there were increasing pools of vom in the snow and we saw several guides dragging semi-conscious clients towards the summit. If you're thinking of hiring a guide to drag you to the top for summit bagging purposes, I have to say it didn't look fun, but then I don't understand the bagging compulsion anyway. Eventually, the ridge flattened, without really becoming spacious, the gorgeous sunrise disappeared in a painful wind of hard-driven spindrift and we were done. I flopped on my arse and cried uncontrollably to myself: there was no more god-damned up to be trudged and we could get on with the important business of getting down. Not exactly a glorious summit experience! I've never had such an emotional experience from exhaustion before: I had dragged myself upward continually for almost 5 hours after my body first wanted to give up. Ridiculously, we were a mere 10 minutes over guide book time: they must have timed it for mountaineering sloths!

On the descent, we stopped into the Vallot refuge, largely out of curiosity. It was a disgusting place --- full of rubbish, and smelling of rot. We ate some cake and, since my camera had filled with snow taking summit shots, Al snapped a pic of Dave and myself looking tired and grumpy among the debris. A few days later it was splayed across 2 pages of the "Times 2" supplement. How annoying... I carry an SLR camera all that way, snap 500 shots, and the killer image is the one where my camera is out of action! Then stomp, slide and trudge back to the Gouter Hut and eventually civilisation. It was a bad 12 hours for Mont Blanc: we saw one climber slip down the Grand Couloir to his death on the descent, and the next morning a huge serac collapse avalanche on the 3 Monts route killed 8 climbers and injured 8 more. Over 100 climbers have died in the Massif this season alone.

Later, in our campsite in Chamonix, we all looked up, and saw our route in profile, the wing whipping a lenticular spindrift cloud into existence along the summit ridge. "Thank god we don't have to do that again," said Tom. We all nodded.

Hey physicists! Lack of an observed Higgs boson getting you down? Well fret no longer: you can make your own, thanks to the miracle of ROOT! Look, here's one I made earlier:

Okay, so everything's wrong: it's not a very good impression of a Higgs, I know (and let's not even mention the dismal message that this sends about physicist aesthetics and the attention paid to typesetting by the ROOT authors) But this is a worrying effect, given that this is the CINT macro that produced it:

{
    double edges[19] = {-3.0, -2.7, -2.4, -2.1, -1.8, -1.5, -1.2, -0.9, -0.6, -0.3, 0.0, 0.3, 0.6, 0.9, 1.2, 1.8, 2.4, 2.7, 3.0};
    // Double-size bins                          ^    ^
    TH1F h("wrong", "This is not a real peak, it's just binning", 18, edges);
    h.FillRandom("gaus", 10000);
    h.SetMinimum(0.0);
    h.Draw();
}

Yes, that plot is a random Gaussian distribution, according to ROOT. The big peak on the RHS is created by the two bins of width 0.6 (as opposed to 0.3 everywhere else). I hope it's obvious that this is wrong! If it were a bar graph where the width of bins has no meaning, then it would be correct, but the idea of a histogram is that bin heights are set by the sum of weights in the bin divided by the bin width. Or, expressed as they tell you at school, a histogram's area, rather than height, is the thing that reflects the number of "events" in that bin. For differential distributions (i.e. densities), which account for about 99% of all physics distributions, histograms are the only sensible statistical display to use, since they maintain the distribution's shape as an invariant under arbitrary rebinnings: with asymptotically high statistics, a histogram should have heights equal to the mean value of the true distribution between the bin edges, a criterion which bar plots do not satisfy. Or, more loosely speaking, the choice of bin edge position on a distribution shouldn't have any significance!

This is a silly mistake, a schoolboy error. It's like trying to uniformly sample a spherical surface without accounting for the d(cos(theta)) measure factor: the 1D measures here are the bin widths. And it's a dangerous error from a physics perspective, as the plot above shows: in a real physics analysis, it's conceivable that you would bin more tightly around a region of interest, like a potential Higgs peak, in which case ROOT would actually display a dip! It's amazing that no one seems to have noticed this in 15+ years of ROOT being used by the HEP community. I don't use ROOT enough to know if this is a known issue --- students and postdocs that I've mentioned this to have been surprised. Maybe it reflects the tendency of the community to make private work-arounds rather than report bugs upstream --- not that my experiences of trying to report bugs on ROOT have been very encouraging --- or just that with the lack of LHC data no- one has made any non-uniformly binned histograms yet!

Given that my gripes against ROOT are well-publicised, it's with some trepidation (albeit also a fair chunk of smugness) that I'm writing this, but this issue needs to be publicised and fixed. The fix, fortunately, is just for the rendering system to include the width factor when calculating bin heights: the API's GetBinData(index) function name doesn't imply anything wrong about heights, it's just being used inappropriately. Fixing it should definitely be done, and wouldn't be hard, but it's difficult to know how much existing code relies on this behaviour.

High energy physics software (and, for all I know, academic software in other disciplines) is plagued by an obsession on using the system environment to define configuration aspects. This obsession has been applied to package dependencies, package behaviour and a host of other features, and is exceedingly misguided, being based on the simplicity of writing code to read in a configuration from the shell environment rather than using a configuration file.

The shell environment is not intended to be overpopulated with hundreds of environment settings for single projects: a well-written program should only use a few environment variables and at that they should be optional, designed to force a temporary change in behaviour. Any software that relies on users to add settings to their login scripts and .rc files is going about things the wrong way. This sort of environment dependancy leads to a plethora of users' systems in various degrees of misconfiguration, with the result that much time is wasted and scientific results may be trusted less.

Another aspect of this problem is that for projects where many different command shells are in use, separate and very portable sourced shell scripts must be maintained. This naturally leads to a broken system after several maintainer cycles, since it is hard to know several shell languages intimately enough to write very portable scripts in each: several maintainers will be required to keep the system configuration working and the end result is that scientific results may depend on whether the user was working in tcsh or bash/ksh shell! Worse still, the environment is also very susceptible to users' personal settings: I have seen several cases where .bashrc files used to choose favourite editors, set shell aliases and so-on have been responsible for the non-functioning of HEP experimental software: in none of these case were we ever able to work out why the clash occurred and it became "standard" practice to purge the shell environment before setting up a minimal environment to be populated by the experiment's environment-mangling setup scripts.

A much better system would be for the projects to use configuration files built on a robust and standard grammar (e.g. XML) rather than the environment to define the project's setup. Any project which relies on the shell "source" command to build several hundred of its environment settings is asking for trouble: the environment is not designed to be used in this way.

The logical continuation of this argument is an exercise for the reader :-)

Mantras for software engineers

There are certain aspects of software engineering that are so close to being fundamental truths that all developers should have to repeat them to themselves 10 times per day and twice on Mondays. They are independent of language, operating system and whatever editor or syntax highlighting scheme you hold sacred. If you keep these in mind, at least the worst errors are less likely to come up and bite you in the bum when you aren't expecting it. Here's an attempt to write some of them down: since I'm a very fallible person this list is bound to be incomplete and (horror!) possibly even misguided. Let me know.

1. Don't make one entity try to do more than one thing. This is so important, and so often ignored that it defies belief. Objects can do many things, but their components should only do one thing. The best historical example I can think of is that of old-school stack push-pop operations (which were firmly engrained in programmers' and computer scientists' conciousnesses) meeting the new world of threads and exceptions: it was eventually noted that pop could never be an exception-safe operation specifically because it reads and modifies the stack at the same time. Modern implementations of pop tend not to return the top of the stack they only throw it away am aesthetically nice solution is the explicit addition of a "peek" function. The moral lesson: atomicity is good. This example also has the nice feature that is shows how working with legacy code and engrained ideas can tie you into a world of pain, which can be fixed by taking a step back and thinking about how things can be simplified. 2. Keep it simple (stupid). Just because you can overload operators doesn't mean you should. Just because you could do the whole thing with one regular expression doesn't mean you should. Just because you could do it in Perl doesn't mean you should :-) In short, you or someone else will one day have to come back and re-hack code you wrote in the distant past: don't make them reverse engineer your cool tricks when "wasting" another carriage return would have made it clear as crystal. Good developers know when not to be clever. 3. Introduce version tags early With successful projects, you may end up with several versions of your library / file format / whatever "in the wild" at one time. If you didn't provide a versioning tag with your first release version, you are then in the nasty position of having to determine which version a given instance is by the absence of such a tag. Yuck. This makes handling "schema evolution" and related topics much harder and a great dela messier. So think about version tagging right at the start... otherwise you'll end up wishing you had access to a time machine (and that's an even harder problem!) 4. Comment your code Do I even have to elaborate? Okay, one elaboration: comment your code for use by an automated documentation system like Doxygen, epydoc, pydoc, JavaDoc...
2. Modularise agressively... ... but not too agressively! It all gets very Zen when you think about it: the key to success in most endeavours runs along the lines of "strong but supple". A series of near contradictions, whose solution is the thin line between success and failure. Well, that's rather pessimistic the line isn't that narrow and there are always shades of grey confusing the neat black and white picture but you get the idea. Provide a function if you can use functionality intwo places in your code. Provide a new module/package if you have substantial functionality that can be used outside your project. 6. Hide complexity behind interfaces Operate a "need to know principle". Interfaces are the key to this: a developer should need to know what to put in, what comes out and maybe some commentary on efficiency and alternative approaches. They shouldn't need to know how in detail your code achieves its specification.
3. Before you start, see if someone else has already done it Yes, I know your idea is so brilliant that it would take one person in a million to come up with it. There are millions of technical people, there is the birthday theorem (telling you that collisions occur with roughly the square root of the single event probability, so that one- in-a-million really becomes one-in-a-thousand). Chances are someone else has already made a start. Help them or use their work rather than learn their lessons twice.

I was pointed at this interview with maths/compsci/typesetting guru Don Knuth this morning. Apart from clearly being a magician in the Feynman sense*, it's wonderfully inspiring to see someone so at ease with the world and his place in it that he can say this:

Andrew: In late 2006, you were diagnosed with prostate cancer. How is your health today?

Donald: Naturally, the cancer will be a serious concern. I have superb doctors. At the moment I feel as healthy as ever, modulo being 70 years old. Words flow freely as I write TAOCP and as I write the literate programs that precede drafts of TAOCP. I wake up in the morning with ideas that please me, and some of those ideas actually please me also later in the day when Ive entered them into my computer.

On the other hand, I willingly put myself in Gods hands with respect to how much more I'll be able to do before cancer or heart disease or senility or whatever strikes. If I should unexpectedly die tomorrow, I'll have no reason to complain, because my life has been incredibly blessed.

Wow.

* "There are two kinds of geniuses: the 'ordinary' and the 'magicians'. An ordinary genius is a fellow whom you and I would be just as good as, if we were only many times better. There is no mystery as to how his mind works. Once we understand what they've done, we feel certain that we, too, could have done it. It is different with the magicians. Even after we understand what they have done it is completely dark. Richard Feynman is a magician of the highest calibre." --- Mark Kac

Last week I finally decided to waste some money and upgrade my computer speakers from the acceptable-but-a-wee-bit- harsh-and-tinny 50 Creative Gigaworks T20 pair that I've been using for about 9 months to a set of Bose Companion 3's.

The online reviews for the Creative Gigaworks speakers were just too good for me to ignore 9 months ago... and I think there's something to the advice that computer speakers with subwoofers will be boomy and unsubtle --- good for games maybe, but rubbish for music and wannabe-audiophile ears (like mine, ha!) But the moment I got them out of the box (mm, nice build quality) and plugged in (hmm, bit tinny...) I knew it wasn't quite right. Next time I'd just pay stupid money and get the Boses.

And so it has come to pass, and blimey they're brilliant. They are expensive, as any hi-fi nerd worth their salt will tell you, and yes I could probably have got the same sound for less by piecing together an amplifier from one manufacturer, floorstander speakers from another, and cabling from a third. But it doesn't matter, because these are tiny, come in one box, look and feel brilliant and sound outstanding. Convenience and aesthetics are worth spending money on, sometimes, and I didn't see anyone else selling speakers which produce sound of this quality from such tiny units.

Well, I nearly did. The Acoustic Energy Aegos were a serious contender and at a bit over half the price they certainly beat Bose on economic grounds. But life ain't so simple: the Boses are prettier, and they come with a beautifully designed little remote unit with a soft rubber volume control, touch-sensitive on/off panel and discrete headphone/input jack sockets. The AEs force you to rummage under the desk for the subwoofer to control the volume or plug your headphones in --- so I seem to have reached the point in my life where I'm prepared to pay 80 not to have to bend over. Life's funny, isn't it?

Anyway, my point is: if you listen to a lot of music through your computer speakers, and space and nice design are important things, then the Bose Companion speakers are fantastic little life-enhancing devices. Yes, you can do the same thing cheaper, for which the audio geek comments here may be useful, but you'll have to shop around a lot to find anything that does it with half as much style. IMO :)