## Tuesday, April 29, 2008

### Correctly reset LaTeX's theorem counters

Now that's a technical title to start with! Let's keep this short: I've gotten the following question a few times already. When numbering theorems (either standard LaTeX or by package amsthm) within sections (or deeper levels), the counter is not correctly reset when starting a new chapter (or in fact any level above your numbering level).

Example:

\newtheorem{lemma}{Lemma}[section]

\chapter{First chap}
\section{First sec}
\begin{lemma}that's the one\end{lemma}

\chapter{Second chap}
\begin{lemma}This number is wrong.\end{lemma}
\section{Next sec}
\begin{lemma}Now it's OK again.\end{lemma}


Will produce:
Chapter 1 First chap
1.1 First sec
Lemma 1.1.1 That's the one
Chapter 2 Second chap
Lemma 2.0.2 This number is wrong.

2.1 Next sec
Lemma 2.1.1 Now it's OK again.

Notice how the theorem counter did not get reset when entering the second chapter. It is only reset when entering a new section. Of course, I know that the zero is ugly, but apparantly some people really do want to include theorems in a chapter even before the first section has started.

Fix:
In your document preamble (after the \newtheorem), put the following:

\makeatletter
\makeatother


Note that this is only necessary for document classes report and book. When you are numbering within, e.g., subsection, also add a \@addtoreset{lemma}{section}. You'll get the idea.

## Thursday, May 24, 2007

### Two minor editor enhancements

Only for BibTeX and NEdit users: you probably know that the bibliography style often lowercases your texts for titles. This is not what you want in the following case:
An hllc riemann solver for magneto-hydrodynamics
You need to put braces around parts that should not be changed, i.e., in BibTeX form:
An {HLLC} {R}iemann solver for magneto-hydrodynamics
 Put the following piece of code in your ~/.nedit/nedit.rc configuration file for NEdit. nedit.macroCommands: \ ...many built-in macros... }\n\ BibTeX capitalise:Shift+Ctrl+U:c:R: {\n\ replace_in_selection("([A-Z]+)", "\\\\{\\\\1\\\\}", "regex")\n\ }\n nedit.bgMenuCommands: \ After typing a title, just select it and press [Ctrl]+[Shift]+[U]. It will enclose all uppercase parts inside braces. Not much special about it, but handy it is. Oh, and whilst you have your configuration file open, also add this: Comments>% Comment@LaTeX:Shift+Ctrl+C:c:R: {\n\ replace_in_selection("^.*$", "%&", "regex")\n\ }\n\ Comments>% Uncomment@LaTeX:Shift+Ctrl+Alt+C:u:R: {\n\ replace_in_selection("(^[ \\\\t]*%)(.*)$", "\\\\2", "regex")\n\ }\n\ When editing a LaTeX file, select some complete lines, press [Shift]+[Ctrl]+[C] and you'll have the entire block commented by % characters. Include the [Alt]-key to uncomment. 
 
 posted by Arthur at 2:37 PM 0 comments 
 Thursday, April 26, 2007 Colorize your (svn) diffs People who know me, know that I love color on my computer screen[1]. It helps me reading code or output faster. I was not on a side track today, no, but when cleaning up my ~/bin, I just thought that my tiny colordiff script may be useful to others too. It (modestly) colorizes output from svn diff, or plain diff output. Here is an example of svn diff on a directory with some modified files: [dam@doffer:~/avandam_svn/phd/sw/fortran/src]$svn diff . | colordiff Index: mmadapt.f =================================================================== --- mmadapt.f (revision 1114) +++ mmadapt.f (working copy) @@ -429,8 +429,8 @@ subroutine eval_monitor integer :: i1, i2, iq, id real(knd_double) :: alphap(nq, ndim) - call eval_monitor_nondir - return + !call eval_monitor_nondir + !return call cellaverages(x, x, xc) ! I use this result in move_mesh too! Index: mmsolve.f [..] You can also use this on normal diff output: [dam@doffer:~/avandam_svn/phd/sw/fortran/src]$ diff mmadapt.f mmadapt_bla.f | colordiff plain 466c466 < end do ! i2 --- > end do ! i2 foo 485d484 < dq(i1,i2,1:nq,1) = (q(i1+1,i2,1:nq) - q(i1-1,i2,1:nq)) / (xc(i1+1,i2,1) - xc(i1-1,i2,1)) 503a503 > ! bla The colordiff script only uses sed and looks like this: #!/bin/bash # Mainly used to pipe output by 'svn diff' into if [[ "$1" == "plain" ]] ; then # to use in plain diff usage sed -e 's/^$$>.*$$/ESC[1;34m\1ESC[0m/;s/^$$<.*$$/ESC[1;31m\1ESC[0m/;s/^$$diff .*$$/ESC[1;37;40m\1ESC[0m/' else # for svn diff output sed -e 's/^$$\+.*$$/ESC[1;34m\1ESC[0m/;s/^$$\-.*$$/ESC[1;31m\1ESC[0m/;s/^$$Index: .*$$/ESC[1;37;40m\1ESC[0m/' fi sed just inserts the appropriate escape characters producing color output[2] at the right places. To make sure the escape characters are correct do not copy-paste, but download colordiff here. [1] color output for Stratego. [2] Escape characters producing color output. Labels: color, diff, svn, utility posted by Arthur at 11:09 AM 1 comments Wednesday, April 25, 2007 The Ultimate Coolness of Signal Catching Patience is a virtue, but I seem to be lacking it. I often perform long computer simulations and continue working on my code when the program runs in a different window. The end result of the simulation is some data files containing the final solution. What a waste of resources, however, when the simulation ends and it turns out to have become unstable in an early stage already, producing senseless data all the time. Or, imagine you really have to leave the office and want to take your laptop home, but the simulation is still only halfway. Pressing Ctrl-C is easy, but you'll have to start the simulation from the start again at home. I would like to save solution data at any intermediate time. I decided to have a look at the use of UNIX signals to solve these little annoyances. The idea is neither original, nor very difficult; it's just extremely handy! Most of my simulations consist of a large loop in the main routine that starts at simulation time Tstart and ends at time Tend, taking small time steps. Here's sample terminal output to get an idea: [..] # 1967 time = 0.1986020 finished MM after 2 steps (mmres= 9.5645049E-006 ). # 1968 time = 0.1986853 finished MM after 2 steps (mmres= 9.8183985E-006 ). [..] When I press Ctrl-Z ('suspend'), this is what happens: finished MM after 2 steps (mmres= 9.7805565E-006 ). # 2594 time = 0.2427970 (Ctrl-Z pressed) Caught suspend. Saving current data... Continuing execution... finished MM after 2 steps (mmres= 9.9850709E-006 ). # 2595 time = 0.2428664 And when I press Ctrl-C ('interrupt'), this is what happens: finished MM after 5 steps (mmres= 1.0567982E-005 ). # 2617 time = 0.2444400 (Ctrl-C pressed) Caught interrupt. Saving current data... Exiting. Note that I deliberately use the SIGINT (Ctrl-C) and SIGTSTP (Ctrl-Z) signals, because those are sent when pressing the stated key combinations. The reserved user signals SIGUSR1 and SIGUSR2 would have to be sent for example by the kill command, which is inconvenient for my use. Implementation in Fortran On UNIX systems, signal handling is performed by the functions defined in the system-wide (C-)library signal.h. Fortunately libsigwatch provides some basic but sufficient helper functions that allows us to define which signals we want to catch, and what special action should be taken. Here is my relevant Fortran (95) source code: module mmsignal use mmio contains subroutine initsighandles() integer watchsignal integer :: status status = watchsignal(2) ! SIGINT (Ctrl-C) status = watchsignal(20) ! SIGTSTP (Ctrl-Z) ! Optionally check for status == -1 to detect failure end subroutine subroutine catchsignals() integer getlastsignal integer :: lastsig lastsig = getlastsignal() if (lastsig .eq. 2) then print *, 'Caught interrupt. Saving current data...' call save_state print *, 'Exiting.' stop end if if (lastsig .eq. 20) then print *, 'Caught suspend. Saving current data...' call save_state print *, 'Continuing execution...' end if end subroutine end module The routine watchsignal(int) installs special signal handling for the requested signal: each time the signal is received, it is stored in a variable accessible by calling the routine getlastsignal(). The custom signal handler itself is not handled by the sigwatch library: I call my own routine catchsignals() within the main loop's body that checks whether the most recent signal was either SIGINT or SIGTSTOP, and if not just does nothing. To include the sigwatch library in your program, just add it to your linking stage and you are done: > gfortran -lsigwatch finvol.o mmadapt.o mmbounds.o mmconfig.o mmdata.o mmio.o mmphys.o mmsignal.o mmsolve.o mmusr.o -o mmsolve (Relevant parts are highlighted.) Implementation in C(++) In C++, we can directly use the functions in the (C-) signal library. I used this in a classroom package implementing genetic algorithms. The following code is incomplete, but all relevant parts are included: #include <iostream> #include <csignal> #include "galib.h" bool stopGiven = false; void handleUserStop(int sig_num) { stopGiven = true; std::cout << "*** User interrupt caught." << std::endl; std::cout << "*** Please stand by while current generation is completed and saved." << std::endl; } int main(int argc, char **argv) { signal(SIGTSTP, handleUserStop); // ... while (!stopGiven) { p->nextGeneration(); // ... } // In case of a user stop signal or when requested, save last generation if (stopGiven || parameters.savelastgen) { std::cout << "Writing generation #" << i << " to file \"" << LASTGENFILE << "\"." << std::endl; p->writePopulation(fpopout); } fpopout.close(); delete p; return 0; } Notice how the custom signal handler now is enabled by the signal library, installed in one step by the call signal(SIGTSTP, handleUserStop); Now that I have saved intermediate solution data, I can extend the main program to offer a resume functionality, using the data file for initialization. That task is not only easy, but it also does not have anything to do with signals, so I will not cover that here. I still benefit from the above functionality almost every week, I hope it serves you well too. posted by Arthur at 12:12 PM 4 comments Thursday, April 05, 2007 Cleaning up the Mesh Allright, the following is intended only for a small public probably, but whoever occasionally puts pictures of adaptive meshes in electronic presentations should read on. I work with (moving) adaptive meshes. There is one major problem when visualizing these things: resolution. In printed matter, my EPS or PDF pictures exported from MATLAB are of course tack sharp. Unfortunately in small pictures, the hundreds of lines tend to blacken the entire image. Setting the line width to approximately 0.2 solves this. » mh = mesh(x, y, 0*x, 'LineWidth', 0.2, 'EdgeColor', 'k'); That whas the easy part. Now what if the output device does not have as much resolution as a laser printer? Mesh Moiré When using the same PDF pictures in an electronic presentation, e.g., by latex-beamer, the viewer is left to do a proper rendering of the vector graphics in the PDF picture at a low resolution (think of a 1024 px screen width). I have not seen a viewer do this without showing moiré effects. Below is a screen capture of acroread rendering a 200 by 200 adaptive mesh: It looks awful! This will not impress the audience! What makes this even more complicated is that each program performs differently (I've had the best results with acroread 4 so far...), and that at each location the beamer is probably different in resolution from prior locations. So, I wanted to get rid of the on site rendering of these vector graphics. I'll just create a bitmap version and include that. Here's the MATLAB PNG output: (Click on image for actual MATLAB output: MATLAB does not do antialiasing!) So, which program does do good rasterizing? I had heard Martin Bravenboer being really enthusiastic about the SVG rasterizer in the Batik SVG Toolkit. I got an SVG export for my MATLAB figure by the plot2svg add-on. In MATLAB, this was just: » plot2svg('hd22conf11.svg') Next, from a terminal, I let Batik render at the desired resolution: > java -Xmx512m -jar$PKGROOT/batik/current/batik-rasterizer.jar -w 500 -h 500 -bg 255.255.255.255 hd22conf11.svg (Notice how I had to increase Java's maximum heap size; the SVG itself is 8MB, and the rasterizing apparently takes a lot of memory.) The resulting MATLAB -> SVG -> PNG output: Still far from optimal... I'm willing to lose some sharpness, if that rids me of the moiré. So, I rasterize a huge image, say 4000 by 4000 px, and scale that down to the desired size, e.g., by ImageMagick's convert: > java -Xmx512m -jar \$PKGROOT/batik/current/batik-rasterizer.jar -w 4000 -h 4000 -bg 255.255.255.255 hd22conf11.svg > convert -resize 500x500 hd22conf11.png hd22conf11_batik4000convert500.png The resulting MATLAB -> SVG -> PNG large -> PNG resized output: Now, that's what makes me happy. Of course, some sharpness is lost, but what do you expect, for a 200 by 200 mesh on just slightly more than 400 by 400 px? A final note: when including the above PNG into your latex-beamer presentation will again lead to a resizing of this PNG, with minor moiré as a result. I found an image of 560 px wide, included at half size the most acceptable, and far better than anything I've seen so far. posted by Arthur at 8:21 PM 0 comments 
 About Me Name:Arthur van Dam Location:Netherlands PhD student Computational Science More info at my research webpage Photography, travelling, other trivia at my personal homepage Weblog now dedicated to Ph.D. stories There's also a personal weblog View my complete profile Previous Posts Correctly reset LaTeX's theorem counters Two minor editor enhancements Colorize your (svn) diffs The Ultimate Coolness of Signal Catching Cleaning up the Mesh What's in a Name? Cite it Right! Sad Sun Sit Down and Listen... Zijpaadjes Archives October 2004 November 2004 December 2004 January 2005 March 2005 June 2005 April 2007 May 2007 April 2008 
   var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); var pageTracker = _gat._getTracker("UA-396919-5"); pageTracker._initData(); pageTracker._trackPageview();