Planck results: Boring or Anomalous?

The Planck Collaboration released a 29-paper avalanche on the cosmology community just over a week ago, comprising their first set of CMB results (all of the papers are listed here). Along with a lot of people in the field (I imagine…), I’ve been letting the implications of this data release sink in for a few days and, on the face of it, the results are a little boring: no detection of non-Gaussianity, no extra neutrino species, “robust support for the standard, six parameter LCDM model of cosmology” — standard, standard, standard. OK, so the best-fit parameters are a bit different to the WMAP 9-year ones, but that hardly seems like front-page news. A few other anomalies were flagged up in the Planck papers too, but none of the cosmologists I’ve spoken to so far have seemed particularly excited about them. Raised eyebrows, murmurs of “that’s interesting”, but no suggestion that we’re looking at anything earth-shattering.

But hey; they’re worth a look, right? These are the “anomalies” that have piqued my interest, and why:

CMB/SZ σ₈ discrepancy: The value of σ₈ measured from the CMB is in tension with the value measured from the SZ cluster sample. The Planck Collaboration “attribute this tension to uncertainties in cluster physics”, but an interesting note by Macaulay, Wehus and Eriksen suggests that the SZ value is actually pretty consistent with a number of independent redshift space distortion (RSD) measurements from galaxy redshift surveys (see figure, right). This is interesting: If Planck are right about the reason for the CMB/SZ discrepancy, then perhaps there is a potentially important systematic bias in the RSD analyses that has been left unaccounted for. And if they’re wrong, and the value of σ₈ from multiple probes of large-scale structure is genuinely different from the CMB value, then maybe we’re looking at some interesting physics (e.g. a spatial variation in the power spectrum amplitude, or an interesting dark energy equation of state).

f * sigma_8 from Macaulay et al. The dashed line is the theory curve for the Planck CMB best-fit parameters, and is clearly discrepant with the RSD data.

Hemispherical power asymmetry: The Planck results confirm the existence of a hemispherical power asymmetry that was previously seen by WMAP. This is the result that the amplitude of the angular power spectrum appears to have a dipolar variation across the sky. A letter by Liang Dai and others considers a number of physical models for this asymmetry, including a spatial variation in the initial scalar spectral index, an isocurvature mode, and an inhomogeneous reionisation optical depth. If some of these explanations turn out to be true, we might need to seriously revise our picture of what the Universe looks like on the largest scales (which would be cool).

H₀ discrepancy: The best-fit value of the local Hubble rate found with Planck is significantly lower than the Riess et al. measurement from local distance measures. I’ve been noticing for a while that H₀ estimates from WMAP+BAO analyses were tending to come in lower than the Riess value, but the new value from Planck has smaller error bars, and so the discrepancy is more significant. Again, the simple answer is that someone has a systematic error that they need to deal with, but maybe there could be some neat physics here too. Valerio Marra and others point out that one should expect a local measurement of H₀ to differ from the background value as a result of cosmic variance, although they expect a smaller deviation than the observed one. Myself and Tim Clifton have previously suggested that you’d expect such a discrepancy if backreaction effects were important too.

Bulk flow: The official Planck analysis failed to detect a bulk flow using the KSZ effect from galaxy clusters, which is ostensibly bad news for previous claims of an anomalously large bulk flow detection with WMAP. A subsequent paper by Atrio-Barandela claims that the statistical errors have been overestimated in the Planck analysis, and that a significant detection would be found if they were corrected. A large bulk flow seems to be quite difficult to explain within the standard LambdaCDM framework, although I think this result needs more work to be convincing.

Postdoc, paper, thesis…

It’s been a busy couple of months here, hence my disappearance from blogging for a little while. But I’m back! Here’s what I’ve been up to:

• At the end of January, I accepted a postdoctoral position in Oslo with Hans Kristian Eriksen, to start in May this year. I’m currently working with Hans Kristian and others on extending the Commander CMB analysis code to localised signals (especially my old favourite, the Sunyaev-Zel’dovich effect), and will be continuing some of that work as part of an ERC project, “The anisotropic universe“. There’s a bunch of other stuff that I’ll be working on too, but I’ll save the details for another post.
• Since the postdoc starts so soon, I’ve had to write and submit my thesis in what may or may not be record time. As a result, I’ve lost all of February to filling-in forms, thesis writing/editing and all that jazz, but as of Monday, that’s all done and dusted. I’ll be spending the next couple of months finishing off a project, getting a start on a couple of new ones, and travelling a bit.
• I put out a neat little paper with Marc Kamionkowski at the start of February. During a brief visit to Johns Hopkins in October, I had a fun chat with Marc about some of the work I’ve been doing on detecting large-scale inhomogeneity with the kinematic SZ effect. In this paper, we applied some of the same ideas to the situation where a large-scale inhomogeneity could be biasing the measurement of the spatial curvature parameter, Ω_K. Even small biases in Ω_K could cause serious problems if they were left uncorrected for; a detection of non-zero spatial curvature with Planck could all but rule-out eternal inflation, for example (depending on the sign of Ω_K that was measured). We suggested a few possible methods for distinguishing between a bias caused by an inhomogeneity and a genuine departure from flatness on superhorizon scales. As it turns out, the KSZ effect measured at small angular scales by ACT and SPT already places quite tight upper limits on the possible size of a biasing effect of this type.

So things are pretty exciting right now, I’d say!

Book review: Think Like a Programmer, by V. Anton Spraul

My publisher, No Starch Press, sent me a review copy of another of their books a few months ago. Regrettably I’ve been a bit slow in getting around to properly reading it, but here, finally, is my review of Think Like a Programmer, by V. Anton Spraul.

Programming is as much an art as it is a science. When you’re starting out as a programmer, there’s a big mess of concepts and rules to get into your head before you can do anything much more complicated than printing out a shopping list on-screen – things like differences between different types of variable, and how pointers work. Even if you’re dealing with a language that hides all of these icky details, like Python, you’re still going to find yourself spending most of your time learning about specific structures like for loops or class declarations.

Most books for the newbie programmer focus on these mechanical details, generally with specific application to only one programming language. And quite rightly so, in my opinion; after all, it’s only by learning this stuff that you’re ever going to be able to do anything interesting. And so it’s only when you start programming regularly, or try to do anything more substantial, that the “artistic” side of programming starts to become really important.

With Think Like a Programmer, Spraul has his sights firmly set on the people who’ve already put the time in with the initial “science” bit. They have a decent amount of experience with one, maybe two, programming languages, and have progressed beyond textbook exercises or copy-pasting together code snippets to actually writing their own functioning code from scratch. But it’s at this point that a lot of people get stuck, with some of them never moving far beyond this predominantly mechanical understanding. Without a firm push in the right direction, habits can develop, experience reinforces them, and the art of programming never blooms.

It’s a philosophy, not a cookbook

Think Like a Programmer is a 233 page push in the right direction. It’s not a pattern book, with endless lists, block diagrams, and flowcharts for deciding when to use one tried-and-tested program structure over another. It’s not a cookbook, with myriad clever, practical examples to use as “inspiration”. Nor is it an “advanced programming” textbook, with detailed treatises on using the obscure, God-level features of whatever programming language you’re most concerned with. No. While it does have elements of all of these things here and there (they’re useful, after all), it’s much more concerned with your attitude to programming – how you approach solving problems with code. Your coding philosophy.

It would be easy to churn out a book on this subject that goes little farther than chastising you into adopting good coding style (how to indent blocks? where to add comments? how to name variables?), and pointing at a few useful patterns that relative newcomers often don’t know about. But Spraul has gone far beyond this. He starts off with a general discussion on how to solve problems, using examples of the type you might find somewhere near the back of a newspaper. The puzzles he walked through were really fun, and it felt good to go from blindly fiddling around with them to successfully applying the strategies he suggested. The lesson he’s teaching here is to sit down, think about the problem, and start using powerful general-purpose approaches like reducing it into smaller sub-problems, being systematic, and so forth. And, hey, whaddaya know? It works. Thinking works!

It’s a journey, not a destination

Things progress from there into the programming domain. In each successive chapter, Spraul builds on the discussion that has gone before, introducing new, generic, problem-solving approaches and combining them with the methods discussed previously to solve progressively harder example problems. The examples are followed through in excellent explanatory detail, with an emphasis on the structure and logic behind the code rather than the particular language features that are used (though all the examples are in C++, which has its fair share of relatively opaque syntax). He also strongly encourages that you try the numerous exercises at the end of each chapter to cement what you’ve learned, an approach that, while it may sound dry and textbooky, really does help you to get to grips with things.

There are chapters on general programming/problem-solving approaches, plus more specialised ones on using important tools like arrays, classes, pointers, and recursion to your advantage (the recursion one is available to download for free). The discussion is kept general – there’s little in here about specific optimisation or debugging tricks, and rather more of an emphasis on just writing good code, regardless of the specific application you might have in mind. As such, if all you’re after is quick tips for making your code run better, you’re not going to get that much out of the book. If you’re willing to sit down and patiently follow it through, however, you’ll find that what it’s teaching you is an enlightened approach to programming – essentially, how to become a Good programmer with a capital-G. And in the long run, that’s what’s going to make the difference between scraping by, writing cobbled-together solutions that just about work, and outputting truly nice, effective ones.

That troublesome audience

This is all well and good – noble, even – but I can’t help but wonder if the book will get through to its intended audience. If a novice programmer picks this up, there’s a good chance that they’ll struggle with the choice of language. While it’s a sensible pick for showing off the concepts the author is interested in, C++ isn’t the easiest language in the world, and Spraul isn’t afraid of using some of its more obscure syntax with only the briefest of explanations. For someone with experience only of Python, for example, the one-page overview of how pointers work in C++ isn’t going to leave them much wiser on the subject. There’s absolutely nothing to help the non-C++-using reader get set up with compilers and IDEs either, which could cause some serious headaches for those actually wanting to play with the examples themselves. As a result, those familiar with C++ will find the book a considerably easier ride than those who are not, which is a shame.

The purpose of the book is also a bit more subtle than your average (the blurb describes it as a “one-of-a-kind text”). You know what you’re getting with a cookbook, whereas the benefits brought by Think Like a Programmer are somewhat less tangible. The readers who’ll get the most out of this are the patient, motivated learners, whereas those who’re looking for shortcuts and quick fixes to “becoming a better programmer” will likely find it frustrating. Ultimately, I guess that’s fine – you can only help those who will be helped – but I guess this sort of presentation would be more effective to a broader range of people  in the context of a taught course rather than self-study.

Verdict

The book is well-written, with tons of excellent advice and solid, well-thought-out examples. If you’re willing to devote some time to studying the material (perhaps, depending on your background, with a C++ reference in hand), you’ll soon find yourself equipped with an impressive array of problem-solving strategies and, maybe, a new outlook on programming. Recommended.

Calling the WMAP likelihood code from C/C++

If you’re interested in cosmological parameters, chances are you’ll want to include WMAP CMB constraints in your parameter estimation code at some point. Happily, the WMAP team have made their likelihood code publicly-available, so it’s relatively simple to add them into your own MCMC software (or whatever else you’re using). Less happily, the likelihood code is written in Fortran 90, so users of more modern languages will need to do a bit of fiddling to get it to play ball with their code.

Joe Zuntz was kind enough to share a little C wrapper that he wrote for the WMAP likelihood code. It’s pretty easy to follow, although you should of course read the documentation for the likelihood code to see how to use it properly. First of all, compile the original Fortran WMAP likelihood code. Then, compile this wrapper function as a static library (libwmapwrapper) as follows:

gfortran -O2 -c WMAP_likelihood_wrapper.F90
ar rc libwmapwrapper.a WMAP_likelihood_wrapper.o

You can call the wrapper function from your C code by linking to that library. Joe has written a test implementation that shows how it works. To compile this, you’ll need to make sure you’re linking against everything the WMAP code needs, including a BLAS/LAPACK library; the following should work on Mac OS X (using veclib):

gcc wmap_test.c -std=c99 -L. -lwmap -lwmapwrapper -lcfitsio -framework veclib -lgfortran -o test_wmap

(N.B. Joe’s code is written for the WMAP 7-year release, so you may need to change a couple of numbers to get it working with the 9-year release.)

Customising contour plots in matplotlib

So, you need to include a contour plot in some publication of yours, little one? There are two things that you must learn. But beware! The first will raise your spirits, while the second will quicken your descent into madness. These facts I address to you, should you stand to read them: (1) matplotlib has a really customisable contour plot implementation; (2) the convenience functions are few, and the necessary keyword arguments are confusing.

I’m prepping a bunch of contour plots for a publication in a quick letter at the moment, and want to improve their legibility. This involves things like making all of the lines thicker, increasing the font size of the labels (both on the axes and on the contours themselves), and changing the contour scaling. Some of these modifications have proven more difficult than others with matplotlib, so I thought I’d jot down a couple of examples here for reference. (The matplotlib contour examples are useful, but don’t cover everything.)

Tick size

First of all, let’s change the width and length of the ticks on each axis, and the size of the font of the labels for each tick.

import pylab as P

MP_LINEWIDTH = 2.4
MP_TICKSIZE = 10.

P.rc('axes', linewidth=MP_LINEWIDTH)

P.subplot(111)
for tick in P.gca().xaxis.get_major_ticks():
  tick.label1.set_fontsize(20.)
  tick.tick1line.set_markeredgewidth(MP_LINEWIDTH)
  tick.tick2line.set_markeredgewidth(MP_LINEWIDTH)
  tick.tick1line.set_markersize(0.5*MP_TICKSIZE)
  tick.tick2line.set_markersize(0.5*MP_TICKSIZE)

The call to P.rc() changes the thickness of all of the axis lines on the plot (i.e. it changes the global properties, and isn’t restricted to just one plot). The other stuff could probably be done using calls to rc(), but that’s an exercise for another time.

An example of a customised contour plot in matplotlib.

The loop is over all major ticks on the x axis of the current subplot. (The call to gca() gets the current set of plot axes, but of course you could use the xaxis.get_minor_ticks() method from any previously-defined axes object.) The object tick1line is the x-axis at the bottom of the plot, and tick2line is at the top.

Inside the loop, I’m setting the font size of the tick label (the number that appears below each tick), the width of the tick (using the markeredgewidth property), and the length of the tick (using markersize). You can also do things like hiding certain ticks, hiding certain labels (especially useful if you want to remove the tick label at the origin, because it overlaps with the label for the other axis there), changing the appearance of gridlines (somewhat unintuitively), and so on. There’s a list of all the tick-related objects that you can change here.

This will only change the tick styles for the minor ticks on the x axis. To cover all of the ticks on the plot, you’ll need to loop through all the minor ticks using P.gca().xaxis.get_minor_ticks() too, and then do both major and minor ticks for the y axis (using P.gca().yaxis) as well.

Changing which values contours are drawn at, and how they are labeled

To change where the contours are drawn, you need to change the contour locator. This is a keyword argument to contour(), and requires a ticker object. There’s a list of built-in tickers here. In the example below, I wanted a log scaling for my plots, so I used LogLocator().

It’s also useful to be able to change the labels that are added to the contours.For this, you need to use the clabel() function (which controls contour labels) and manipulate the formatter, using the fmt keyword. A list of formatters is given here, with more documentation on them (including formatter-specific keyword arguments for further customisation) given further down that page. Particularly useful formatters include:

• LogFormatterMathtext (which add LaTeX mathmode labels, especially useful for numbers with exponents)
• FormatStrFormatter (which lets you use a C-like format string to determine how significant figures, signs, etc. are displayed)
• FuncFormatter (which lets you define a custom function to handle string formatting)

Setting the font size of the contour label is as easy as changing the fontsize keyword of clabel().

Finally, a subtlety of contour() is its use of the linewidths keyword, rather than linewidth (as with other pylab functions). It works exactly the same otherwise.

from matplotlib import ticker
ctr = P.contour(X, Y, Z, locator=ticker.LogLocator(), colors='k', linewidths=3.0)
P.clabel(ctr, inline=1, fontsize=20., fmt=ticker.LogFormatterMathtext())

Update: Floating-point exception handling on Mac OS X

A few months ago, I was having a few problems porting some C++ code over to Mac OS X because of some non-standard floating-point exception handling functions that are present in glibc on Linux. Well, it just so happened that a colleague of mine, Rich Booth, recently ran into the same problem, only from a different angle. He wanted to keep track of floating point exceptions in a simulation code of his, but found that he couldn’t do this on his Mac.

After a bit of digging around, we found a portable implementation of floating point exception handling that would happily run on both Linux and Mac OS X. It was written by David N. Williams in 2009, and includes some good documentation on the implementation in the comments. There’s also an example program right at the end of the file, so you can test it out right away.

The code should be simple enough to figure out pretty quickly, but Rich split out a header file anyway, just to make everyone’s lives that bit easier. You can find a tarball with Rich’s modifications here.

Patrick Moore

Sir Patrick Moore passed away today, aged 89. Through his many, many books, and TV programmes like The Sky at Night, he became Britain’s foremost populariser of astronomy. It’s safe to say he’s inspired several generations of scientists, showing us the poignant beauty of the heavens and incredible excitement of space exploration, all in his own, unique way.

I have a particularly fond memory of him. When I was quite young, probably around 8 years old, my dad and uncle took me to see Patrick give a lecture at the Victoria Hall in Stoke. I seem to remember that much of it was about Mars, and how astronomers past had mistakenly seen canals and other marks of civilisation on its surface. I still have a copy of a little red book of his, “Into Space!”, lying around somewhere at home, that we bought on the night. We also took my copy of Philip’s Atlas of the Universe (another of his), which he graciously signed for me after the lecture. I can’t remember what he said to me, other than that he’d sprained his wrist, so could only manage to scrawl his initials on the first page! I recall being slightly put out by this, for some reason – perhaps because it looked like someone had randomly scrawled on the book, thus defacing it. (Anyone who knows me will have some appreciation of how cardinal a sin the defacement of a book, however slight, is in my eyes.)

Meeting Patrick was one of a number of important events in my development that happened at around the same time. My dad bought me a little black Tasco refractor, and managed to get a stunning view of Jupiter out of it, one that I couldn’t reproduce myself for many years. A couple of years earlier, he’d woken me up in the middle of the night, literally carrying me out of bed to see a lunar eclipse. My parents had also been indulging me by buying science books, which I absolutely lapped up. One of these was Patrick’s Atlas of the Universe, the one he signed, which I often dipped into. In 1999, there was also a solar eclipse in Britain, only partial in Stoke but reaching totality in Cornwall, which I remember Patrick doing the commentary for.

These events, along with many others of a similar nature over the years, have shaped me both intellectually and personally. Being an astrophysicist is a big part of who I am, and I’m forever grateful to all of the people like Patrick who set me out on this path all those years ago. I only hope I can repay the debt by inspiring others myself.