Friday, February 18, 2011

Dr. Bernoulli gets a job: Mathematics of the Job Search – Faculty Version

I recently found out that the Duke Computer Science department had 404 applicants for the open position in their department. I mentioned that to a CS professor from a different university, and he didn't seem surprised by that number. Moreover, when you think about how many "faculty candidate" lectures there usually are within a CS-like department each hiring season, and you consider that those interviewees are likely a small selection of the total applicants, then 404 starts sounding reasonable.

When there are 404 applicants who each have PhD degrees, publications, and possible post-doctoral or existing faculty appointments, let's also assume that the objective function that each department is maximizing is pretty flat. If you don't like that assumption, then assume we have no prior information, and so we will maximize entropy and assume that each applicant has a 1/404 chance of being picked for the job (in reality, this probability is itself conditioned on whether the state steps in and has a hiring freeze... so the real probability might be closer to 1/1000). So that is a very low number. Can we fight low probability with high volume of applications?

Assume we apply to N schools where the probability of getting an offer is
p = 1/404
at each of them. Then the probability of not getting an offer from each of them is
1 - p = 403/404,
and so the probability of not getting an offer from all of them is
(1 - p)N = (403/404)N.
So finally we arrive at the probability of getting an offer from at least one of them, which is
1 - (1 - p)N = 1 - (403/404)N.
Hypothetically speaking, let's say you apply to N = 50 such positions. Then you have a
1 - (403/404)N = 1 - (403/404)50 ≈ 11.65%
probability of getting the offer. Of course, if you were paying attention, you remember that p (1/404) is very small in this example. Consequently, the (1 - (1 - p)N) curve looks linear for a wide region around the origin. So even though you remember your fourth-grade math teacher teaching you that you cannot additively accumulate probabilities (i.e., your probability of getting a job is not (N × p)), in this small-p case, it is a pretty decent approximation. In particular, even with our ostensibly large N, it is the case that
N × p = (50)(1/404) ≈ 12.38%,
which is pretty close to our slightly more dismal 11.65%.

In December, I ran into a woman who just got finished submitting all of her faculty positions. She said she applying to just 10 of them because she was exhausted and figured she was just practicing this round. Setting N = 10 reduces your chances to 2.45%. Having said that, the distribution across the applicant pool is certainly not flat. Her home institution, research, adviser, and other factors make her a very attractive candidate who will likely do well with such a low N... In fact, she was recently interviewed at a university near me (that, again, may have to deal with hiring freezes, etc., in the near future).

Now, in my case... Maybe I should burn my CV and dust off my résumé... I hope I'm not too old and outdated.

Wednesday, February 16, 2011

Microsoft's version of Google Scholar?



natbib-compatible BibTeX style (BST) file for Springer LNCS publications

UPDATE: Additionally, if you prefer "References" instead of "Bibliography", you have to re-define the \bibname macro in your document (e.g., just after you include natbib). Just add a
or a
and you should be up and running with your desired bibliography name.
For some reason, the folks over at Springer do not like to make their BibTeX style (BST) files natbib compatible. This omission seems egregious when considering the kind of authors that would submit to journals and conferences that use LNCS-style formatting. Springer does provide LaTeX support files for LNCS, but the included BST file is not natbib compatible (because it was not built with natbib and author–year extensions turned on, which are needed in natbib even when numbered references are used). What makes things more difficult is that it is produced by hacking another BST (titto.bst) that was originally generated properly using makebst, and many of the hacks were already implemented natively in merlin.mbs. So much more of the postfix BST language was hacked directly rather than would have been necessary if the correct docstrip driver options were picked in the first place. So that makes it more challenging to reproduce a refactored version with additional natbib functionality without worrying about introducing regressions.

Nevertheless, I've done my best, and I've made the the natbib-compatible result splncsnat.bst available for download. I was able to remove the need for some of the manual editing by a smarter choice of docstrip options, but I still ended up having to create a patch on top of a stock docstrip-generated BST (the docstrip driver splncsnat-unpatched.dbj and patch splncsnat.patch are also available). Hopefully that helps someone out there.
  • splncsnat.bst: natbib-compatible BST file for Springer LNCS-type publications
    Download and place splncsnat.bst in same directory as document's TeX source code. In the TeX preamble of the document, use
    and then in the text use macros like
    \cite{smith77}       % to get a "[1]" in the text
    \citep{smith77} % to get a "[1]" in the text
    \citet{smith77} % to get a "Smith [1]" in the text
    \citeauthor{smith77} % to get a "Smith" in the text
    The normal \bibliography{FILENAME} can be used at the end of the text where the BBL will be inserted by BibTeX.
  • splncsnat-unpatched.dbj: docstrip driver used to generate splncsnat-unpatched.bst
  • splncsnat.patch: patch used to generate splncsnat.bst from splncsnat-unpatched.bst (assuming version 4.20 [2007/04/24 (PWD, AO, DPC)] of merlin.mbs)
Of course, you need only splncsnat.bst to get up and running.

More Quick Reference Cards

Remember that time when I was quick reference card happy [1, 2, 3, 4, 5]? Today, I accidentally found another good quickref card blog post by someone else (Refcards by Michael Goerz; see the original post for the source code and other versions of these cards):He also includes a few quick reference cards not written by him (Subversion (SVN), GDB, GNU Emacs, MySQL).

Friday, February 11, 2011

Scripts to get Mercurial up and running on OSU CSE machines (SunOS and Linux)

UPDATE: A day after I posted this, Mercurial and Python (and Git) were added as optional subscriptions for users of these machines. So login to your desired machine and execute subscribe, then select MERCURIAL and whatever PYTHON is available (version 2.4.x or higher). Quit subscribe to save your changes, and re-login (of course, you can also do the same thing with GIT).
If you are a student, staff member, or faculty member in the Computer Science and Engineering department at The Ohio State University, you may have found yourself wanting to use a DVCS like Mercurial (hg) for SCM. Unfortunately, the version of Python that comes bundled on these enterprise systems prevents installing Mercurial, and some other issues on the SunOS system (like the lack of round() in the math library) prevent building a recent version of Python 2 that is needed for installing Mercurial. There are ways around this mess, and I have done my best to automate them within a script.

So give it a shot:Download the appropriate script to your desired target machine. Next, edit the script (e.g., using pico, nano, vi, or emacs) to verify that the INSTALLDIR location at the top of the script is what is desired – if you are going to run the script on both types of machines, your INSTALLDIR must be different in the two scripts. Then run the script on the machine (e.g., ./ and follow the instructions. The script is interactive, and so you will be able to manage its behavior as it runs. Be sure to follow its instructions at the end about setting your PATH and PYTHONPATH; if you ran the script on both types of machines, you will have to be clever in your script RC/profile file to set these differently based on the machine you are on – I recommend using uname to detect the different machine type.

After that, you should have a working Mercurial. In the Linux script, you may adjust the Mercurial and Python 2 versions downloaded, but in the SunOS script, you need to leave the Python 2 version alone as later versions of Python will not build on the SunOS machines (due to the problems with the old math library). On either machine, if you are adventurous, you can use the installed Mercurial to clone the stable Mercurial repository (hg-stable) and keep your installed Mercurial up-to-date with the very latest stable version.



  1. Unzip
  2. Unzip
  4. Build the sample dissertation with:
    1. pdflatex Thesis.tex
    2. bibtex Thesis.aux
    3. pdflatex Thesis.tex
    4. pdflatex Thesis.tex


Thursday, February 10, 2011

PlugBox Linux on my Pink PogoPlug: 4GB USB partition was the key

So I just installed Plugbox Linux on my pink PogoPlug v2, which was selling for about $50 on Amazon when I bought it last week.

The only problem I had was solved when I put my entire Plugbox Linux distribution on a partition of my USB stick that was only 4GB (or smaller). I used an ext3 file system, but an ext2 file system works as well (and probably FAT too). I made the partition bootable in the partition table, but that isn't necessary with the way the current version of u-Boot looks for the kernel. u-Boot looks for a partition with /boot/uImage on it. Others say that they've put /boot on a small 32MB partition by itself, but I had to put everything on one partition.

To figure all of this out, I did enable the netcat console. That let me watch u-Boot as it booted before it hands things off to the kernel on uImage. However, if I would have used a 4GB partition (or smaller) to begin with, I don't think I would have even bothered setting up the netcat console.

Hopefully everything keeps working!