musical epigraphs

In my ongoing quest to learn more about LaTeX than I really wanted to know, I have figured out how to use lilypond together with a redefined \chapter command. Of course, it’s all worth it because I can do this:

Chapter 2 plus epigraph

In other news, I’ll finish writing about ITA when I get more than 20 minutes of contiguous time.

From graduate admissions to the future

I realize this is a bit rambling.

One thing that I’ve done for the last few years is act as an associate reviewer for graduate applications for our department. Basically this means I can chip in my 2 cents on applications during the initial review. I’ve already written about my shock at the kinds of letters people write (although I was certainly more naive then). One thing that I’ve come to realize over the years is that it is possible to write a full, good letter for someone whom you don’t know too well that both indicates the basis on which you can evaluate them (e.g. took your class and got an A, did research with your grad student, or did research with you) and is not ambiguous due to “conspicuous omission.” Writing a recommendation letter is an art — if you could just talk to the committee it would be a lot easier, but with N-hundred applicants of whom you admit at most 4 N, the written word is most of what they have to go on.

I often wonder about the total statistics of people who apply to graduate school, especially domestic students who apply to graduate school. At a state school like Berkeley there is a policy to encourage the admission of US citizens and permanent residents (a good thing, in my opinion). But how many of domestic students are interested in graduate programs? Are there many potential strong candidates who don’t even consider a career in graduate school? My gut feeling is that yes, there are many graduates who would benefit from and enjoy some exposure to engineering research at the graduate level who never even consider it. But that’s just a gut sense, which may be off.

The whole process raises a lot of big questions, ranging from “what is the purpose of the graduate program?” to “what can we do at the undergraduate level to bolster interest in postgraduate research?” to “where should the future of academic research in engineering go?” None of these has an answer, and I think that succinct answers are impossible unless you subscribe to some inflexible dogma. But they’re good to keep in the back of my head, I think, especially since I am (hopefully) looking towards a future in the academy.

Berkeley EECS makes TA-ing more cushy

At the end of last semester I got a memo from our department trying to make TA-ing a more attractive prospect. In reality, a grad student in EECS is a TA here (or Graduate Student Instructor (GSI)) for one of three reasons : they’re a first-year and don’t have an advisor (yet), their advisor is low on funds or doesn’t have funds for their particular project, or they are fulfilling their teaching requirement to graduate (one semester only). The difference between being paid as a TA and as a research assistant (Grad Student Researcher (GSR)) is significant — the union negotiates the pay scale for GSIs, and the University is not going to let salaries rise if they can help it. In some instances a student’s advisor can bump up their salary to the GSR level. So now the department recommends:

  • If you are doing research the same semester you’re teaching, your advisor should give you a partial GSR to help out.
  • You can be appointing as a 100% GSR during winter break if you are around.
  • If your advisor can’t afford to pay you and you are GSI-ing to fulfill the graduation requirement, then the department will give you a unconstrained fellowship.

All in all, it’s seems like a much more pleasant deal — how this will end up changing the dynamics of TAing is unclear though. It also makes things much much nicer in EECS than in other departments, which seems somehow unfair in the end. Why can’t all GSIs get better pay?

Thesis strategies

I’ve completely revised my thesis strategy. Before I had hoped to make incremental progress: 2-4 solid pages a day of material I was happy with and would constitute a solid draft. Now I’m just wholesale copying chunks from papers I’ve written in the hopes of getting a handle on what holes I need to fill and how best to organize everything. I started feeling like writing my thesis was a zero-sum game where the payoff is my ability to think; every lemma I finalized in the text took away one potential lemma that I could prove about new and exciting problems. The new method means more tedious proofreading and checking later, but at least I have a sense of the big picture. Of course, now my pages vs. time graph is going to look strictly concave instead of linear, so as long as I stop thinking Δpages = progress it should all work out.

perl script for merging .tex files for ArXiV

I thought a good use of part of my Sunday would be to (re?)learn a little Perl and make my life a bit easier. Suppose you have a paper that’s split up into many files. This script will parse your main LaTeX file and generate a single LaTeX file for the whole paper. It searches recursively for “\input{}” commands and replaces them with the relevant file. It seems to be functional enough to use, but everyone has their own LaTeX usage conventions, so YMMV.

This is particularly handy for submitting papers to ArXiV, which requires a single .tex file, and cutting and pasting in 20 little files can become a bit of a pain. With the perl script for stripping comments, you can generate the .tex for your ArXiV submission on the fly.

I spent a little time searching for a script like this online, since I’m sure many people have written such a thing, but I didn’t turn anything up. Hopefully this will be of use to others looking for a similar hack. Sorry for the lines getting chopped off in the display — it should show up if you cut and paste the text.

#!/usr/bin/perl

# mergetex.pl
#
# Script for merging tex files into a single monolithic file.  This
# script should make it easy to generate an ArXiV-friendly single
# .tex file from a paper that is broken into subfiles using LaTeX's
# \input{} command.
#
# USAGE:
#     ./mergetex.pl  [input]  [output]
#     ./mergetex.pl  mypaper.tex  mypaperMerged.tex
#
# mergetex takes two arguments, the [input] file and the [output]
# file into which the merged files should go.  It recursively
# searches [input] and adds any file given by uncommented \input{}
# commands.
#
# v0.1 by Anand Sarwate (asarwate@alum.mit.edu) with tips from Erin Rhode.

use IO::File;

if ( scalar(@ARGV) != 2) {
   die "Syntax Error : use 'mergetex.pl [input] [output]'"
}
$infile = shift;
$outfile = shift;
print "Generating tex file from $infile and storing in $outfile.\n";
my $outputfh = new IO::File($outfile, "w") or die "Could not open $outfile: $!\n";
my $inputfh = new IO::File($infile, "r") or die "Could not open $infile: $!\n";
parsetex($inputfh,$infile);
$outputfh->close();

sub parsetex {
  my $fh = shift;
  my $file = shift;
  print "Found $file.  Merging into $outfile.\n";
  while () {
    # strip out comments
    $decom = $_;
    $decom =~ s/^\%.*$/\%/;
    $decom =~ s/([^\\])\%.*$/\1\%/g;
    # search for lines with "\input{}"
    if ($decom =~ /\\input{(.*?)}/) {
      #get new file name
      if ($1 =~ /.tex/) {
        my $newfile = $1;
      } else {
	$newfile = $1 . ".tex";
      }
      # recurse to input new file
      my $newfh = new IO::File($newfile, "r") or die "Could not open $infile: $!\n";
      parsetex($newfh,$newfile);
    }
    else {
      $outputfh->print($decom);
    }
  }
  $fh->close();
}

Limited feedback achieves the empirical capacity

For those who think writing in the blog precludes doing work, here’s a snapshot of something due in Sunday’s ArXiV update:

Limited feedback achieves the empirical capacity
Krishnan Eswaran, Anand D. Sarwate, Anant Sahai, Michael Gastpar
(Submitted on 2 Nov 2007)

The utility of limited feedback for coding over an individual sequence of DMCs is investigated. This study complements recent results showing how limited or noisy feedback can boost the reliability of communication. A strategy with fixed input distribution $P$ is given that asymptotically achieves rates arbitrarily close to the mutual information induced by $P$ and the state-averaged channel. When the capacity achieving input distribution is the same over all channel states, this achieves rates at least as large as the capacity of the state averaged channel, sometimes called the empirical capacity.

Mathematical methods in systems EE?

One thing that I have definitely benefited from in graduate school is my undergraduate background/degree in mathematics. It’s not that I use the contents of the math classes I have taken — Dynkin diagrams and cohomology don’t often appear in information theory or signal processing problems — but I am pretty comfortable with mathematical formalism. Grad students who didn’t do as much math usually get caught up on measure theory and so on by taking the graduate probability sequence or analysis sequence. What we don’t get is a survey of all the mathematical tools which we could use to attack different problems so that we know what kind of tools may relate to a given problem and where to look for it.

I think a first-year topics lecture series that introduces some new mathematical concepts to first-year graduate students could be great. Subjects like algebraic graph theory, auctions and mechanism design, random matrices, and so on may form a small unit in a regular class or may not be covered in classes at all. Not everyone wants to sit through a reading group on percolation theory, but they might want to get a basic idea of what percolation results are like and how they are useful (e.g. network connectivity).

On the other hand, maybe if such a lecture series were offered nobody would come and it would be useless. Any thoughts?

SSP 2007 : aftermath

I just finished up attending the 2007 Statistical Signal Processing Workshop in Madison. Normally I would have blogged about all the talks I saw, but (a) the only “talks” were tutorials and plenaries, and (b) I’m a little burned out to write much. Despite the fact that I applied to grad schools for signal processing and took the DSP prelim exam at Berkeley, I’m not really much of a signal processing guy these days. All of the submitted papers were given as posters, and despite being organized into “sessions,” all the posters were in the same room, so there were about 30-40 talks going on at the same time in parallel for 2 hours. I was a bit dubious at first, since my experience with poster presentations is that they have a large effort-to-value ratio, but this format worked for me. I was unfamiliar with about 80% of the problems that people were trying to solve, so going to talks would have made me confused. Instead, I could at least talk to someone and get the point of what they were trying to do, if not the scale of their contribution.

The one downside to the conference for me was that several of the posters that I wanted to see were in the same session as me, so I ended up missing them! Luckily I was next to “Distributed Average Consensus using Probabilistic Quantization,” which is right up my alley (from my work on gossip algorithms), but I could only listen in every once in a while. If only we could encode our talks using an erasure code — then if I listen to 7 minutes our of 10 I could interpolate the other 3…

ASEE fellowships blog

Apparently the ASEE has a fellowships blog. They administered my NDSEG fellowship back in the day. It seems to be laden with NSF news, but I think it’s a new feature, so I’m sure it will develop over time. Hopefully it will be a good resource for undergrads and early grad students to navigate the thicket of fellowship applications.