Archive for January, 2009

My Python Dream About Groups


As I drifted off to sleep my mind felt as if floating free amongst mist; the mists cleared and the following code was revealed:

def g(l, n):
    return zip(*[iter(l)]*n)

(in my dream of course, l and n were free also. I bound them with a def for this article)

Python being such a naturally clear language, it’s obvious what this code does, right?

>>> g(range(10), 3)
[(0, 1, 2), (3, 4, 5), (6, 7, 8)]
>>> g('hello world!', 2)
[('h', 'e'), ('l', 'l'), ('o', ' '), ('w', 'o'), ('r', 'l'), ('d', '!')]

Yeah, course. g groups a list l into a list of n-tuples, by taking each group of n elements from the list and making them into a tuple. How useful.

What good is it? Well, this sort of thing crops up all the time. Decoding hex dumps for example:

# g decomposes hex string into hex-pairs:
>>> g('1c47ff47', 2)
[('1', 'c'), ('4', '7'), ('f', 'f'), ('4', '7')]
# then we can use int to decode to decimal
>>> map(lambda x:int(''.join(x), 16), g('1c47ff47', 2))
[28, 71, 255, 71]

Sorry the previous example is a bit clumsy, a Python sequence of characters isn’t quite the same as a string. Sadly.

Now the implementation of g is a bit subtle, and relies on some features of Python that might appear a bit unsound. But I’m sure I heard Raymond Hettinger say that if i is some iterable then zip(i, i, i) turns out to make 3-tuples of successive elements of i. This used to be so by accident of implementation (basically zip just happened to construct its tuples by taking one element from each argument in turn); but now they had decided that the idiom was so useful that zip is now defined to behave like that. In other words zip isn’t allowed to make internal copies of its arguments, or peek ahead in any of its iterable arguments.

zip(*[iter(l)]*n) is the same thing, but for variable n. Of note is that [i]*n makes a list of length n all of whose element entries refer to the same i (this was the cause of a bug of mine last year when I wrote [[]]*16). That iterable i is then passed n times (as n arguments) to the zip function. Neat.

It still scares me a bit.

This code is obviously ridiculous. I can’t help feeling I’ve missed a more Pythonic way of doing it.

My Water Bill


Just got a water bill for our new home. We’ve been here 2 months. Yorkshire Water have estimated our water usage at 0 units. Twats.

I have just read the meter and we have used 6 units. That’s 6 m3 in 60 (ish) days. Or about 100 litres a day. Two of us live here, so that’s 50 litres each per day. Yay for us (the UK average is about 150 litres per person per day).

Our new house has an annoying on-demand boiler which means we often run cold water straight down the drain when doing the washing up; our old house stored hot water in a cylinder. The only time I bothered to do the calculation at our old house I came up with 90 litres (between us, so 45 each) per day. The waste of water annoys me, but from the numbers it’s clearly not a huge waste of water. So that’s good. And I’m sure we burn less gas with the on-demand boiler.

The number of units of water used is so small that to do it properly I should use a year’s worth of bills. That would also eliminate the seasonal variation. I’m pretty sure we use more water in summer: We don’t water the garden (we don’t have one, but we didn’t when we did have one anyway), but we do water the tomatoes, chilis, and courgettes, or whatever we’re growing (still, this probably only amounts to a few litres per day). We also wash the car, not often, but I’m sure we wash it more in summer than winter, just because it’s warmer and nicer to be outside washing the car. We have just replaced our car with something a lot newer (with emissions of 119 g/Km CO2, yay!), so perhaps we’ll be washing the car more often. Perhaps we drink more in the summer too.

When we moved in I had to find out where our water meter was. There are 4 water meters outside on the street in a cluster, but Yorkshire Water helpfully told us which one it was (they had a note on file, saving me from struggling to read the serial number). To check, I got my partner to turn on the tap whilst I watched the meter. The meter actually measures down to the litre (in red digits that don’t go on the bill), and has another spinny thing that probably does 10 revs per liter, so this is a totally feasible exercise. I recommend that everyone try this, watching that meter spin round furiously just from turning on the tap was quite frightening.

I note that my bill is in m3 but all the discussion about water consumption is in litres (average consumption is 150 litres, bath and kettle sizes are quoted in litres). This is okay, everyone knows that there are 1000 litres in a m3, right? Apparently not. I asked two people I know that I consider intelligent and fairly numerate, as well as occasionally taking an interest in these things; they both have degrees, and not in underwater needlework. Neither of them knew the answer straight away to how many litres were in a m3. Both, when prodded, remembered that a litre is equivalent to a cube 10cm x 10cm x 10cm; one immediately realised that this meant there must be 1000 litres per m3, the other had to be prodded again. I conclude that the quality of maths teaching in this country is appalling.

I also conclude that it would be more helpful to have water bills that say 1000 litres instead of m3. Because then it would be easier for consumers to relate their bill to their baths. Should we use kl? Dunno, always makes me laugh a bit, for some reason.