Astronomers rely on statistical analysis all the time. The Python programming language has some excellent add-on packages for statistics. But sometimes the documentation isn’t as helpful in “real-world” scenarios. Prasanth Nair has posted a very nice tutorial on Simple Statistics with Python over at his blog. I highly recommend it for new users of python and anyone learning how to use statistics in their astronomical research. While you are there, poke around a bit as Prasanth’s blog has several other useful astro-python related tutorials including some on ephemeris and angle calculations.

Simple Statistics with Python | Comfort at 1 AU Blog

You can hardly be an astronomer today without knowing how to write code. As with programmers in all disciplines, we are at the mercy of the language we code with. Computer science is still a rapidly evolving field and new programming languages come along, existing programming languages get updated, and your favorite packages/routines might get deprecated or de-supported all together. Whether you stick to your old favorites or jump-ship to the latest and greatest seems to be a matter of personal taste.

The python programming language is still fairly new to astronomers; but it has many advantages over C/Fortran/IDL (and some disadvantages, see here for our wiki page on Python v. IDL). In many scientific research fields, python has been adopted very rapidly. However, the python programming language has undergone a major overhaul going from 2.* versions to 3.* versions. The most common scientific python packages still use 2.* versions; but, rumblings have begun to migrate them to 3.* versions in the near future. I expect it will still be a a year or two before 3.* support in numpy, scipy, and matplotlib python packages are fully supported and de-bugged and I would imaging that 2.* support will continue for the next 5-10 years at least. But I still use codes written over 20 years ago, so long-range planning isn’t completely crazy.

For your early adopters out there, here is a useful quick-switch guide for python 2 to python 3 conversions. I should note that python 2.6 and 2.7 have transitional support for features found in python 3.*; but there are still some differences. Since python 2.7 comes installed with OS X Lion, if you get a new machine or upgrade, then consider tinkering with the new python features. And take a look at which of your coding habits will break things in the future. For instance:

print 'I found %10d bugs' % bugCnt

doesn’t work in python 3 and instead should be replaced with

print('I found {:10d} bugs'.format(bugCnt))

Here are a couple of other relevant links.

• Python 2 or Python 3?
• Automated Python 2 to 3 code translation
• Porting Python 2 Code to Python 3

With the migration of the Rumor Mill to the AstroBetter wiki, a new feature was added, comments. Some of the comments have been useful questions, updates, and clarifications about jobs and fellowships while other threads have evolved to become (not completely unjustified) rants about the job market. These threads elicited this comment,

Perhaps comments should rather be associated with the blog webpage or another webpage for discussion (maybe with a separate link from the mill)? I postulate that recent threads may have had a negative impact to the wiki, and potentially affect peoples’ use of the rumor page. I pose this as a question to the community.

and one response,

As someone whose name is a few places on this list, the comments have made me not post other (new) offers I have received since it only seems to make people angry.

What do you think?

In collaboration with a few colleagues, I have sketched out a wiki page with some guidelines for refereeing submitted journal articles.

Nearly everyone has wildly different expectations of the goals, duties, and time expenditures expected of a referee. At times this leads to combative encounters, complaints to editors, editorial decisions thought to be bizarre by both the author and referee of the same paper, and incorrect results being accepted. While every paper and process is somewhat unique, many of these problems likely stem from a lack of any guidance and the lack of a consistent set of expectations within the community. A relatively large collection of postdocs/young faculty have no idea what the expectations are for the referee process, with the only guidance being the very wide range of referee reports we have received over the years. Below, we attempt to provide some of this lacking guidance.

ROLES OF THE REFEREE:

• decide the “reasonableness” of the paper
• point out obvious errors, if any
• evaluate major claims of paper for reasonable-ness
• suggesting changes that would improve the readability and accessibility of the paper

THINGS REFEREE IS NOT RESPONSIBLE FOR:

• redo all calculations
• identify and fix grammatical or typesetting errors
• suggesting major additions. resist the urge to try to turn the paper into one that you would’ve written. Be a referee and evaluator, not a co-author

THINGS WE WISH REFEREES DID NOT DO:

• Contrive ways to add references to their own papers
• Take three months to return a cursory report that makes it obvious they barely read the paper
• Be mean and condescending to authors they don’t know personally. Instead, consider trying to write in the same tone you would use if the author was standing right in front of you.

Do you agree with what we have there so far? What’s missing? Do you have any concrete advice on what you look for in a good referee report? What guidelines have you set for yourself as a referee?

UPDATE – In your comments, please just give the guideline you’re suggesting and refrain as much as possible from recounting your nightmare referee stories.