We have a very nice series of informal computing centric talks/seminars at the University Observatory Munich, labelled “Code Coffee”. I enjoy these a lot, although I prefer tea. Even for topics on which I already know a lot, I usually learn something new and interesting. The most recent installment …
Shortly before Christmas a paper by Nathalia Cibirka and colleagues appeared as arXiv:1612.06871 in which she studies the concentration of galaxy clusters using weak lensing. This topic is very close to my research interests and I immediately skimmed through the paper. The primary question in my mind was …
This blog post is triggered by a colleague stopping me in the hall and asking “What does ~ do in Python?” She was surprised by the behavior of the ~ operator when applied to Python bool types and I was surprised that it behaved differently on numpy bools than on Python bools …
The Affine-Invariant Ensemble Sampler (AIES) is a Monte-Carlo method particularly popular in astrophysics. The paper describing its widely used Python implementation emcee is highly cited and the method is particularly popular because it has — aside from the number of walkers, i.e., the number of chains — no tunable parameters.
Huijser …
I recently had a bug in my code that obviously was caused by an issue with floating point precision but had me scratching my head how it came about. Here it is:
import numpy as np
from astropy.table import Table
from astropy import cosmology
cosmo = cosmology.WMAP9 …
While working through the close to 250 applications for PhD positions at the International Max Planck Research School (IMPRS) for Astrophysics1 for the current round of applications, I noticed an odd pattern: Reference letter writers who saw a candidates strengths more in theory than in experiment seemed to rank these students higher compared to those whose strengths are more in experiment.
I have many reasons to like Python: rapid prototyping, powerful libraries, great interactive tools like the IPython shell and notebook, and the ability to write beautiful code. I will admit, the last one definitely is in the eye of the beholder. Brandon Rhodes gave a good talk at PyCon Canada a couple of year ago in which he explained what makes Python beautiful to him. One of the points he made, and one that I wholeheartedly agree with, is that you can make Python code look just like the math you are coding up. We know how to write math; we know how to typeset equations so they look beautiful and are easy to read, and thus easier to understand. We can use that knowledge to write more readable Python code.
But I’m not a mathematician, I’m an astrophysicist. Can I take this further and make my code look like physics, not like math?
In my work as an astrophysicist I have encountered quite a bit of confusion on how to quantify the level of disagreement between two or more measurements with error bars, or even more complex multi-dimensional confidence volumes. This is even more true this term when I am teaching an undergraduate lab course. Thinking a little about this myself, I realized that this is not something I have ever seen written up. At least not in any concise form. So I decided to create this little document, not only to educate others, but also to organize my own thoughts. I put an emphasis on developing the concepts and I make no attempt at rigour.
Suppose we have three measurements of the gravitational acceleration on the Earth’s surface, all with their own error bars (or measurement uncertainties, if you prefer). These are shown in the plot below and the error bars indicate their $1\sigma$ standard deviation.
I learned about IPython Notebooks from the fantastic blog of jakevdp. Realizing what a great way they are to interactivly manipulate Python code and transform the results into web pages, I started playing around with them and the pelican site generator myself. I had a few science questions on my mind for which I thought writing things up with some nice graphical illustrations would clarify things for myself and maybe others. Then I arrived at a point where I had long input boxes in my web pages with Python code that was not very interesting. I just wanted to have some figures for illustration. Of course I could just generate some plots, save them and load them into the Notebook to display them. But that seemed like an unnecessary detour if I already created the plots in the notebook. Could I not just hide the input cells? It turns out the answer was apparently “no”.
So I interrupted the process of writing about the original problems that were on my mind and set out to modify the liquid_tags pelican plugin that generates these pages so that the input code cells can be hidden.