More in the matrix algebra scheme of things.

A document with some more handy relations.

I hate BLAS/LAPACK interfacing so much. And there are, like, two pages that talk about it on the internet. I might have to change that.

EDIT: I wrote, like, 6 wrappers for BLAS/LAPACK functions today. It was painful. There are two websites that talk about this on the internet (and the lecture notes I have from my statistical computing course). That's it. Two. Everybody else, of course, has figured out how to use the C library interfaces and therefore don't think about it. It's also annoying because, you know, if I chained these things together instead of wrapping each individual function, it would be much more efficient. That's why they were made in the weird way they were. But doing it that way involves a lot of magic and debugging.

A note for later: efficient calculation of big covariance matrices

This answer is helpful. Now, this may not be the most efficient way to calculate the sample covariance of a large data frame, but it's a fairly well-optimized (all BLAS) and fairly easy method which avoids the numerical difficulties of the various naive methods. Then, say, if you want to decorrelate, DPOTRF and DTRTRI or something will get you the proper matrix.

More on why public funds for sports stadiums are a bad idea

Pretty much all economists agree. It's not as strong of a consensus as the consensus of climate scientists about climate change caused by humans (answer: yes, it is happening and it is caused by human CO2 emissions, among other things), but it's still strong. Far stronger than any other political conclusion I am aware of.

Why are manhole covers round?

They aren't round. There are plenty of square manhole covers. Generally, round manhole covers go on round manholes and square covers go on square holes. To do otherwise would be silly. So why are some holes round and others square?

public service announcement about redirecting stdin, stdout

I'm making an announcement about this because it caused me several hours of debugging problems and there were few google results that contained this answer.

Problem: I wrote a big long C program that printed output to stdout and also wrote some stuff directly to a log file, but the verbose output was also helpful sometimes. Naturally, I wanted to save that for later, so I did the usual thing to run the program:

./program > log.txt &

When I made my toy examples, included tons of diagnostic output, and ran it on smaller data sets, of course, things worked as expected. However, when I removed diagnostic output and ran it on larger images (ie, so it would take hours to run instead of minutes), suddenly, my logs were turning up empty even when I checked them hours later. I was worried! So I'd kill the job, tweak the file, recompile, and start doing more obscure things:

./program &> log.txt 
./program 2>&1 | tee -a some_file

And even some options involving screen. The above two are probably your best options. Oddly, none of these worked. However, when I would run in the terminal, things would show up.

Solution: stdout, when it is not running to a terminal or terminal emulator, will buffer the output and release it in chunks. The buffer can be up to 4K. So, if your program is ouputing perhaps 10 lines over the course of 12 hours before closing, you might not get any output in your log if you do it this way until the program finishes. Therefore, either have the program write directly to a log file (if you want to glance at output along the way), have your program write a lot of output, or, in your program, use the following after printf commands where you really want to be able to view your results immediately-ish:

fflush(stdout);

Or whatever the equivalent command is outside of C. HTH. HAND.

In case you're wondering what I was up to, I was finishing up an incremental semi-supervised k-means algorithm. Exciting!

Now back to your regularly scheduled theological content.