1. locate apsrev to find where the apsrev.bst file is.
2. cd to the directory, and invoke grep -v 'format.url output' apsrev.bst > your/manuscript/directory/apsrev-no-url.bst to create a no-url version of the bst file in your manuscript directory (or any other directory in the search path of bibtex).
3. now, in your manuscript, replace \bibliographystyle{apsrev} with \bibliographystyle{apsrev-no-url}

1. Converting pdfs to png:
   for f in *pdf; do convert -verbose -density 150x150 $f `basename $f .pdf`.png; done
2. combining png to gif (and optimize):
   convert -verbose +dither -layers Optimize -colors 32 -delay 5 -loop 0 -dispose previous *png output.gif
• if there are too many *png files, it’s probably better to divide and conquerer: assuming png files are frame_000 upto frame_139, then first:
  for i in `seq -f "%02g" 0 13`; do convert -verbose +dither -layer Optimize -delay 5 -loop 0 -dispose previous frame_${f}?.png frame_${f}.gif; done
  then
  convert -verbose frame_??.gif all.gif
• notice that I’ve dropped the -color 32, b/c in my case it actually increases the resulting file size.
3. further optimization (YMMV) using gifsicle:
   gifsicle -O3 output.gif -o output_optimized.gif

cf:

http://www.wizards-toolkit.org/discourse-server/viewtopic.php?f=1&t=13339&start=15&sid=10c87c23bbac068a5eb44654da33167f

p.s., a related operation is to combine say every 10th of the pdfs for closeup inspection:

pdfjam frame_??0.pdf --papersize '{12in,9in}' --outfile frames.pdf

pdfjam is a frontend to the latex package "pdfpages". The --papersize I used is the same as the one I had used in gnuplot when generating these plots (set term tikz size 12in,9in ...).

The problem with rb/gsl is speed. The other day, my boss walked in and compiled his fortran code on my machine. It beat my ruby code hands-down—one would think gsl, being a C library, should be on par with lapack, but apparently it’s not, and it’s not (entirely) ruby’s fault since I rewrote the same stuff in C, using gsl, and it’s still about 4 times slower than my boss’s fortran code using lapack. (I guess partly it’s b/c gsl is using its own blas implementation).

So I want something faster but still with natural semantics—e.g., matrix multiplication should be A*B, not dgremm(...A...B...)—so C++ seems a reasonable place to look at. So far I find armadillo suits my needs quite well. It is a c++ linear algebra library interfacing with lapack/blas.

On gentoo, this is what one needs:

1. If you have intel cpu, emerge sci-libs/mkl. This is a blas/lapack drop-in replacement from Intel. You need to go to intel’s website and register (free) for a non-commercial usage license. AMD has a similar library. Otherwise, just setup your blas/lapack of choice.
2. use eselect blas/cblas/lapack list/set to choose mkl as the blas/lapack implementation to use.
3. now emerge sci-libs/armadillo. It is important to install it after 1) and 2) b/c it will decide what library it’s linking against during compilation time

Now, #include <armadillo> in your cpp code, and use
g++ -O3 -larmadillo your_code.cpp -o your_exe
to compile. You don’t have to use -lblas -llapack as these are already taken care of by -larmadillo (which was done in 3 above, that’s why emerge order is important).

On a Mac OS X (my office workstation), the appropriate way to compile is instead:
g++ -O3 -framework Accelerate your_code.cpp -o your_exe
as per armadillo’s readme file.

I transcribed my ruby/gsl code into c++/armadillo, and on the Mac, it actually is 2 times faster than my boss’s fortran code—since both are using the same underlying blas/lapack implementation, I suppose there’s some unnecessary computation in the fortran code. At any rate, it seems safe to say the c++ overhead is not significant so I’ll happily settle for armadillo for the moment.

1. the two displays better have the same resolution

   There is a way around this, described here, where essentially one sets up the projector to just reproduce part of the laptop screen, but I find the resulting image on the projector a bit too fuzzy.

2. The pdf viewer must be able to span the two displays in its presentation mode. Surprisingly my day-to-day choice of lightweight viewer, evince, doesn’t support this—instead it just spans a single display in its full screen mode. (I’m using xrandr for dual-display setup. more on that later). Luckily acroread behaves in the desired manner (with some caveat. see below)

Here’s the script I use to add a projector to the right of my laptop screen (i.e., right edge of laptop screen identified with left edge of the projector screen):

xrandr --output LVDS1 --mode 1024x768 --primary
# force use 1024x768 mode of the projector
xrandr --output VGA1 --mode 1024x768 --right-of LVDS1 || (xrandr --addmode VGA1 1024x768 && xrandr --output VGA1 --mode 1024x768 --right-of LVDS1)


Three things to note:

1. The reason why I put the projector on the right is because the window manager I use (awesome) automatically push all windows onto the left-most screen when a second screen is added, and you don’t want all your stuff to go up onto the projector–I’m sure there is a way to overcome this in awesome but I’m just too lazy.
2. The --primary is also necessary, this tells xrandr to set the laptop screen (LVDS1) as the primary one. Why? Because when going into full screen mode, acroread aligns the top-left corner of your document to the top-left of the primary screen. If your projector ended up becoming the primary screen, your notes will be displayed on the projector instead of your slides (which is pushed outside the visible range).
3. With the above layout, your beamer document should have notes frames placed on the left hand side, \setbeameroption{show notes on secondscreen=left}

For completeness, here is the script to shut off the projector output:

xrandr --output VGA1 --off
xrandr --output LVDS1 --auto


Here’s a web page from JadeTeX that pointed me in the right direction, http://jadetex.sourceforge.net/#index-div-d18e113. The following solution is based on this.

1. make changes to texmf.cnf. You may want to use `locate texmf.cnf’ to find where it is. Then in it, change `main_memory’ from 3000000 to say 8000000
2. now regenerate latex.fmt for plain latex, or pdflatex.fmt for pdflatex. E.g., to recompile pdflatex.fmt:
   1. find where “pdflatex.ini” is
   2. cd to that path, then invoke “pdflatex -ini -progname=pdflatex pdflatex.ini”
      Notice that this is different from what’s in the JadeTeX webpage. You need to invoke “pdflatex” instead of “tex”
   3. now find where the original “pdflatex.fmt” is, back it up, and copy the generated “pdflatex.fmt” to there
3. to regenerate “latex.fmt”, use “latex -ini -progname=latex latex.ini

In gentoo, the proper way of fixing this once and for all is:

1. Change the value of the corresponding field in file /etc/texmf/texmf.d/20sizes.cnf. This should persist through all future texlive upgrades.
2. run texmf-update to regenerate the system-wide texmf.cnf
3. run fmtutil-sys --all to regenerate the .fmt files

Some more googling brought me to this gcc ML post. The solution is simply to add -mstackrealign into your /etc/make.conf. Re-emerge zlib then solves the problem.

NB:
(1) ‘createstyle’ is crucial, otherwise tex will complain about missing ‘gnuplot-lua-tikz.sty’. This doesn’t seem to be mentioned in the first several google results
(2) I have to comment out the ‘utf8x’ package in the resulting tmp.tex. That may just be a problem with my tex environment

and finally, don’t forget to change /boot/grub/menu.lst and /mnt/newgentoo/etc/fstab

suppose I have a datafile with 3 columns. I can plot columns 1 and 2 as a curve:

gnuplot> p 'datfile' u 1:2


In my problem, the 3rd column indicates whether the entry is “localized on the left side”, which will have abs($3)>1, or the “right side”, having abs($3)<1. I want the curve to be plotted in one color (say red) for the “left side” segment(s), and another color (say green) for the “right side” segment(s)

somewhere in gnuplot’s manual, it says it will silently drop data if they are unplottable, and gives an example that 1/0 is unplottable (division by zero). so here’s the idea:

define the “above” and “below” function:

gnuplot> above(x,a) = x > a ? 1 : 1/0
gnuplot> below(x,a) = x < a ? 1 : 1/0

then I can use them to pick out the left/right segments:

gnuplot> p '' u 1:($2*above(abs($3),1)) w l lt rgb 'red' lw 2 tit "localized to the right"
gnuplot> rep u 1:($2*below(abs($3),1)) w l lt rgb 'green' lw 2 tit "localized to the left"


there is a minor problem: for data files, the segments with different colors are always separated by a small gap b/c neither above nor below would cover that gap. Haven’t thought about how to solve this yet, probably a clever redef of above and below could do the job.

Attached is some real world example.

2. emerge foomatic-db-ppds, equivalently just download the ppd file corresponding to your printer (the one in my office is lexmark c543dn)

3. add yourself to the groups lp (for printing) and lpadmin (for using web interface to configure cups)

4. start cupsd (e.g., add it to the default run-level), then visit https://localhost:631

5. add printer from within the web interface. For the lexmark mentioned above, locate the corresponding ppd file installed in step 2. The network address should be socket://ip-address-of-the-printer (I googled and saw on one lexmark official page that the printer should be accessed through the port 9100, which from the cups manual should have socket:// in its URI)

6. I also queried the printer’s default printing options from within cups web interface b/c the default option used by cups doesn’t utilize the duplex feature of the printer.

7. now just use lpr -P&lt printer name &gt to print (e.g., from the gtk printing dialogue box). &lt printer name &gt is the name you used in step 5 when adding the printer.