]]> http://blog.ashtonmason.net/index.php?t=story&p=28 http://blog.ashtonmason.net/index.php?t=story&p=28 Sun, 01 Aug 2010 06:48:14 -0500 Some photos from our recent holiday on the Grecian island of Crete.

We spent a week in Crete in late July on a kind of package holiday, which we opted for because it was by far the cheapest deal for flight and accomodation.

As it turns out the apartment, in a resort in the resort town of Platanias, was actually pretty good. Platanias itself lacks any character now other than that imposed by tourism, but, unlike most other visitors to the resorts, we spent most of our time exploring the mountains and beaches of western crete by hire car.

I'll let the pictures do the talking, but basically Crete is a great place and well worth a visit: great driving roads (contrary to what many claim, they're not that dangerous if you treat them on their terms); wonderful, if simple, food; glorious weather; dramatic landscape; excellent beaches; gratuitous helpings of history.

You might be wondering why there are no beach shots, or shots of myself and Ania. They're all on Ania's compact camera - I might try to extract some.

We can only wonder, but what we can say is that this month's mix is up and running. Something of a relief, too, after June's got trampled underhoof amid a flurry of fervent coding.

Not completely convinced about the mixing in a couple of places in this month's mix, but I do like the overall flow and direction. Definately getting more into this sa/afro/funky/kwaito/laidback sound. I snaffled up a bunch of fresh tunes from traxsource today too.

As always, comments appreciated (negative as well as positive!).

I think I like this month's mix. It's a pretty fast and furious affair with quite a lot going on. Here are some sort of track times, for those who are curious.

00:00 Thicken - Gel Abril
01:45 Hiya Kaya (Original Mix) - Kentphonik
05:30 EP#5 (Original Mix) - Quentin Harris
09:40 Sunday Showers (Casamena Basement Mix) - Kentphonik
12:45 Mind Ckuf - DJ Cleo
18:00 Wena Ng'Hmba Nawe - DJ Cleo
22:30 Bongo Jam (L-Vis 1990 & Bok Bok's Refix) - Crazy Cousinz
25:00 Monopoly (Kenny Dope Remix) - Kenny Dope and Terry Hunter
28:30 Inflation - Crazy Cousinz
31:20 Neva Believe You - Movado

No Politics by Quentin Harris on Strictly Rhythm

Standard reminders apply: check out the mix, grab the feed, subscribe in iTunes, buy the records. Thanks for your attention.

Hyundai i-Flow concept interior

Sure there will be elements that are carried forward. But it's way too out-there for a production car, so will be massively toned down -- and I'm guessing much of the exterior will go the same way. Those wing mirrors for example are not going anywhere near a showroom floor.

Hyundai i-Flow concept wing mirror detail

Personally I'm in two minds about the concept -- there are elements which look great and which gel well with the current Hyundai design themes, like the fluid swage lines down the sides. But there are others which are just fanciful bordering on cheesy, and the car as a whole is way too busy IMHO.

There could be a pretty cool D-segment production car in there -- but it depends which bits make it into production!

Hyundai i-Flow concept exterior

Either way I would have been happier to see a concept that more accurately hints the future model -- the way the ix-onic concept quite accurately predicted the ix35.

Head on over to the pod for a listen, or grab it in itunes.

2011 Hyundai Sonata (Hyundai)

The Sonata is a midsize semi-luxury sedan sold mainly in the US and also Korean markets, where it is one of Hyundai's best-selling cars. If it ever made it to Europe it might perhaps be called either i40 or i45 (its rumoured name in Australia).

Whereas the previous Sonata model sold mainly as a four-cylinder, it was available with a V6, like most other cars in the segment (large midsize semi-luxury sedans). Whilst few customers actually bought the V6, its mere availability lent the range kudos in a market besotted with power and size.

Now here comes Hyundai admitting that in the new Sonata range no V6 option will be available. At first sight this seemed even to me like a pure concession to the economy: we can't justify it in the current climate so will take this hit and grin and bear it. How would that compare to the Hondas and Toyotas with which it does battle in a toughly competitive segment? What would the neighbors think?

But Reilly has it right. The deletion of the V6, while certainly helped by the downsizing economy, can also be seen as a bold masterstroke that few other manufacturers would have attempted. Hyundai has sensed the wind and moved swiftly to take the lead. The article spells it out: Hyundai knows its new engines beat the competition, even with only four cylinders. Four beats six in terms of weight, which is more important than power, in real terms (as even the US market is slowly realizing). Not having to support the mere possibility of a V6 makes even the four-banger considerably lighter and more nimble. The Sonata's fuel economy and emissions stories are both much improved by being market leaders across the range rather than just at the green-eating bottom end.

As Reilly points out, the removal of the V6 is impressive not just in the light of the current market conditions, but also as a sign of Hyundai's growing confidence. Many manufacturers would have just kept the V6 as a tickbox option, trying to eek out the safe path where the V6 is offered but relied upon not to sell too well. And the weight and handling of the car would have suffered -- even the four-cylinder.

At the risk of sinking further into blatant fanboyism, if there's one thing that characterizes Hyundai for me it's this lightfooted forward thinking. Perhaps it's to do with being a newcomer, or perhaps with being Korean. Hyundai never seem afraid or intimidated by change.

Examples are easy. In just the last couple of years, Hyundai produced their first rear-wheel drive platform, their first true sports car, their first in-house six speed automatic transmission, their first GDI engines, their first hybrid architectures. Even their base cars are overflowing with standard features which they seemingly implement on a moment's notice, from iPod connectivity to stability control to folding door mirrors. They're also now the leading manufacturer in the US in terms of emissions across the range, only a couple of years after promising to become so.

And the recent leadership isn't limited to technology: Hyundai's bold steps in the US during their current depression have made them one of the only manufacturers to grow in 2009 rather than shrink. Shortly after the bad news set in they announced their pioneering assurance program: sell back your new car with no impact on your credit rating if you lose your job. At the 2010 Superbowl Hyundai bought up millions of dollars of prime slots and became the lead advertiser. Not bad for a car maker in a recession.

Perhaps it's significant that Hyundai means something like progress or pinnacle in Korean.

The forum uses one of those image verification tests to distinguish real customers from automated attacks that fill in the form with random contents and hit submit repeatedly until they hit the jackpot. You know the kind of thing, there's an image of some garbled text and you have to type the words in the picture correctly. The one my hosts use is called ReCAPTCHA. I had the opportunity to use it for the first time last night.

in overmuch? apparently not.

Having tried and failed to log into the forum on the hosts' website, I assumed I had forgotten my password and tried to retrieve it. That's when the fun began.

Frustration turned rapidly to anger as repeated attempts at guessing the garbled words failed. One might assume the problem was that the words were too garbled, but actually they're pretty easy to read (with a few exceptions, which you can just pass on by requesting another).

No, the problem seems to be that ReCAPTCHA is a pile of poo. Check out the examples I saved and judge for yourself: am I blind and illiterate, or is ReCAPTCHAa's verdict just plain wrong? These are not occasional failures either: when I was gathering these, six out of seven repeated tries failed. One did succeed -- perhaps that's considered enough.

Better yet, have a go yourself. The site to go to is this one. That's the lost password retrieval page. There are two boxes: in the first, enter any old email address (preferably make one up). In the second, guess the words in the picture. Hit the big button below that, and tensely await the result.

If it says You have not entered an email address that we recognize then we got the words correct (yay!), and it's gone on to bitch about the fake email address. But if it says The string you entered for the image verification did not match what was displayed then we can only assume that we guessed wrong, hit back, and try again.

Hell, try a few times. If you're like me, sometimes you'll be lucky and ReCAPTCHA will turn a blind eye to your errant ways. It seems to go through patches of good will. But then its mood will change -- like that -- and it won't let anything past it. Let me know how it goes.

Oh and if you fancy trying your hand at a real challenge, try the audio version. Click on the little red speaker next to the box. You'll need sound. Go on, give it a try.

Dhoom:2 by Yash Raj Films.

The mix is called Risen, referring partly to the rise of modern India as one of the world's new superpowers.

As a European or American, it's good to be reminded occasionally that Bollywood produces more films than Hollywood (and makes more money).

Films in India are more overtly a cultural expression than in Europe and the States. Whole families go to the cinema to see their favourite stars, cheering the good guys and booing the bad guys, dancing in the ailes to the chart-topping tunes.

Risen also refers to the way the mix progresses from rough and dirty street music, through love songs and club tunes to flowering female vocals, finishing with the brilliant Aaj Ki Raat from Don (more recently featured in Slumdog Millionaire, where gangsters are shown watching Don on TV).

So this month's edition is a tribute to Bollywood, and also to Channel 4 for their recent Indian Winter feature. Those who caught the movie Dhoom:2 might recognize the track Dhoom Again in this month's mix.

Click through to the monthly mix for more, and remember to hit subscribe.

Since it's called the monthly mix, I guess I've signed up to produce one a month. The first episode is basically house, but in quite a rhythmic style and fairly chilled, with a South African township flavour here and there. If the word house conjures up images of sweaty bare-chested blokes and smoke-filled clubs, bear with me (or should that be bare with me?).

And as far as future episodes go, who knows? It won't be just house, that much is certain.

The feed address is http://pod.ashtonmason.net/feed.php?channel=monthly. For those new to podcasts, you can subscribe in iTunes, for example, by going to the Advanced menu and choosing Subscribe to Podcast. You can also download the first episode directly as an mp3 file from here.

Be sure to let me know what you think.

A cracking smoothie.

When I first got into making smoothies I leapt head first into the whole idea, making them both days of every weekend and sometimes even before work during the week. They replaced my regular muesli as breakfast. Of course, later the novelty wore off and the difficulty of having ripe fruit on hand all the time, especially in Winter, took its toll.

These days I make them when I get the urge, and when I remember to buy enough fruit in the supermarket, which I guess is the best way. Although we generally have fruit at home we don't so often have the types that make for really good smoothies: melons, tropical fruit like mangoes, luscious berries and cherries.

Here then, my top tips for great smoothies.

• While the most commonly available fruit like apples, pears and oranges are useful in smoothies, they're best thought of as ''basenotes''. They need something layered on top of them to be really interesting.
• The most sure fire basenote fruit is banana. It's hard to go wrong with two or three good ripe bananas.
• The less commonly available fruits like mango, papaya, melon, strawberries, blueberries and cherries make for real interest in a smoothie. It's often a good idea to layer a couple of these, in smaller quantities, on top of a broad basenote like pear or banana.
• Making smoothies is easier in Summer, when there's lots of good quality fruit around, but it's still possible to make some damn good smoothies in Winter. In the UK Winter the shops are full of berries and cherries -- although they're not seasonal locally of course and have been either imported or stored -- and these make for great smoothies.
• Don't get carried away! A few ingedients is usually enough. More than about four, and the tastes start to get too mixed up.
• Really dark fruit like blueberries, strawberries and cherries can easily overpower everything else. Treat them like the hand-picked specialities they are and use them sparingly.


A cracking smoothie waiting to happen.

• Don't use unripe fruit. If bananas aren't ripe they aren't worth using. They're definitely not ripe enough if the skin doesn't peel away cleanly from the fruit. Use something else or wait a day or two and use them then.
• Overripe fruit is fine for smoothies. In fact, smoothies are a great use for those partly blackened bananas that otherwise would get thrown away.
• You can tell how good it'll taste in a smoothie by smelling it. Bananas and melons that don't smell great while still whole won't taste great in a smoothie. I won't buy a melon if it doesn't smell like a melon. Bananas of course will ripen over a few days, but some are grown for looks rather than taste. It's always worth giving them a sniff.
• While mango in general is a good smoothie fruit, try to track down some Pakistani honey mangoes for a real flavour adventure. In the UK they're only available in summer, when they're sold in Indian areas like Alperton near Wembley. At the height of summer you can hardly walk down Alperton high street for honey mango salesmen, then suddenly a few weeks later they're gone. They sell them in boxes, usually for pretty good money. Expect to pay around seven quid for a box of six large mangoes. Delightfully, the boxes come decorated with strands of tinsel.
• Peeling and stoning fruit can seem like hard work. But there are time-saving tricks for most of the real hardball cases. For cherries, try cutting right around them with a sharp knife -- rolling them on under the knife on a chopping board works best -- then twist the halves apart in your fingers to separate. Unfortunately the stone stays embedded in one of the halves, and that still has to be dug out by hand -- let me know if you know a better way. The same approach works for avocados, by the way.
• For mangoes, you can buy specialized mango stone removers. My mom, a bit of a smoothie fan herself, introduced me to these. They work a bit like olive pitters, slicing an elliptical hole right through the mango from top to bottom and removing the stone in the process. Once the stone is out and the flesh is in two halves, you can get the flesh off the skin easily by scoring the flesh in a checkerboard pattern with a knife and then removing the cube-shaped checks one at a time.
• Yoghurt does work well in a smoothy. I prefer to use yoghurts that aren't too heavily flavoured or sweetened. But that's just me.
• A little bit of water helps to get things moving in the blender, and makes the smoothie, which otherwise can actually be too rich, go a lot further in the glass. Fruit is a highly concentrated source of energy and sugar and there's nothing wrong with diluting it a bit.
• Surprise ingredients include dates, pecan nuts and honey. You don't need much to add a bit of extra zing.

Maximum stay 4 hours ... for 30 minutes. Eh?

Spot the parking voucher sign. Here's a clue: it's upside down.

See the parking voucher sign? Come on, the guy behind is hooting.

Instead of good old fashioned money, many of the parking spaces in Richmond require parking vouchers, paper slips that can only be purchased in particular neighbourhood shops. The shops, generally corner shops and newsagents, are helpfully designated by 'R' stickers in their windows.

Has anyone in Richmond council actually tried finding a shop that sells parking vouchers in busy traffic in an unfamiliar town? It's all very well if you're a resident (in which case you probably have a residents' parking permit anyway), but as a visitor you're not likely to have a bunch of Richmond-specific parking vouchers stashed in the glove box. We all like a bit of fun now and then, but I somehow doubt the councillors themselves are playing by the same rules.

Finding a parking space is a challenge in itself. Having found a space, the driver parks and deciphers the traditionally confusing roadside sign, only to find that their car is parked illegally and their carefully hoarded spare change is useless.

Instead they require an elusive permit which can only be purchased, mysteriously, from shops showing the all-important 'R' sign. There's no indication what kind of shops these might be, but one assumes they must be newsagents rather than, say, hair salons or Indian takeaways. At any rate it's back in the car in search of an 'R' sign, since there are no likely shops visible nearby.

To make the game more challenging, it turns out the 'R' signs are quite small. And as luck would have it, the windows of the local corner shops that sell them are invariably covered in a hundred other brightly coloured signs, advertisements and notices, making it almost impossible to identify the target sign from a moving car. Well, you wouldn't want it to be too easy, would you?

Brilliantly, having finally spotted a shop showing the sign, the driver then needs to park to go inside and buy a voucher ...

Hyundai i20

To me, they fall into two main camps. Some are glowing with praise and, tellingly, a slight sense of shock. Others, like this one, at best dutifully list the standard features, performance and warranty, then mysteriously conclude with a rating of average, saying, effectively, "nice car - but of course you wouldn't want to buy one".

As the keen owner of an i20 this second type do slightly get on my nerves.

I do agree with the basic point here that with the i20, Hyundai once again missed an opportunity to make a strong statement. They had a car which, had it been sold as a Ford, Vauxhall/Opel or VW, would have been praised as extremely accomplished and a great buy. But as Hyundai they needed to avoid the trap of seeming to be copying everyone else. And it's in that, subtle secondary sense, that they arguably messed it up.

Hence there's no shortage of sour reviews like the Guardian's where the reviewer can clearly find nothing at all to dislike, but fundamentally doesn't want to like the car, so instead falls lazily back on the familiar narrative of poor Korea trying to be more European - and failing, of course (ha ha).

Hyundai i20 rear light cluster.

A few facts then that the reviewer left out: Best in class standard features, near best in class performance, solid handling and driveability, best in class fuel economy and emissions, German-level build quality, best in class warranty and reliability, best in class safety and NCAP rating, and - best of all - best in class price.

Whilst I know better than to take mainstream car reviews too seriously, it seems a particularly wild piece of journalistic theatre to ignore these facts, spin a mildly xenophobic yarn about nuclear weapons, and conclude with a smug verdict of unremarkable.

One thing that irritates me in particular is the double standards in reviewing the 1.2 model and then complaining that its performance is lacklustre. Of course it is - it's the 1.2. They miss the point that the 1.2 engine is a brilliant piece of engineering: a direct injection, variable valve timing, all-aluminium masterpiece that is the best engine of its size available, in practically any score you can think up.

For some reason, few bother to review the 1.4 model. This may have something to do with the fact that Hyundai themselves push the 1.2 as the clear best seller (although a glance at AutoTrader suggests there are as many 1.4s about as 1.2s). The 1.4 too is among the most fuel efficient engines on the market in its capacity, yet, at 100 bhp and 100 lb ft, outperforms similar engines from almost any competitor (including Seat, VW, Opel, Mazda and Ford).

Hyundai i20 at the edge of a Scottish loch

Instead, the i20 seems to be implicitly judged against the larger engined or turbo versions of competitor cars. For that reason it would help a lot if there were similar performance versions of the i20 available here -- even if few were actually sold (something Hyundai seems to not yet have understood about the European market).

Lastly, the complaints about the shape. This has always mystified me. The car, to my eye, is actually better looking than some (though granted not all) of its rivals. Only a mother, and all that, but it does grow on you and it took me a while to really 'get' it. It's true that it borrows too much and adds too little, and its most unique feature - the curve of the character line at the rear haunches - strikes me as uncomfortable and overdone. Still it's by no means ugly.

If anything the i20's mistake is to be too smoothly good and too subtle - it lacks a strong key feature to make it stand out. But don't let that, or half-assed reviews like the Guardian's, put you off.

Movie poster for Main Aurr Mrs Khanna

We had originally intended to see Up, the new Disney/Pixar film, at the Cineworld in Wandsworth. But at the last moment we veered left onto the M25 and drove towards Feltham instead, largely to avoid the seven or eight speed cameras, on the A3 between Esher and Wandsworth.

Most people seem to have worked these into their routine: dashing along at ten or thirty miles per hour above the limit, then slowing suddenly en mass right before the cameras (which are a square foot in size and bright yellow). But while I can manage the sudden slowing easily enough, instead of starting to seem normal, the whole thing has just become more and more annoying.

It's not having to slow down that irritates me: it's the sheer bloody-minded pointlessness of a system which is perpetuated, for greed, in spite of it clearly not working. And that's tolerated so placidly by us, the public, in spite of the fact that a good 60 or 80 percent of us clearly don't believe it's a sensible solution. But then, this is the same country that put up with eleven o'clock pub closing times for fifty or sixty years with hardly a complaint.

So instead we drove to Feltham. However on arriving it turned out that Up wasn't showing -- and none of the other films seemed appealing -- so instead we decided to watch a Bollywood film called Main Aur Mrs Khanna.

It's not unheard of for us to choose Bollywood over Hollywood. When we lived closer to Wandsworth we belonged to the Cineworld (nee UGC) Unlimited club, whereby we could watch any film at any time for a flat monthly fee. When going to the cinema is effectively free you consider seeing films you otherwise might not risk seven or eight quid on.

After a time we developed quite a taste for them. They're all musicals, of course, and their style is quite different from Hollywood films, or even European ones. But given that Bollywood makes both more films than Hollywood and more money, it seems churlish to dismiss them entirely due to some kind of basic cultural prejudice. We watch Spanish films with subtitles, so why not Indian ones.

Movie poster for Lago Raho Munna Bhai

And in truth some of them are good. Lage Raho Munna Bhai for example, a warm and satisfying comedy about a likeable small-time gangster who meets the ghost of Ghandi (and wins the girl, to a rousing Bollywood soundtrack). Or Taare Zameen Par, a faultlessly told story of a young dyslexic boy's experience of prejudice and ignorance of his condition at school.

Sadly less the case with Main Aur Mrs Khanna, which is more your standard blockbuster romantic comedy, Bollywood style, told with lashings of glamour and glitz but questionable production values. As bad as say, a bad American romcom, but in Hindi.

Something which always surprises us is the reaction of the cinema staff and the audience. The people watching the Bollywood films are, without exception, entirely Asian. It's safe to say I've never seen another European. This causes some interesting situations where the staff assume you've been inadvertantly given a ticket for the wrong film. They try -- and fail -- to find a delicate way to explain that the film is an Indian film, in Hindi, and so clearly not your thing.

The other cinema goers are equally surprised. Some are even moved to come over and ask you questions, bewildered and confused.

Bizarrely, the question they always ask is not why we chose the film, but rather how we understood it. Which is amusing, given that the films generally have English subtitles. Either they're so used to not reading the subtitles that they've forgotten they're there, or they can't imagine how any westerner could hope to understand or enjoy one of their films, even with the aid of on-screen clues. It's true Bollywood cinema is a cultural expression - with more ritual and significance than your or my average night out to see the new James Bond.

And it's true the subtitles aren't always the best help. Often you can tell they're wrong, even though you don't understand a word of Hindi. And astoundingly, even the English parts of the films -- Bollywood is liberally sprinkled with Hinglish -- are very often 'mistranslated'. In last night's film Swissair was translated as Cathay Pacific. Sometimes the character on screen will say "Okay that's great" in perfectly understandable English, and the subtitles will read "Let's go, I'm hungry". Weird.

Production model of the Hyundai ix35, replacement for the Tucson.

For a couple of years now Hyundai have been making moves upwards in terms of brand visibility. Their quality and technology has been world-class for some time but their market image has taken a while to catch up, partly due to some styling and branding decisions that reflected their South Korean ancestory more than Western ideas about desirability and design.

Ever quick to address problems, Hyundai established a European center in Germany where their latest line of models for the European market were designed and engineered. These new i series models, such as the successful i10 and i20, have designs more in touch with European tastes and are also showcases for Hyundai's world-beating engineering and quality.

The latest in this series, the ix35 is essentially the replacement for the Tucson. The Tucson is already one of the best-selling SUVs in Europe but was a lower-profile sibling to the impressive, but still not quite world-class, Sante Fe. In some markets, such as the US, the ix35 will still be marketed as a Tucson.

Given its ready-made credibility as the replacement for the successful Tucson, the ix35 seems perfectly placed to sell in bucketloads. With confident, Europe-friendly styling and segment-leading performance, fuel economy and environmental creds, plus the usual Hyundai tech-fest of standard features, it promises SUV practicality with hot-hatch desirability while managing subcompact-level economy.

The Hyundai HED-6 ix-onic concept.

What impresses immediately about the ix35 is that the final production model has retained much of the bold styling of the HED-6 ix-onic concept car on which it's based. Hyundai have a long tradition of showing inspiring concept cars and then finally releasing them as conservatively diluted production models. The good quality but somewhat stodgy i30, based on the well-received HED-3 arnejs concept, a case in point.

The new Hyundai R-diesel engine.

The ix35 is due for official debut at the Frankfurt motor show on September 15. Hence it's not yet clear exactly which engine and transmission features of the concept will make it into the production model. Still it seems a safe bet that the newly developed two-liter R-series diesel engine will be offered for the first time, and the in-house developed twin-clutch 6-speed automatic gearbox is a possibility.

With power and torque figures that beat equivalent engines from BMW and others by around 20 percent, plus lower emissions to boot, the R-series engines look extremely promising.

The in house automatic gearbox design makes Hyundai/Kia only the 3rd automotive manufacturer to have developed their own 6-speed automatic transmission. Reports on the net claim the design boosts fuel economy by 12 percent, is 12kg lighter and has 62 fewer parts than the preceding 5-speed model.

Also featured in the ix-onic concept was a 1.6 turbo petrol engine with claimed CO2 emission figures of 149g/km, which would make it the envy of many hot-hatches. Rumours suggest this engine may be available as an option. I believe Hyundai needs to introduce more turbo models, since they are clean and combine performance figures with impressive fuel consumption. For that reason I'm really hoping the ix35 will offer this engine as an option.

Hyundai HED-6 ix-onic interior.

I'm also hoping the interior of the ix35, which looks good though neither as wild nor as refined as the concept's, will mark the start of world-class interiors from Hyundai. The i20 that I drive has a well-designed and ergonomic interior with good fit and finish, but the quality of the materials, particularly some hard-touch plastics, isn't up to the levels of, for example, Ford or Volkswagen. Small details like that trigger lingering perceptions of the Hyundai brand as low-budget and are invariably talked about in reviews. It's time Hyundai offered an interior that matches its engines and exterior construction quality, even if only as a luxury trim option.

Hyundai seems to not always have understood the halo effect that operates so strongly in the excruciatingly brand-conscious European market. A budget interior in an entry-level trim option won't even be commented on in a review if it's understood that a luxury version is available. A marque is judged by its flagship models, and the market perception follows suite.

That's also why it's a significant failing that there's no screaming, turbo-powered hot-hatch version of the i20. Whereas the i20 has succeeded in beating old ideas about the brand and been accepted as a contender in the safe, economy-minded end of the subcompact market, reviewers still regard its performance and desirability as mediocre, in the face of 0-60 figures that are easily a match for equivalently-engined cars from Volkswagen, Vauxhall and Ford. The reason? There's no turbo Cupra or VXR edition of the i20 to establish it as capable of drool-worthy performance. Instead the i20, if anything, is associated with its best-selling entry-level city car sister, the i10.

It matters little that the Cupra and VXR edition sales constitute only a few percent of total sales of their respective models. Their mere existance creates credibility for the standard editions that customers actually buy. If Hyundai wants to finally see off the budget image it still has in Europe, it needs to start releasing hot versions of its cars. And bringing the Genesis Coupe to Europe wouldn't be a bad move either.

Most programmers are familiar with the idea that numerical calculations on computer have limited accuracy. Basically, you can't trust the accuracy of floating point results. A simple example shows what we mean.

A common operation in computational geometry is testing a 3D point againt a plane. The aim is to see whether it lies on, below, or above the plane. The plane is commonly defined by a normal vector n (perpendicular to the plane) and a constant d. The plane is defined as the set of all points p such that the dot product of p with the normal vector n is equal to d.

const float dot = Dot(p, n);
if (dot == d)
{
    // Point p is on the plane
}

Note that p and n are floating point vectors, d is a floating point value, and Dot is a floating point vector operation:

At this point seasoned coders will hear alarm bells ringing. We can't rely on the computed value dot being exactly equal to d, even for points p which are legitimately on the plane. Why?

First, because the floating point calculations in the Dot function will have limited accuracy. This means that even for perfectly accurate input values for p, n and d, dot is not guaranteed to equal d.

Secondly, the inputs p, n and d are often themselves the computed results of other floating point calculations. This means their values are not guaranteed to be accurate to begin with.

Combined, these two sources of error mean the value of dot will typically differ from the intended value by some error whose maximum absolute magnitude is bounded by an unknown term e. The maximum error e depends on both the error bounds of the input values p, n and d and the accuracy of the operations performed by Dot. Errors tend to accumulate: adding values together adds their maximum errors; multiplying values multiplies their errors.

Given this knowledge, a safer version of the code above might look like this:

const float dot = Dot(p, n);
static const float e = 0.00001f;
const float distanceFromPlane = Abs(dot - d);
if (distanceFromPlane < e)
{
    // Point p is on the plane
}

Here we've introduced a compile-time constant e, often referred to as an epsilon value, to approximate the maximum error of the calculated result dot.

It's important to understand that the arbitrary value of the epsilon term e used here is a guess. It's an approximation, both in the obvious sense that we can't in general be sure of the maximum error of calculated results, and also in the more subtle sense that the maximum error will vary dramatically depending on where the input values came from.

Input values that come directly from a source with a known maximum error can be trusted to have errors bounded by that maximum. However, input values that are themselves the results of successive earlier calculations will contain accumulated errors that are orders of magnitude greater. To know the maximum error in a calculated result, we have to know the error bounds of the inputs.

Ideally, floating point values would each come as two parts: the actual represented value, and an error bound representing the known maximum error of the represented value. Even better, hardware types should have these error values built in. They don't, but it's possible to roll our own in C++ using a class to replace the built-in float type:

class Float
{
public:
    Float(const float value, const float error) :
      mValue(value),
      mError(error)
    {
    }

    Float(const float value) :
      mValue(value),
      mError(value * 0.00001f)
    {
    }

    operator (float)() { return mValue; }
    float MaxError() { return mError; }

    Float operator+(const Float &other) const;
    Float operator-(const Float &other) const;
    Float operator*(const Float &other) const;
    Float operator/(const Float &other) const;

private:
    float mValue;
    float mError;
};

Float a(5.0f);
Float b(3.0f);
Float c = a + b;

The definitions of the arithmetic operators account for the accumulation of errors:

Float Float::operator+(const Float &other) const
{
    const Float result(mValue + other.mValue, mError + other.mError);
    return result;
);

Float Float::operator-(const Float &other) const
{
    const Float result(mValue - other.mValue, mError + other.mError);
    return result;
}

Float Float::operator*(const Float &other) const
{
    const Float result(mValue * other.mValue, mError * other.mError);
    return result;
}

Float Float::operator/(const Float &other) const
{
    const Float result(mValue / other.mValue, mError * other.mError);
    return result;
}

Note that errors are added even on subtractions, and multiplied even on divisions.

Now that every floating point value comes with a silent partner recording its maximum error, we can define less-than, greater-than, equal and not-equal operators that take the error ranges into account to provide confidence in our comparisons:

bool operator<(const Float &left, const Float &right)
{
    return (left.mValue + left.mError << right.mValue - right.mError);
}

bool operator>(const Float &left, const Float &right)
{
    return (left.mValue - left.mError > right.mValue + right.mError);
}

bool operator==(const Float &left, const Float &right)
{
    return !operator<(left, right) && !operator>(left, right);
}

bool operator!=(const Float &left, const Float &right)
{
    return operator<(left, right) || operator>(left, right);
}

These are just sample implementations, but they give the flavour. Basically we're treating each represented value as a range [min, max], where min is the stored value minus the maximum error, and max is the value plus the maximum error.

If we have confidence in our accumulated error bounds we can say with absolute certainty that one Float instance a is less than another b, or b less than a, if their possible ranges don't overlap. Likewise if either a<b or a>b then we can say with certainty that a!=b. However if the plausible ranges of a and b do overlap then things are less clear. We can't say with certainty that a<b or a>b, and we admit that a==b since there exist possible values of a and b that are equal.

Although implementing a custom floating point type like this is certainly possible, it's not often done. One reason is efficiency: it doubles the cost of every numerical operation.

Another feasible but expensive option is the use of custom types with variable precision. If we're willing to use complicated dynamic types with internally adaptive precision then we can represent any value to any required degree of accuracy, avoiding numerical precision issues almost entirely. However this too is a heavyweight option not often used in realtime code.

Instead people writing performance-critical code typically rely on simple epsilon-based tests, as we showed earlier. A not-too-expensive finessing of the basic epsilon test is to use dynamically computed epsilons instead of compile-time constants. This allows us to approximate the error bounds of a calcation's input values, calculating from them an approximate error bound for the calculated result:

static const float noiseFactor = 0.00001f;

// Compute a magnitude-dependent epsilon term
const float eP = Magnitude(p) * noiseFactor;
const float eD = d * noiseFactor;
const float e = Max(eP, eD);

const float dot = Dot(p, n);
const float distanceFromPlane = Abs(dot - d);
if (distanceFromPlane < e)
{
    // Point p is on the plane
}

Here we've assumed that the error bounds of the input values are some arbitrary factor of their magnitudes. This relatively inexpensive trick exploits the fact that the maximum error in a calculated value is generally proportional to its magnitude. We use an assumed noise factor representing the typical error component of computed values. The remaining limitation of this improved method is that it ignores the fact that values from different sources will have accumulated errors that differ by orders of magnitude. But it's an improvement over the compile-time constant epsilon used earlier.

This relatively inexpensive trick exploits the fact that the maximum error in a calculated value is generally proportional to its magnitude. The larger the value of a floating point number, the more bits are devoted to representing the part of the value before the decimal point, and the less remain to represent the fractional part.

Another way of thinking about this is to imagine the finite number of unique real values representable by a 32-bit float layed out on a number line (all 2^32 of them). Whereas a fixed-point representation would result in values that are evenly spaced across the line from the minimum value to the maximum, the values representable by a float are "bunched up" near zero, and become further and further apart as the magnitude increases.

A subtlety of our improved magnitude-dependent epsilon calculation is that it fails in situations where the magnitudes of p and p are close to zero. In these situations we can compute an unrealistic, vanishingly small epsilon value.

As a practical example, consider the case where the plane we're testing against passes through the origin. That implies that d is intended to be zero. (If it was computed, its actual value is likely to be some very small number). In the situation where the point p being tested is near the origin, its magnitude will be close to zero as well. As a result, our epsilon calculation will produce a vanishingly small value:

static const float noiseFactor = 0.00001f;

// The value we compute for e is a very small number
const float eP = Magnitude(p) * noiseFactor;
const float eD = d * noiseFactor;
const float e = Max(eP, eD);

This would be fine if the actual error in the computed result dot was indeed bounded by some factor of its magnitude. However in reality there are sources of error that are independent of the calculation magnitude. Although small, these errors are likely to be larger than our computed e value. The result is that we're unable to detect the point p as being on the plane.

We can address this failure by including a constant term that approximates a minimum error bound expected in any value, irrespective of its magnitude:

static const float noiseFactor = 0.00001f;
static const float minError = 0.0000001f;

// Magnitude-dependent epsilon plus minimum expected error
const float eP = Magnitude(p) * noiseFactor;
const float eD = d * noiseFactor;
const float eMag = Max(eP, eD);
const float e = Min(eMag, minError);

const float dot = Dot(p, n);
const float distanceFromPlane = Abs(dot - d);
if (distanceFromPlane < e)
{
    // Point p is on the plane
}

It's important to realize that the specific values used for noiseFactor and minError are still nothing more than rough approximations. Typically different calculations require different values, depending on how much accumulated error the input values of the calculation are likely to contain. Some fine tuning is inevitably required.

As a final touch, we note that the use of Magnitude involves an expensive square root operation. We can avoid it by using the squares of values throughout the epsilon comparison:

static const float noiseFactor = 0.00001f;
static const float noiseFactorSquared = noiseFactor * noiseFactor;
static const float minError = 0.0000001f;
static const float minErrorSquared = minError * minError;

// Magnitude-dependent epsilon plus minimum expected error
const float eP = MagnitudeSquared(p) * noiseFactorSquared;
const float eD = (d * d) * noiseFactorSquared;
const float eMag = Max(eP, eD);
const float e = Min(eMag, minErrorSquared);

const float dot = Dot(p, n);
const float distanceFromPlane = Abs(dot - d);
const float distanceSquared = distanceFromPlane * distanceFromPlane;
if (distanceSquared < e)
{
    // Point p is on the plane
}

In this article I've hopefully introduced some basic methods for handling numerical inaccuracy in calculations. Much of this will seem overly complex, if you've not been exposed to situations where numerical accuracy is an issue. You'll have to trust me that when you are, you may find some of this stuff useful. In my work I've certainly found myself having to resort to this kind of complex (although still frankly unsophisticated) approach.

In future articles I hope to introduce other, higher level issues related to robust handling of numerical errors, with examples sourced from computational geometry specifically. Stay tuned.

Eilean Donan Castle

Evo ran a story on the roads in the northwest of Scotland in issue 127, February 2009. The author had good things to say about both the scenery and the roads -- memorably singling out the A894 as the UK's best driving road. "The truth is that the further north you head, the better it gets". Right then.

After staying the first night in Glasgow we left earlyish for the west coast, heading north up the no doubt well-travelled A82 past Loch Lomond and then breaking westwards on the A87 after Fort William. The A87 turned out to be one of the best roads in the whole trip. Great scenery too; a bit reminiscent of Wales.

I did manage to get pulled over by an ernest, greying Scottish traffic cop on the A82 just outside Glasgow. Mental note: it's not okay to amble past police cars at 50 mph in a 40 limit, up North.

Cloudy day in the Highlands.

After the A87 we headed north on the A890 and A896, which lead up the coast past a series of small settlements, some so small that they could barely be called villages. After the A87, the quality of these roads came as a bit a shock. Single track most of the time, with occasional widenings signposted as passing areas. No road markings and no hard shoulder - just rough-edged tarmac where the ground eroded away. And the roads lunge randomly this way and that, following every whim of the landscape rather than ploughing their own path, constantly throwing up blind summits and surprises.

(Makes you realise how much work must go into building a good quality road: it's not just a matter of ladling down a dollop of tarmac and calling it quits).

Over these challenging roads -- the most difficult I've seen in Britain -- I was impressed with the fine Korean engineering (not to mention German suspension tuning) on the i20. The car feels solid and agile when pushed. It helps to lay into the corners, throwing the weight onto the leading wheels. The balance is well-judged, and you can push it wide sideways with very little body roll and without being forced into excessive understeer. Generally a pretty good place from which to tackle the A896.

This was something of a revelation, since in close-knit town driving the firm suspension and somewhat artificial steering can make the car feel a bit skittish and leaden at times. Not all the time -- it seems to make a difference how confidently you approach the car. It likes to be pushed and rewards feelsome driving.

After the ardours of the A896 we met some of the best roads of the long weekend pushing further north, on to Ullapool and then inland across to Inverness. Long sweeping arcs for corners, with perfect visibility and a good surface. Again the i20 felt right, the engine supple and the gearchanges slick.

Late afternoon on the Highlands.

I desperately wanted to head further northwards, past Ullapool and on to the A835 and famed A894, where "the further north you head, the better it gets". But it became pretty clear that that wasn't feasible. We had already used up half our allotted time -- most of that spent driving -- and were already committed to the same driving back. The A896 had felt like a race against the clock and the road. I didn't want to spend all of our waking hours driving. So reluctantly we headed away from the coast, towards Inverness.

The weather too turned against us, the sky overcast and the light a dull grey. Heading south on the A9 from Inverness towards Edinburgh the scenery, already less dramatic than the coastal and loch-bound roads of the day before, became drab and uninspiring in the flat, muddy light. Things didn't improve much until we returned to the more touristy stretches down south, the Black Water country for which the the Highlands are renowned.

To any like-minded souls seeking Scotland's best driving roads, I advise sticking to the A82 and A87 north of Glasgow, taking in Loch Lomond, Loch Lochy and Loch Ness up the great rift that divides the land in two from Fort William to Inverness. Then head out west towards Ullapool and start the journey north from there. The A890 and A896 are challenging, but too time consuming for a short journey.

Driving weather, Scotland style.

On the way back towards London the heavens opened and we drove through sheets of rain seemingly all the way through Scotland and down into northern England. The i20 felt surefooted enough to take on the wet roads at speed, the Pirelli P6000's with which I had replaced the standard issue Kumhos cutting through the rain and refusing to slip even on standing water.

At motorway speeds the 100bhp 1.4 liter petrol engine is enjoyably strong (for a small car), but it does help to be in the right rev range. I found 4500 rpm in fourth more useful for overtaking than 3500 in fifth.

A naked and a conventional, undoctored portafilter side by side.

The naked portafilter on my Silvia clued me in to the uneven pour. The sawn-off shotgun of the espresso world, a naked portafilter is basically a normal two-spout portafilter with the spouts rudely sawn off. Some online stores specialize in doing a backroom job and selling the modded part.

Going bottomless is the height of fashion in some circles, but believe it or not these puppies do also have real benefits. Removing the spouts lets you watch the coffee pour, which can be very instructive. Part of making great espresso is learning where you're going wrong in your tamping and grinding. If the grounds are tamped too hard, the coffee drips before it pours, and burns a blackish brown. Tamp with an uneven pressure, and the less tightly packed side will pour faster as the water follows the path of least resistance. On the fast side the coffee is weak and light in colour; on the slow side it's dark and burned. Ideally you want it to pour evenly from the whole surface at once.

Lately I've been noticing that the pour was consistently much faster at the front (nearest the handle), no matter how much I adjusted my tamping to favour the other side. Something wasn't right.

Used Silvia group gasket

Having run out of other ideas I decided the group head gasket was probably at fault. The gasket is a round black rubber seal hidden in the recess of the group head, onto which the portafilter is pressed by the wrenching action of the handle. Together the gasket and the portafilter rim form a tight seal which prevents the pressurized water from escaping, forcing it instead through the compacted coffee grounds in the filter basket.

The theory, then, is that if the gasket isn't sealing properly then the water can escape from one side, affecting the pressure. The best evidence was that I'd occasionally seen sprays emitting from the front of the group, as if the seal wasn't quite tight.

The new gasket arrived today, together with a new shower screen that I'd picked up purely to get the order total above the online order minimum. The shower screen is the metal screen through which the water is forced before coming into contact with the grounds.

Removing the old gasket and inserting the new one is easy enough, once you know the trick of screwing a couple of screws into the old gasket and yanking it out with those.

Silvia shower screen with slight dent at the screw hole

Looking at the old gasket, it seems in surprisingly good nick (the small holes are from the screws). Ordering the shower screen may have been a stroke of luck, since it's in rather poorer condition. It may be hard to spot in the picture, but it's dented inward around the central screw hole.

Pages on the web warn against overtightening the shower screen screw when replacing it after cleaning, for fear of denting the screen itself. So the new theory is, that's what happened.

And the results? Disappointingly, not quite conclusive. It still pours faster at the front, but probably less so. I'm left wondering whether there was just always a slight front bias: after all, I notice the water comes in from the back of the group, rather than from the top as I imagined. So maybe Silvias naturally have a slight front bias. Maybe another Silvia owner can let me know. In the meantime I might try putting back the old shower screen, to compare.

We took the i20 up to Scotland this weekend, leaving from Guildford on Thursday morning and arriving back on Sunday night. Something I've been wanting to do for a while.

Click through for the pictures.

As you may know, templates and class inheritance are the two main mechanisms of reuse in C++. One provides compile-time reuse, the other runtime reuse. To an extent the two can be used interchangeably.

Each use of public inheritance represents an abstraction point at which we introduce the possibility of interchanging several different related types by virtue of their common relationship to a parent type, or interface. The interface captures the API to which all derived implementations must conform.

class IReadable
{
public:
    virtual int Read() const = 0;
};

class Book : public IReadable
{
public:
    virtual int Read();
};

class Pamphlet : public IReadable
{
public:
    virtual int Read();
};

Although superficially different, templates fulfill a similar purpose. They define abstraction points at which types can be interchanged. By defining a class template we invite different types to be provided as its template parameters.

template <class IReadable>
class Reader
{
public:
    int Read(const IReadable *const readable) const
    {
        return readable->Read();        
    }
};

class Book
{
public:
    int Read();
};

class Pamphlet
{
public:
    int Read();
};

Often we want to make various parts of a complex type easily replaceable, to allow greater reuse. A C++ idiom I use frequently is a class template that accepts multiple template parameters, each specifying the implementation of a different component of the compound type. These policy classes dictate the policy for particular aspects of the overall operation. They can be either static (with only static member data) or instantiable (with non-static member data), or a mixture of both.

template <class Reader, class Writer>
class CompoundType
{
public:
    void Process(Writer *const writer, const Reader *const reader)
    {
        writer->Writer(reader->Read());
    }
};

The compound class template calls the methods of the policy classes. It may be provided with instances of one or more instantiable policy class constructed by the caller and holding context data specific to their implementations. Each policy class template parameter allows the policy of a particular aspect of the compound type to be replaced.

The compound template is often generic in the sense of being able to operate on a variety of data types, without knowing anything about them itself. The types to be used are specified by the policy classes as typedefs and static const variables that they expose (sometimes called traits). The methods of the policy classes accept instances of the trait types they define, and it all works out.

template <class Reader, class Writer>
class CompoundType
{
public:
    typedef typename Reader::InputType InputType;
    typedef typename Writer::OutputType OutputType;

    static const InputType INVALID_VALUE = Reader::INVALID_VALUE;

    static InputType Read();
    static void Write(const OutputType &item);
};

Another idiom you'll often find in my code is a class template whose job is simply to act as a wrapper around a collection of related functions. Typically the functions are templates and share a common set of template parameters. Instead of declaring the functions as global function templates, each templated identically on the same common template parameters, I stick them all in a class template as non-templated static member functions.

template <class Item>
class Wrapper
{
public:
    static Item Read();
    static void Write(const Item &item);
};

The wrapper class is a static class in the sense of not containing any non-static member data. It is not intended to be instantiated. Instead it acts more like a namespace, with one important difference: it's templated. Indeed, it's templated on the template parameters shared by its member functions.

The static class template provides a convenient place to typedef any convenience types that would otherwise need a separate typedef repeated in every function. Doing so has the pleasant side effect of making the typedefs available for use as parameter types of the functions. A case where this is particularly useful is when the typedefs define types that depend on the template arguments - something that is difficult to arrange in the global namespace.

template <class Item>
class Wrapper
{
public:
    typedef stl::vector<Item> ItemVector;

    static void Read(const ItemVector &items, const int numItems);
    static void Write(ItemVector &items, const int numItems);
};

Furthermore, unlike a namespace, the static class has public and private sections, so allows private definitions of internal types and helper methods which are not exposed to the user. In this sense the static class acts as a compound type.

In both of these idioms that I've outlined, as the number of template parameters grows they can become unpleasant to deal with. They must be repeated at the definition of every member function:

template <class A, class B, class C, class D>
class Template
{
public:
    typedef typename A::ReturnType ReturnType;
    typedef typename D::ArgumentType ArgumentType;
    
    ReturnType Method(const ArgumentType &arg);
};

template <class A, class B, class C, class D>
inline typename Template<A, B, C, D>::ReturnType
Template<A, B, C, D>::Method(const ArgumentType &arg)
{
    // Method implementation
}

I find it's useful to instead substite a single type context template parameter which acts as a wrapper for a set of template parameters. The first thing the class template body does is typedef convenience definitions that forward the actual contents of the type context, making them available as if they had been passed as conventional template arguments:

template <class TypeContext>
class Template
{
public:
    typedef typename TypeContext::A A;
    typedef typename TypeContext::B B;
    typedef typename TypeContext::C C;
    typedef typename TypeContext::D D;

    typedef typename A::ReturnType ReturnType;
    typedef typename D::ArgumentType ArgumentType;
    
    ReturnType Method(const ArgumentType &arg);
};

template <class TypeContext>
inline typename Template<TypeContext>::ReturnType
Template<TypeContext>::Method(const ArgumentType &arg)
{
    // Method implementation
}

Typical programs use a mixture of these idioms. The type context trick can often be used to simplify the other idioms. Often a single system-wide type context type can be used in the definition of several class templates within the system. Each picks out the individual contained types that it needs and simply doesn't reference the others.

template <class TypeContext>
class ReaderManager
{
public:
    typedef typename TypeContext::ReaderType Reader;
    typedef typename Reader::ItemType InputItem;
    
    static InputItem Read(const Reader &reader);
};

template <class TypeContext>
class ReaderManager
{
public:
    typedef typename TypeContext::WriterType Writer;
    typedef typename Writer::ItemType OutputItem;
    
    static void Write(Writer &writer, const OutputItem &item);
};

// Example type context
struct Context
{
    typedef MyReader<int> ReaderType;
    typedef MyWriter<int> WriterType;
};

The type context also serves as a centralized location where the parameterized types of a complex system can be defined once. This avoids the confusion of having multiple classes within the system define the same typedef, potentially differently.

template <class TypeContext>
class ReaderManager
{
public:
    typedef typename TypeContext::ReaderType Reader;
    typedef typename TypeContext::ItemType InputItem;
    
    static InputItem Read(const Reader &reader);
};

template <class TypeContext>
class ReaderManager
{
public:
    typedef typename TypeContext::WriterType Writer;
    typedef typename TypeContext::ItemType OutputItem;
    
    static void Write(Writer &writer, const OutputItem &item);
};

// Example type context
struct Context
{
    typedef int ItemType;
    typedef MyReader<ItemType> ReaderType;
    typedef MyWriter<ItemType> WriterType;
};

Although these idioms I've described may seem unrelated, they share a common theme, introduced by the use of templates. Each uses classes that act as containers of types, rather than of data.

The static and non-static components of C++ classes are somewhat independent: one exists at compile time, the other at runtime; one is static, the other dynamic; one is about types, the other about data (instances of types). In practice particular classes may be either entirely static or entirely runtime - and many are both. Although runtime classes with occasional use of static members are well understood, purely static classes are not as often used or as well known.

Classes with dynamic components act as containing abstractions for collections of data. In this sense the non-static member functions of a class behave as if they were each passed an extra, implied pointer parameter corresponding to this (indeed, that's how they're implemented by the compiler).

class MyClass
{
public:
    int Get(/*MyClass *const this*/) const;
    void Set(/*MyClass *const this*/, const int value);
    
private:
    int mData;
};

In a similar way, classes with static components (static members functions, static data, nested class declarations or typedefs) can function as collections of types. This useful aspect of classes only really comes into its own with templates. As we've seen, we can use a static class to share a common set of types across a set of function templates:

template <class TypeContext>
class Wrapper
{
public:
    typedef typename TypeContext::ValueType Value;

    /*template <class Value>*/
    static Value Read();
    
    /*template <class Value>*/
    static void Write(const Value value);
};

Of course, the types contained in static classes can be classes, as well as functions. A static class can contain several other classes that it defines and exposes. Nesting of classes is certainly possible in C++, but isn't much used. When it is, it is often as an abstraction mechanism, with the internal classes made private and so not exposed in the public API. When not used to hide implementation, nested classes seem only to increase code complexity for not much gain. However when templates are introduced there are gains to be had, as I've hopefully described.

Classes do have an irritating limitation, however, that makes extensive use of nesting unpleasant. Unlike namespaces, class declarations can't be opened, closed and then reopened, potentially across multiple files. As a result, all the contained types must be declared within the scope of the declaration of the container class, within a single header. Nested classes don't scale as well as they could. This is only really a problem if the contained types are classes.

// reader.h
template <class TypeContext>
class IO
{
public:
    typedef typename TypeContext::ItemType ItemType;

    class Reader
    {
    public:
        static ItemType Read();
    };
};

// writer.h -- CAN'T DO THIS!
template <class TypeContext>
class IO
{
public:
    typedef typename TypeContext::ItemType ItemType;

    class Writer
    {
    public:
        static void Write(const OutputType &item);
    };
};

Earlier we hinted at a feature of C++ that almost solves this problem: namespaces. Namespaces are certainly containers for types, and from a distance look a lot like static classes: they're like classes stripped of their runtime functionality. Happily, they can be opened and closed across as many files as we like. Unfortunately, they fail our test in another respect: they can't be templated. This limits their practical usefulness as static classes.

// CAN'T DO THIS!
template <class TypeContext>
namespace IO
{
    typedef typename TypeContext::ItemType ItemType;
    static const int INVALID_VALUE = TypeContext::INVALID_VALUE;

    static ItemType Read();
    static void Write(const ItemType &item);
}

Namespaces have another significant limitation: they can't have private members. This is another way in which they aren't true static classes.

namespace IO
{
    typedef int ItemType;

    static const int INVALID_VALUE = -1;

    static ItemType Read();
    static void Write(const ItemType &item);
    
    // CAN'T DO THIS!
private:
    static ItemType ReadHelper();
    static void WriteHelper(const ItemType &item);
}

In summary, static classes are as useful as more familiar non-static classes, once templates are introduced. However a couple of limitations of C++ make them less convenient than they might be. Classes must be declared all-in-one-go, in a single header. Namespaces are like half-baked static classes that have the static aspects of classes without the runtime aspects. However in the process they've also lost several useful features of classes, limiting their use to non-templated situations.

Hyundai i20 rear light cluster.

Mine is the 1.4 liter manual petrol model, Comfort spec, with a claimed Combined Cycle figure of 50.4 MPG (5.6 l/100km, for those living in countries with proper units). In reality on first driving the car I was seeing less than 40 MPG - about 38 was typical. This was with free flowing driving in light traffic on country roads. Figures on the motorway were considerably worse, dropping to maybe 30 MPG. Something was up.

I had gathered that the economy figures claimed for cars were often optimistic. At first I put this down to outright lying on the manufacturers' part. But it all started to make more sense when I found out what exactly the Combined Cycle entails. Evo magazine recently ran a feature explaining how it works. A European standard, the Combined Cycle measures the average performance of a car on two very specific tests: the Urban Cycle and the Extra-Urban Cycle. Each cycle is so-named because it consists of a carefully prescribed series, or cycle, of gear changes, accelerations and decelerations, with periods of constant speed and even complete stops. The intention, presumably, is to simulate "typical" road behavior of a car on two classes of roads.

Some features of the Combined Cycle are surprising. Firstly, at no point on either cycle does the car exceed 50 mph (about 80 km/h). Presumably, in Europe, no one ever exceeds 50 mph. This goes some way to explaining why my own figures don't match up. Personally I exceed 50 mph on a regular basis, in fact whenever conditions allow (but never in a built-up area, of course, officer).

It's a widespread belief that cars are more fuel efficient at higher speeds. This idea comes, I think, from the well-observed fact that the figures for the Urban Cycle are always worse than for the Extra-Urban cycle. But it's a myth. Most cars are more economical at lower speeds (within reason). Certainly more efficient at 40 mph than at 60, and more at 60 than at 80. Try it: unless you have a high-performance car designed specifically for high speed driving, you're better off driving slowly, if saving fuel is your goal. So where does the misconception come from? Simple: while cars are more fuel efficient at lower speeds, they're unavoidably very inefficient in stop-start driving. Cars fare worse in the Urban cycle because it simulates town driving, with traffic lights, not because it involves slower speeds.

i20 Comfort model comes with a handy, if somewhat cheap looking, LCD display with average and instantaneous mileage.

The poor fuel economy seen at higher speeds is really pronounced in compact hatchbacks driven at speeds in excess of 70 mph. Once you pass 70 mph you enter a no mans land that the car designers likely didn't even bother to measure, for fuel economy, let alone optimize. The Combined Cycle tests low speed driving with stops and starts, so that's where the money is in the economy segment.

The strict sequence of accelerations and decelerations of the Combined Cycle represents a very specific driving experience whose results aren't very transferable to real-world motoring. It's infamous for figures that sound great on paper but are best used in comparing one car to another: they are at least standardized.

Another surprising feature of the Combined Cycle is that gear changes are scripted. While accelerating, the test technician changes from first to second, second to third, at specific speeds that are mandated as part of the test. The reason, again, is clear: if it wasn't scripted then who's to say that a low score isn't the result of the tester doing a lousy job? Scripted changes allow different cars to be compared - how meaningfully is another matter.

The gear change points in the test are designed for high fuel efficiency, and effectively represent short-shifting, the practice of changing gears early under acceleration to keep the engine revs under 2500 rpm. Short-shifting works so well that we are often advised to practice it as a fuel-saving trick.

My own experience backs this up. In driving around town in light traffic, most of the time is spent driving at moderate speeds behind other cars, coasting with the foot lightly pressed on the accelerator, just enough to match the speed of the guy in front. Choose a higher gear and less revs are needed to nudge the car forward. Result: dramatic fuel savings.

Hyundai i20

I can't help wondering whether there's a cost in terms of engine wear. Although very high revs are bad for an engine, very low revs are bad too. The engine has to push harder on each revolution, with higher strain on the components. A middle ground of, say, 3000 rpm seems likely to put the engine under less strain than spending much of ones time pushing hard at 2000 rpm.

But that aside, I can vouch for short shifting as a way to save fuel. Surprisingly it doesn't feel overly forced either. In fact it quickly starts to feel smoother than changing later. The car seems to glide along without fuss, instead of in bursts of revs punctuated by distinct gear changes.

The bottom line: if I fastidiously change gear at 2500 rpm, and quite often before, I can reliably hit 50 MPG in free-flowing traffic on suburban roads (read: stuck behind other cars). It's a good feeling. Of course, as soon as I hit the town center, or let loose on the open road, the feeling fades fast and the economy readout glares back with a sullen 30 or 40 MPG. But you can't have everything, can you. And at least it's good to understand where the figures come from.

Rancilio Silvia

If you're looking for a home espresso setup then these babies are the ones to look at first. The ubiquitous Gaggia line are okay, but if you want the de facto standard home machine, consider spending a bit more and getting the Silvia. The Silvia is more robustly built and weighs in at a healthy 14kg, much of that the solid brass used for the heat-bearing parts: boiler, group and portafilter.

There are a number of distinctions between a "home" espresso machine like the Silvia and a professional machine. Most obviously the home machine is smaller and in particular has just one group - the head of the machine where the coffee is produced.

Less obviously the home machine typically has only one boiler inside; as a cost-saving move a single boiler serves both for pouring coffee and for producing steam. The two need quite different temperatures -- one boiling, the other not -- so this concession means a mandatory wait of around a minute while the boiler heats up between pouring an espresso and steaming milk for a cappuccino.

No huge inconvenience, except that espresso becomes bitter quickly once poured and is past its best within a few minutes. Frankly you wouldn't want to leave an espresso that long if you were going to drink it neat. But by luck the foamed milk of a cappuccino or latte masks the ill-effects. At any rate there's little that can be done about it, short of splashing out several thousand pounds on an overly expensive dual-boiler machine.

Many home machines are bought on the spur of the moment, and then sit largely unused after an initial honeymoon of enthusiasm. Espresso machines are more complicated and laborious than buyers imagine. What most people want is the convenience of pressing a button and having a cup filled in front of their eyes. But the reality of espresso is that it's a technical craft with some six decades of proud Italian expertise, more similar to mixing cocktails than to pouring pints.

Group and portafilter of Silvia with recently poured double shot.

Making good espresso demands unavoidable investments in technology. Some home machines come with no internal pump, relying instead on steam pressure built up inside the boiler to force the hot water through the tighly packed coffee grinds. There are two problems with this: firstly, the pressure produced is too small (espresso requires a quite specific 9 bars of pressure). Secondly, the water is necessarily boiling, and so hot enough to burn the coffee (espresso needs about 95 degrees Centigrade).

The truth is that home machines without pumps are so useless as to be worth discounting completely. Steer clear and invest in a pump machine instead. Unfortunately the pumpless machines are the ones cheap enough to be bought on impulse -- their manufacturers are guilty of exploiting the widespread naivety about what espresso really involves.

Another piece of essential kit that's often overlooked is the grinder. Most people don't budget for a quality grinder at all, but the truth is it's worth spending half as much on the grinder as on the coffee machine itself.

Many people are familiar with the advantages of grinding beans at home instead of buying pre-ground coffee. For one thing it's a lot fresher: once ground, coffee becomes flavourless and bitter rapidly, unusable after half an hour's exposure to the air. Kept in a sealed container it lasts for longer, but the best bet is to grind it immediately before use.

Even armed with this knowledge, the true value of a grinder is still not obvious. To be useful for espresso, a grinder must be manually adjustable, capable of varying the grind size smoothly from coarse to fine. Espresso requires a very fine grind, much finer than one could get away with in a caffetiere. And crucially, the fineness of the grind must be adjusted to control the flow of coffee from the group.

To taste good, espresso should pour smoothly and slowly, a bit like honey. It should have a gloopiness about it as it falls, arcing inward from the spouts under its own surface tension. Even a small difference in the grind will easily cause it flow too quickly, becoming watery and sour, or too slowly, becoming burnt and bitter. Espresso that flows twice too fast or twice too slow will be bordering on undrinkable. To complicate things, different coffees need different grinds. It's no exaggeration to say that the correct grind is pivotal to good espresso.

Which brings us to one last difference between home machines and their commercial cousins. A whole class of home machine are pod-based, accepting small airtight tinfoil-wrapped single servings called pods instead of ground coffee. An example is the Nespresso pod system, which many different manufacturers support. Pods have the advantage of keeping individual servings fresh until the moment they're needed, although not as fresh as if it had been ground immediately from freshly roasted beans.

Many espresso purists sneer at the pod-based machines, and with some good reason. They take much of the art out of producing good espresso, with the user's involvement reduced to inserting the pod and pressing a button. But in this simplicity lies their appeal: most buyers frankly don't want to care about grind settings or pouring rates. And they're certainly happy not to splash out a couple of hundred quid on a proper grinder. So for these people, the pod systems represent good value and an espresso machine they might actually use, with consistently pleasing results.

Portafilter of a Rancilio Silva

Can a pod-based system produce a true espresso? Yes. Can it make one as good as a commercial machine, or even a quality home system like Silvia and Rocky? No. But most people won't know or care. In Britain the quality of espresso in chain cafe's is so poor that a Nespresso machine can usually beat it. More importantly it can beat it time after time, without any expert knowledge and without ever pouring a bad shot. Throw in the fact that most British coffee fans like their espresso with lashings of steamed milk, and few would miss the better flavour and aroma from a more sophisticated system.

On the subject of steamed milk, it's worth noting that many pod-based machines skimp on boiler size, because the pod system can get by with less. This means their steam pressure is sometimes poor at best, and steaming milk can be a frustrating experience with bubbles but no smooth silky microfoam. It's worth asking for a demonstration of the steaming, since that's the bit which is most likely to vary from one pod machine to the next.

The bottom line? If you're a true coffee freak, and you like nothing better than to get your geek teeth into serious fine tuning and experimentation, then get a Silvia (or, if you prefer, a Gaggia) and you won't be sorry. But if you just want a decent coffee at home with a minimum of fuss, go with a pod system. The price you'll pay is a small drop in coffee quality, sub-par steamed milk, and the opportunity to learn a bit more about the real art of espresso. But on the plus side you might actually use the machine you buy, and like the results.

I should note that in London the only place I know of where you can buy Rancilio machines is The Coffee Machine Company. Their shop, Drury, is in Covent Garden.

A double espresso shot.

The results might surprise you, depending on how familiar you are with the golden rule of espresso. The rule says a 25ml shot of espresso should take about 25 seconds to pour. The rate of pour affects the taste: too slow and it burns and becomes bitter, too fast and it comes out underextracted and sour. Good cafes (mostly, ones in Italy) use the golden rule as a yardstick to fine tune their grind.

An important subtlety is that the golden rule refers to the pouring time of two 25ml shots, not one. This is because espresso machines are purpose-built to pour two shots at once: the filter holds enough ground coffee for two shots, and the single stream of extracted espresso is split into two separate spouts. For a double, place one cup under both spouts. For a single, place it under one spout.

A double shot from the Rancilio Silvia.

For this reason espresso shot glasses, used to measure timed shots, come in a standard double size of two shots, not one. These bad boys are twice the size of the good old shot glasses we know all too well from too many nights in our misspent collective youth. The one in the picture has a handy white line marking a 50ml (2 oz) measure.

Now watch carefully as the barista pours the shot. Very often they'll use one of these double shot glasses to catch the spare second shot from the other spout; the drip tray is generally littered with them. If you're paying attention you'll see that the shot glass on the second spout is filled right up to the white line -- meaning it's caught two whole shots, just from one spout.

Basically, Caffe Nero are pouring four shots on every pour, rather than the two shots like we use throughout the civilized world.

The odds are, it's by accident: they know that a shot should get poured at each spout, but they don't realize that their shot glasses are doubles. This means their grind settings are completely wrong: coarse enough that the coffee flows twice as fast as it should. And that's bad news for that espresso we just ordered.