Posted by Andy Buckley on Jun 06, 2014
Time for another lazy excerpt from private correspondence! This time we visit that most viscerally thrilling and scientifically crucial of subjects: what tense(s) to use in your scientific paper. Daring, I know! But surprisingly controversial, and I’m motivated to write it after reading and reviewing umpteen notes, drafts, and published papers in which the tenses seem (to me) perverse. In particular I think there’s a need to write such a thing after being told by one physicist “I think there’s a convention in science writing that we always use present tense”. Piffle!
I think this sort of view, which is not uncommon, is an interesting phenomenon – junior physicists read badly written documents, then after initial recoil they rationalise the bad style as “how it’s done in science”. Later then internalize and view the weirdness to some degree as a badge of honour; and finally they become irrational defenders of the spontaneously arisen faith. The same sort of thing can happen for oddball journal style rules like using “Section” if the first word in a sentence but “Sect.” otherwise – such rules are different for each journal, of course, and if you ask me it’s the journal staff’s responsibility to enact their own crazy rules if they think that’s a good way to justify their continued existence. Bah, humbug.
Posted by Andy Buckley on May 17, 2014
If you attend a particle physics meeting these days (and most of us do, several times a day… this is not a good thing) it looks rather different to how it did 10+ years ago. Not that everyone paid attention then, but the type of laptop everyone’s focusing on rather than the speaker has shifted, from the olden times array of various clunky black boxes to the situation now where 2/3 of the room seem to be wielding shiny silver Macbooks.
It seems like a no-brainer: Windows is pretty much 100% dysfunctional for computing-heavy science (unless you are either in a fully management role and never touch data, or for some reason love doing all your work though a virtual machine), but Linux is unfamiliar territory for most starting PhD students. Sure, it’s a lot more user friendly than it used to be, with more helpful GUI ways to manage the system and the wifi even works out of the box most of the time. But Macs are perfect: beautifully designed, friendly, but with Unix underneath … and they only cost an extra 50%! Ideal for HEP users who need Unix computing but want it to just work out of the box… and who doesn’t? As the Apple advertising used to say “It just works”.
Or does it? From my perspective as an author and contact point for an awful lot of particle physics software packages, I can put my hand on my heart and swear that about 90% of user problems are from people with Macs. And even if we adjust for the base rate effect that there are an awful lot of Macs out there, it’s still the case that a majority of issues relate to the fact that it’s a Mac that they are using. This trend toward everyone having a Mac naturally brings an assumption that, just like the mail client and web browser and office suite, HEP software should “just work” on these machines like it does on the offically supported Linux platforms. But that’s often not true, for various reasons, and the demand that everything also work on a rather dysfunctional platform which is not part of the LHC’s data processing plan puts rather a heavy load on us developers and maintainers. If you want to be able to run HEP code on your Mac, rather than just use it to log into Linux servers, then Macs are not the “it just works” path of least resistance that you might expect.
Posted by Andy Buckley on May 12, 2014
A while ago I was included in a discussion between an ATLAS experimentalist who had been told that some “unfolding” was needed in their analysis, and a theorist who had previously been a strong advocate of avoiding dangerous “unfoldings” of data. So it seemed that there was a conflict between the experimentalist position of what would be a good data processing and the view from the theory/MC generator community (or at least the portion of it who care about getting the details correct). In fact the real issue was just one of nomenclature: the u-word having been used to represent both a good and a bad thing. So here are my two cents on this issue, since they seemed to help in that case.
Posted by Andy Buckley on Feb 28, 2014
I was just recently notified that the world top mass combination uses “my” MCnet review paper on MC generators to justify stating that the definition of the top quark mass used in all (!) event generators is equivalent to the “pole” mass.
I’ve heard that statement very often, but not backed up by anything more concrete, so I was interested to read this section of the paper (Appendix C, starting on p184 of the PDF), which turns out to be rather good, interesting, and elegantly presented. Not to mention slightly embarrassing that I hadn’t read it before, given that it has my name on the front! (In my defence, I did write some of this paper, just not that bit. I suspect most of the authors haven’t read everything in it.)
Anyway, it definitely does not say that MC mass equals pole mass, so I thought it might be interesting to post my explanation of what it does say, at least as far as a dumb fence-sitting experimentalist/MC guy like myself can understand…
Posted by Andy Buckley on Apr 14, 2013
Well well well, another blog post, eh? So soon: it’s only been… erm, two years. Oh. Well I never promised to be prolific. This one’s come about because I grumbled briefly on Twitter about the nature of (British) pop-science TV and immediately hit the restrictions of that medium. Twitter is a wonderful way to share neat things that you find online, and to make pithy soundbites & jokes (and for describing what you’re eating, the form of public transport that you happen to be on, listing film names with comic vegetable name substitutions…), but for exploring a non-trivial issue 140 characters is, to put it mildly, a limitation. I have difficulty fitting one of my normal sentences into 140 characters. So of course I came across as a whining idiot, prompting the reply “Yeah, we really should do more about how shit it all is. You don’t see that tone ANYWHERE” from Dara O’Briain. Well, not remotely what I meant, but who can blame him? So here’s an attempt at a more coherent and nuanced version that hopefully doesn’t make me come across as an anti-science, axe-grinding git. But perhaps as a slightly grumpy science nerd, which is fair enough.
Posted by Andy Buckley on Feb 13, 2011
Having recently concluded a long-ongoing saga to get the first ATLAS underlying
event study both through the experiment’s internal review procedures and then
into the perverse format demanded by the academic journal, Physics Review D, to
which we submitted it, it seems an apt time to offer a few comments on the
state of the sacred academic publishing and peer review process.
Posted by Andy Buckley on Dec 27, 2010
I’ve had my attention drawn to this reply to a ROOT bug report, which I think highlights a serious problem with how the ROOT project interacts with the LHC experiments. In short, someone contacted the ROOTtalk mailing list to inform them that ROOT’s calculation of weighted means is incorrect if there are negative weights involved. There is a well-defined procedure for calculating weighted means, and in fact it’s dead simple. There’s no reason to not get it right. This is a bug report, about a significant numerical error in just about the simplest statistical quantity that anyone might want to calculate: any statistical analysis tool worth bothering with would provide a bug fix as fast as possible. So how did ROOT respond?
Well, the response from René Brun, the ROOT project leader, is that ROOT have “no plans to change this algorithm”. This is absurd: the LHC experiments depend on ROOT to provide them with accurate statistical results. Errors in ROOT mean mistakes in the LHC physics programme: this is not a feature request that can be turned down because it doesn’t fit with ROOT’s plans, it’s a bug which needs to be fixed. That ROOT’s management appears to see no reason to get simple calculations correct, and that errors this simple still exist after nearly 20 years of development, is an indictment of ROOT’s relationship with the LHC programme… and of how CERN and the experiments have dropped the ball in making ROOT a useful tool targetted to LHC physics. I’ve often heard comments that ROOT is all about empire-building and CERN politics rather than about good science – I’d rather not believe that, but examples such as this make it hard to draw a more appealing conclusion. The nicest thing I can say is that René apparently hasn’t understood that this is a bug. If I were feeling more conspiracy-minded I’d interpret it as saying that he doesn’t care if ROOT is right, as long as it’s used. And it is certainly used – ROOT has a virtual monopoly over LHC physics data analysis, without delivering the sort of quality that such a position demands.
Posted by Andy Buckley on Dec 24, 2010
I’ve never been the most active blogger, but 2 years between posts seems a little excessive, even to me! I wish I could explain the cornucopia of reasons for this, but I’ll just point a couple of accusatory fingers at the extraordinary busyness of life (in the intervening time I moved to Edinburgh, the LHC restarted, and my working life has generally been batshit insane) and general frustration at my server setup. You may also be frustrated with the slowness of this server: turns out that running a mail server and a Rails application on a 256 MB virtual server puts me deep into the swap memory zone and site performance accordingly drops into the region marked “painful”. I’d have loved to fix this 2 years ago, but a) I’ve written enough web apps in the past to not want to make another half-assed one, and b) did I mention work being batshit insane? Anyhoo, someone asked me at a recent meeting when I was going to start blogging again, and after the initial shock of discovering that I have some sort of niche audience I decided that I should start venting my spleen in more substantial ways than the 140 chars offered by Twitter.
A bit of recent server upgrading means that this site is not quite as slow as it has been – I’m enormously impressed by the service from Slicehost, by the way – and I’m going to try and replace Radiant with something a little more fun, speedy, and memory-efficient in this little pre-2011 gap. Suggestions of CMSes/blog engines with user comments, picture galleries, code highlighting support, etc. and support for static content (such as this site’s Cambridge night climbing content) would be much appreciated. Oh, and because I’m a picky person and have not found Ruby/Rails to be a terribly pleasant development experience, being based on Python would also be a big bonus!
Posted by Andy Buckley on Jan 21, 2009
Here’s a handy tip for all the people I see giving talks made with the super-genius LaTeX Beamer package, all of whose slides have a row of never-used navigation widgets (back, forward, start, end, next frame…) getting in the way of the slide content. It’s dead easy to remove them, and then (if you’re like me) you can finally sleep at night. Just put this in your Beamer document preamble:
Voila — no more silly nav crap! You will now be the envy of obsessive-compulsive, LaTeX fiend scientists everywhere you go!
Posted by Andy Buckley on Nov 22, 2008
It’s the end of another busy week. Work life has been busy to the point of insanity recently, burrowing its way into every available bit of spare time… if you consider every weekend since mid October to be spare time rather than “essential time”, that is. I’m actually inclined to the latter view: while happy to declare that my work is captivating and inspiring, some downtime is definitely needed. In the last month I’ve been to two week-long conferences in Italy, snatched a week back in Durham and then spent the last week in Chicago. After one more week in Durham, in which to pay some attention to demonstrating and marking Frank’s excellent new computational physics course, I’m off on my travels again, this time to CERN for a week. And then it’s Christmas and skiing; January is looking a bit crazy, and I’m trying not to think about that. Fortunately Jo has been a star and given me some (unearned) slack, but this schedule isn’t really fair on either of us: I think I’ll be imposing a more restricted travel schedule in the New Year and hopefully sending some collaborators out to do the salesman thing instead ;)
Anyway, reflections on the past week: I have to say, I’ve really enjoyed Fermilab. Most people seem to bitch about the “boring site”, the strip malls of West Chicago, the weather and anything else that springs to mind, but I must be a bit funny in the head because I like it all. Okay, not the strip malls — a bit of restriction on the suburban planning process would have been welcome — but here’s a list of hat I’ve been up to, other than giving talks and coding up experimental analyses in Rivet:
Posted by Andy Buckley on Nov 17, 2008
“Ah, the famous Andy Buckley. Or perhaps infamous, no?”. When a dapper French gent at a statistics conference addresses you this way, I guess it’s normal to feel a bit perturbed, particularly when you’ve devoted a serious chunk of time in the last few years to publicly demonizing their work. Really, I suppose it’s maybe a minor miracle that Rene Brun and I haven’t crossed paths before now — although I guess this is largely to do with me being keen to avoid a fight.
Posted by Administrator on Nov 10, 2008
XML is a useful technology, sometimes: that’s about as positive as I can be about it these days. While there was a period when I got quite excited about the idea of a standard syntax for, well, everything, time tempers such enthusiasm. See, 90% of the time, XML is just too damn cumbersome. When what you want to say is
Param1 = 3
or something of that complexity, then having to write
<param name="Param1" value="3"/>
is just a bit hefty. Anyone who’s ever tried using Ant or Maven will surely sympathise with the idea that XML is a pain in the arse way to write make-files. And XSL transforms? Phew, glad I’m not going back into that arse-end of software engineering gone mad. It’s also a pain in the arse to read XMLified data in C++ or Fortran. Hell, even Python and Java make you jump through SAX or DOM-shaped hoops in their lowest common denominator implementations! Frankly, XML is a serious candidate for “no silver bullet”-type debunking: merely wrapping everything in angle brackets actually solves nothing, even if it looks totally SOAP-AJAX-Web 2.0, dude. Much of the time, something simpler is quite enough.
Posted by Andy Buckley on Nov 09, 2008
I’ve recently finished reading Richard Dawkins’ The God Delusion. I was pretty determined to not read it when it first came out since a) I object to specifically indulging in writing that I know I’ll agree with — I suspect that searching out compliant opinions leads to foam-mouthed Daily Mail reader behaviour and obstinate old man disease, and b) Herr Dawkins has been on a bit of an ego/PR trip in recent years, in an area which he’s not really all that qualified to talk about. But then, as he points out in the book, it’s not like religious “authorities” are really qualified to say anything meaningful about well… anything, so when Jo got a copy, I decided to steal it and finish it before her ;)
Posted by Andy Buckley on Sep 26, 2008
I always have trouble submitting papers to the arXiv, on account of my tendancy to use a whole bunch of style files etc. that aren’t in the standard arXiv collection. They aren’t usually in my document source directory, either, but are spread around my system in various
texmf trees. Accordingly, getting papers to upload is a pain (and if you try to upload just a PDF, arXiv detects that the PDF was made with TeX and refuses to accept it! Dang, foiled!)
So here’s the method that seems to work for me.
- Get the
snapshot package, and use it in your document with the usual
latex etc. on your document until it’s happy (note, I use
pdflatex pretty much exclusively these days, but arXiv will use good o’ DVI-producing
latex, so that’s what you need to use when producing your submission)
- If your document was called
mydoc.tex, you will now have a dependencies file,
mydoc.dep. This can be used to bundle your source files for submission. To do this, get
- Run bundledoc on the deps file — you may need to provide an explicit config file. Here’s my command:
bundledoc --config=$HOME/local/texmf/tex/latex/bundledoc/tetex.cfg mydoc.dep
- You now have a tarball or zip archive, depending on whether you used the TeTeX/TeX Live or MikTeX config file. This should be okay for uploading to arXiv. Happy bundling.
Posted by Andy Buckley on Sep 23, 2008
Amazingly, the article on Python indentation I bashed out a year ago at the Manchester parallel programming workshop has become the most popular thing on this website. Even more than all the lovely night climbing stuff: it seems the ‘net is an even stranger place than I thought! It’s also been nice to have the occasional bit of fan mail about the article (and a “you’re wrong” mail, which is fine, except that it really missed the point and got into a fight with the tabs-vs-spaces straw man).
Anyway, I was thinking about finally putting my head above the parapet and trying to suggest an explicit block ending scheme to the Python dev list, when I found this mail thread, the first of which which goes through all the same experiences and reaches exactly the same conclusions as I did some 13 years later. Blimey — what a way to be behind the times! George Reynolds seems a fully sane individual in my view, of course, and even manages to mention the problem of using Python where indentation is inconvenient/impossible, or even where the program must be expressed on a single line: I have been considering adding this to my own article, if I could manage to do so without cluttering, but I’ll now leave George as the definitive authority.
The pragmatic reason for this post (there is one, really) is that Guido van Rossum himself chips into the debate, and even provides the “pindent” script for converting (legally-indented) Python programs to an explicit block scheme and back. A shame that the suggestion that such a thing be included in the Python interpreter never came to anything… if it hadn’t been for the ugly “comment end block”, this could have changed the face of Python some 10+ years ago. Now, however, I think we’re probably stuck with what we’ve got. Let’s see if I can get up the courage to bring this issue up for Python 3000!