PGF/TikZ

For a while now I was wondering how on earth those neat vector graphics in textbooks are made. I remember my professor of international economics producing graphs in CorelDraw, which is not the state of the art software I had expected.

Because I'm studying distributions at the moment, I was looking for a LaTeX bell shaped curve. I found the GPF/TikZ package and boy, this is what I needed for so long! Within TeX/LaTeX, it's a fairly recent addition. Its predecessor is PStricks, a postscript based graphical language that can't live in a PDF world.

Unlike much of the LaTeX manuals, the TikZ documentation is very instructive and even starts with 80 pages of tutorials. By the way, up to date manuals can always be found at:

http://texdoc.net/pkg/<packagename>

Reinhart-Rogoff

The best joke in decades is the Reinhart-Rogoff paper in the American Economic Review 2010 special issue (this). Not so much because they messed up stats - everybody does - but because they wouldn't leave their stance. No doubt the couple is more than twice as smart as I am, maybe that's why it's hard to admit. Here's a summary, and this is the Herndon Ash Pollin revelation paper.

I quote some guy called Dennis Schminke on the Wall Street Journal online:

"I spent 29 years of a 38-year career with a major US corporation performing operational and financial analyses. Much of that time included review of the work of peers and subordinates. When PC's and spreadsheets first came along in the early 1980's, the trouble began. My experience...if it's on a spreadsheet, there is a good chance there are errors, especially in the hands of inexperienced or careless users. And all we did with our error is cost our company money. We did not blow up the economy or cause trillion$ to be spent chasing an environmental rabbit."

Anyway, it seems that the US does far worse than thought, if you check alternative stats. 

Counting lines of code in multiple files

Ever wondered how much work you put in a project? The best way to operationalize is to count (obviously) the number of lines in your code. I'm aware that this is a relative measure: some people need more lines, but you may compare different projects.

I found the following line to type in MS DOS Prompt that counts lines within each of a series of files:

for %G in (*.do) do find /c /v "_+_" %G

Where *.do are the syntax files of the project in the present working directory. You still have to sum all output manually though.

Thanks to Marten Braten.