scratch Buffer

"They Call Me Dr. Worm"

2009-12-12T06:36:20Z

I defended today!

An old friend.

2009-12-05T07:44:48Z

For nearly five years now, I've had two color schemes defined in my init.el file for Emacs. One is a basic dark text on white scheme that's a tweaked version of the default colors from XEmacs. The other color scheme is something of its inverse with light text on a black background. I based the second one off of the first. While I found that the pure primary colors work nicely on the white background, they're a little too strong against black. So I ended up switching them to analogous secondary colors that are a little bit desaturated:

For some reason, I always found this to be a really comfortable color scheme. This week I realized why. While switching to it, I was thinking of it as my "midnight" color scheme. That rung a bell and for some reason it made me think more specifically of something about pinball at midnight.

And that's when I realized...

It was the old Apple ][ palette! The machines of my childhood that I had learned to program on! No wonder it felt so familiar and comfortable. It also explains why I gravitated towards slightly desaturated, less pure colors; they were a better match for how the colors usually appeared on all those monitors that always seemed to be cranked up to maximum brightness.

Incidentally, that Emacs screen shot is also showing off my very own programming font made from scratch in Fontforge. But that's a topic for another post.

ICFP 09, Post Mortem, Part One

2009-06-30T07:16:05Z

"It would be pointless to observe that the finest volume of all the many hexagons that I myself administer is titled Combed Thunder, while another is titled The Plaster Cramp, and another Axaxaxas mlö."
— "The Library of Babel" Jorge Luis Borges.

Well, as of the point when they froze the scoreboard, my solo effort was ranked in the 24th place with 2763.6783 points. The following is the first half of my post mortem, describing the basics and the lower level parts of my code. I intend to post a second half tomorrow, describing my solutions to the specific problems.

The Basics

I wrote all my code in C++, of course. Don't get me wrong: I definitely enjoy messing around with other program languages and other programming paradigms. It's a fun challenge to work under interesting constraints. But when it comes to actually getting stuff done, C++ is the pragmatic choice for me. I don't want a programming language's ideology getting in my way.

Build-wise, CMake is my preference. It's designed for C/C++ and it's sane but powerful. In this case, the program was simple enough that I just swiped the usual opening lines from another project. I could have simply made a makefile directly, but 4 lines or so of CMake did the job for me.

I also swiped a vector class from one of my projects and hacked it down to being only a 2D vector class. I know some folks dislike operator overloading, but its a godsend for something like vector arithmetic.

The VM

The VM was actually the first place where I started hacking on the code. Given the detailed specification of it, it seemed like low hanging fruit. In a fairly short period of time, I had a VM class whose constructor would read in a file and unpack the instructions. (Swiping some of my portable endian conversion code from a library in another project helped with this and saved some time.) Read and write methods for the ports were fairly straightforward.

I ended up using a simple looped switch-dispatch interpreter for the execution of the VM. Easy to write and nicely portable. At one point, I made a start at changing to indirect threading using gcc's computed goto extension to see if I could get a speed boost. But I changed my mind about this: if I was going to go non-portable to speed it up, why not go all out? I could either use LLVM (which I've employing lately for research purposes) to JIT the VM code. Or, I could just translate the code to C++, invoke g++ to compile it into a shared library, and then dlopen() that to load it in. Either would have been messier and more time consuming to implement, so I defered doing adopting those approaches until I'd actually seen that the VM was the bottleneck. It never was.

Orbital Mechanics

I actually decided to tackle the third problem set, Eccentric Meet & Greet, first. I figured if I could get my program to handle those, I should be able to handle any of the others as variations.

I spent a good bit of time on Friday night studying orbital mechanics and getting confused by things like the relationship between mean anomoly, true anomoly, and eccentric anomoly and how to calculate them from the state vectors that we had. But even if I had all the orbital elements, it wasn't clear to me how to use them to efficiently get to a moving target.

Late on Friday night, I came across something called Lambert's problem. One formulation of the problem is, given two radii from a mass center, and the angle between them (i.e., two satelite positions in polar coordinates relative to the Earth), calculate the instantaneous velocity required to get from one position to the other in a given amount of time.

I found a very nice paper on the topic by R. H. Gooding which included working Fortran-77 code for a numeric solver for this problem. I ended Friday night by porting this to C++ code. To avoid mistakes, I converted it as directly as possible, leaving it as very un-idiomatic C++ code. It takes the parameters of the formulation that I described and gives the absolute instantaneous transverse and radial velocities needed. It actually returns up to two solutions.

On Saturday, I wrote two wrappers around this code. The first would take the current position and velocity of the chaser and target satelites, respectively, as well as an initial and terminal time for the maneuver. It projected out the position of both of satelites to the initial time step, and then continued projecting the position of the target to the terminal time step. These in hand, it converted these positions to polar coordinates, called the port of Gooding's code, and converted the results back to offset velocities in the problem coordinate system. (Returning whichever solution required the smallest delta-v.)

The second wrapper employed the first quite heavily. Since the most fuel-efficient initial and terminal times are unknowns, this routine attempts to solve for them. I used the classic downhill simplex method to try to solve for these values, taking the fuel estimate of the first wrapper as the cost function to minimize. It's not perfect, but it's easy to implement and seemed to work well in practice.

ICFP 09, #2

2009-06-29T12:07:27Z

I'm calling it a night.

Position         Score           Team                   Problems Solved
21               2763.6783  	 Combed Thunder         16

I'd broke the top twenty and was in 19th place for a good long while earlier. Oh well. At least I finally had a respectable ICFP showing this year and did reasonably well for a solo effort.

ICFP 09, #1

2009-06-28T06:51:11Z

 Step: 0 Distance: 2.2343e+06 VDiff: 3588.08
 ...
 Step: 711 Distance: 0.0530664 VDiff: 3.04898e-05

This is just with made up numbers since I haven't hooked it into the VM yet, but still. I also need to optimize for fuel consumption (7688 units, in this case). By I can hit an arbitrary moving target fairly squarely now.

Debugging my VM this afternoon was frustrating when it turned out that the error was in the specification. On the other hand, I wrote a nifty little decompiler thing.

Shell Recipes

2008-09-22T21:32:15Z

I doubt these will be useful to anyone else reading this, but I'm going to collecting these here as notes to myself so that I don't lose them. I should really just turn them into shell scripts.

Generate an Emacs TAGS file for a project

find . | grep -E "\.(cpp|cc|cxx|hpp|h|hxx)$" | etags -

Use this recursively scan a directory and all subdirectories for C++ source code, and index it with etags.

Convert PDFLaTeX PDF to Illustrator-usable EPS

gs -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=epswrite -dEPSCrop -sOutputFile=out.eps in.pdf

Use this to turn a page with snippets of equations into vector paths that Adobe Illustrator can handle without choking on font embedding and substitution issues. Good for keeping fonts consistent when labeling charts and diagrams. Also good for embedding equations into diagrams.

Convert B&W scans to searchable PDF

convert pagexxx.png -filter Cubic -resize 200% -threshold 50% -compress Group4 pagexxx.tiff
tiff2pdf -z -p letter -ro -x 1200 -y 1200 -o pagexxx.pdf pagexxx.tiff

Scan pages in, clean them up in an image editor, save to individual files. Use these two commands to convert each page to PDF. Combine in Acrobat Professional, and use the built-in OCR with the "Searchable Image (Exact)" option. Gives excellent image quality and file size (avoids bad JPEG image recompression.)

Grouped bar charts, thick lines, and font embedding with gnuplot

set terminal postscript eps enhanced color solid linewidth 3 \
    "NimbusSanL-Regu,17" fontfile "/opt/local/share/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb"
set output 'cache_issue.eps'
set style data boxes
set boxwidth 0.2
set xlabel "Pirates"
set ylabel "Ninjas"
set grid y
set xrange [0:4]
set yrange [0:6]
set xtics ("1"  0.5, \
           "2"  1.5, \
           "3"  2.5, \
           "4"  3.5 )
plot '-' using ($1-0.7):($2) title "Red" with boxes fs pattern 0, \
     '-' using ($1-0.5):($2) title "Green" with boxes fs pattern 2, \
     '-' using ($1-0.3):($2) title "Blue" with boxes fs pattern 3
1 2.4104
2 4.4581
3 4.7087
4 4.7337
e
1 0.5815
2 1.0963
3 1.1257
4 1.1282
e
1 0.7219
2 1.3632
3 1.4184
4 1.4223
e

Basic example of how to set up grouped bar charts. First line shows how to make lines thicker so that they'll show up better when reduced to the width of a text-column. Also shows how to specify a specific postscript font file to be embedded.

Qualifying Exam

2008-08-25T23:19:05Z

It's done! Grand totals: one full week, five questions, and seventeen typed pages written including almost four pages for the 64 entries in the references list. And countless iced chais chugged.

Frankly, I'd rather have spent the time and energy doing, well, the actual publishable research that this is supposedly testing my preparation to do. I often wish that the Ph.D. could simply be granted after you've published enough peer-reviewed first-author papers. Given that those would all have passed evaluation by many (hopefully impartial) external experts, I'd think it'd be pretty good proof that you know your field well enough at that point.

ICFP 2008 #3 - The End, but with a bit of ray tracing

2008-07-13T09:14:25Z

Real life has sort of overtaken things and it's clear that I won't be able to get as far as I'd like in the ICFP contest so I've decided to bow out. Given that, I figure that I might as well save some time for those still in the running and impart some of my ray tracing knowledge. So I'm giving away two little routines that ought to be helpful to those still in the running. I've translated them to Python as it's a nice form of executable pseudocode. But first, here's a tiny vector class. It's obviously very incomplete, but it's just enough for the two functions I'll give below:

from math import *
class vector:
    def __init__( self, x, y ):
        self.x = x
        self.y = y
    def __add__( self, other ):
        return vector( self.x + other.x, self.y + other.y )
    def __sub__( self, other ):
        return vector( self.x - other.x, self.y - other.y )
    def __mul__( self, other ):
        return vector( self.x * other, self.y * other )
    def dot( self, other ):
        return self.x * other.x + self.y * other.y

Now, on to the fun stuff. First, you'll undoubtedly want to be able to answer the question: does a line from here to there cross an obstacle. Here's some code that will answer that:

def intersects_circle( start, end, center, radius ):
    direction = end - start
    offset = center - start
    offsetsq = offset.dot( offset )
    radiussq = radius * radius
    if offsetsq < radiussq:
        return True
    midchord = offset.dot( direction )
    if midchord < 0.0:
        return False
    invdirectionsq = 1.0 / direction.dot( direction )
    midchord = midchord * invdirectionsq
    midchordsq = midchord * midchord
    halfsq = ( radiussq - offsetsq ) * invdirectionsq + midchordsq
    if halfsq < 0.0:
        return False
    hit = midchord - sqrt( halfsq )
    return hit <= 1.0

The first test there is a quick check to see whether the start point is already within the radius of the obstacle. If so, then obviously part of the line segment is in the obstacle. The second test looks to see whether the line's direction even heads in any way towards the obstacle. And the third test determines if any part of the line from the start point towards the end point and on out to infinity touches the circle. If it does, the final test in the last statement is whether it reaches the closer edge of the circle before the end point. If you want to know exactly where it first enters the circle, then that's just start + direction * hit.

If you've got a lot of obstacles to test those rays against, you can build a tree out of them and use that to reduce the search time to be logarithmic. One of the simpler ways to do that is with a bounding volume heirarchy. This is a tree where the obstacles will be at the leaves and each interior node will contain the data for a shape (a bounding volume) that completely encloses its all of its subtrees. To test a ray against this tree you start at the root of the tree and see if your ray intersects the root's bounding volume. If so, you recurse to its children and do the same test against them and so forth. If you've built a good BVH, you can quickly cull away large groups of obstacles that you obviously can't hit.</pp>

Building the BVH is a bit tricky. There's an old approach (the MacDonald-Booth algorithm) which can work here. Take the first obstacle and make it the root of the tree. Then for each new obstacle that you find, begin at the root of the tree and expand the bounding volume of that node to include the new obstacle. Examine its children and figure out which child's bounding volume would have the smallest perimeter if you expanded it to add the new obstacle. Then descend to that child, expand its bounding volume and check its children. Eventually, you'll reach a leaf, so then you replace that with a new interior node that holds both the original obstacle at that leaf and the new one. This approach can generate highly inferior trees if you're not careful (especially for something like this the trees may end up fairly linear), but it does have the advantage of being fast and incremental.

But what do you want to use as the bounding volume? Circles can be tricky to expand, but doable. They also tend be very loose in terms of space. Boxes are dead simple deal with and are reasonably tight. If you do decide to use boxes, here's how to check whether any part of a line segment goes through a box defined by two opposing corners:

def intersects_box( start, end, corner1, corner2 ):
    direction = end - start
    if direction.x == 0:
        direction.x = 1e-9
    if direction.y == 0:
        direction.y = 1e-9
    inverse = vector( 1.0 / direction.x, 1.0 / direction.y )
    xmin = ( corner1.x - start.x ) * inverse.x
    xmax = ( corner2.x - start.x ) * inverse.x
    ymin = ( corner1.y - start.y ) * inverse.y
    ymax = ( corner2.y - start.y ) * inverse.y
    if xmin > xmax:
        xmin, xmax = xmax, xmin
    if ymin > ymax:
        ymin, ymax = ymax, ymin
    near = max( 0.0, xmin, ymin )
    far = min( 1.0, xmax, ymax )
    return near < far

Note that for both these functions, there are some simple precomputations that you can do to speed them up if you'll be calling them a lot on the same line segment, box or circle. You'd probably want to cache the inverse direction in the box test, for example. I leave that to you. Still, as for the algorithms themselves, these are pretty much the state of the art in ray tracing so you'll find them tough to beat.

Hope that saves some of you some time! Good luck!

ICFP 2008 #2

2008-07-12T08:48:50Z

Yay! Geometric stuff!

Yay! Book got signed!

Boo! Monitor died last night.

Alright, time to stop for the night. This problem is interesting. At first it looked a lot easier than last year's problem. Certainly the problem description seems much shorter. But on thinking about it, there's a lot of interesting potential gotchas. Once I realized this, I decided to adopt my usual C++ approach though I'd thought of using Python at first. I'm not sure how far I'll get on this by working alone -- I haven't even started in on the networking code yet or the low level point A to B navigation. But I seem to be well on my way to having a fairly cool exploration and static path planning module to eventually direct that A-to-B code. Fast spatial data structures I can do! :-)

ICFP 2008 #1 - The Live CD

2008-07-10T23:17:32Z

Yay for fast network connections! I've now got a burnt copy of the official ICFP LiveCD in my hot little hands.

Here's hoping that it's an interesting problem and one that's soloable since it looks like I'll be working alone.

In an interesting case of timing, this guy will be visiting tomorrow. I'm going to have to see if I can get him to sign my copy of his book.

The Eleventh ICFP Programming Contest

2008-06-14T06:35:45Z

A blog entry linked from proggit reminded me that the ICFP programming contest is coming up in about a month. Last year, I tried it solo but I think it would be much more fun to compete on a team together this year. (It also helps that I don't have a fixed work schedule this summer and that that weekend is in a dead-zone for paper deadlines.)

So anyway, this is an open invitation to anyone who reads this to think about teaming up.

How not to annoy me when I review your C.S. paper.

2008-06-13T08:38:28Z

I've been meaning to write this post for a good long while. Last week finally triggered it. It's partly a rant about the presentation in some of the papers that I had to review then and partly a how-to guide that codifies all of the little rules-of-thumb that I strive to follow when writing my own papers. They're basically cosmetic so I try not to let them affect my reviews too much. I won't reject an otherwise solid paper just because the presentation is a bit off. But it might annoy me into being a bit more critical. So without further ado, here's my list.

Use LaTeX

Don't use Microsoft Word. Just. Don't. I've heard horror stories about trying to do papers in Word. And yet, I can always tell when Word has been used. Its typography is terrible: crappy justification tending to produce very loose lines, it won't substitute ligatures, there'll be widows and orphans everywhere, etc. Using Word also tends to mean trying to manually set everything to match the journal or conferences style. Not to mention that for the references section, using Word means either having to do them all by hand (typically with inconsistent results) or throwing away gobs of cash for a half-baked reference manager like EndNote. (Oops! You want to use Word 2008? Too bad!) I have to laugh when I see discussions of problems with reference managers come up on academics_anonymous when BibTeX is free and has been chugging along for almost 25 years.

Sure LaTeX and BibTeX are a bit arcane at first, and the syntax can be awful. And they're not WYSIWYG. But come on, you're computer scientist! Presumably you should have this whole edit-compile-test cycle thing down pat by this point!

Use vector graphics for diagrams

Do you want to include a diagram in your paper? And is it mostly basic lines, curves, shapes and text? If so, draft it in a vector graphics tool and export it as EPS or PDF. Then have LaTeX include that in your paper. Not a raster image. And especially not a low-res, pixellated, aliased raster image! LaTeX will embed vector formats directly so that when a someone goes to view your paper on screen their viewer will display it according to their preferences. When they print it, your figures will come out silk smooth. Even better, most vector diagrams will only add a few kilobytes to your final paper file.

There are a handful of tools that are really useful for this. If you can find of license for it, Adobe Illustrator absolutely rocks for making figures. If not, XFig, while a bit archaic, is a fairly decent free alternative for simple diagrams. For anything that's a tree, graph, DFA or NFA, try the dot program from the Graphviz package. For charts and plots, gnuplot works quite nicely. Dot and gnuplot are also scriptable which can be useful at times.

Also, expect for people to print your paper on a B&W laser. So please make sure that the colors you choose provide a good luminance contrast. This also helps in case some of your readers might be color blind.

Use raster images otherwise

If you're showing photographs, rendered images from your system, or some other type of figure that's not amenable to vector graphics then yes, by all means include those as raster images. Try to make them of an appropriate resolution for the size of the figure in your paper, however. 300 dps is a decent rule of thumb -- so a 256x256 image would work reasonably for a 1"x1" figure in your paper. But don't expect it to look so good at 3.5"x3.5". If anything, err on the side of higher resolution. It's easier to downsample than upsample since downsampling only has to discard pixel data while upsampling has to guess at recreating it.

Never use JPG compression on the raster images that you include in your paper. It'll introduce artifacts that may obscure what you're trying to show. Instead, use PNG since it's lossless. In fact, the PDF format understands both JPG and PNG formats directly. If you use something like PDFLaTeX then those image files while be directly embedded into the byte stream written to the PDF file. Be careful about converting the images to EPS first and then embedding those with vanilla LaTeX. The DVI->PS->PDF steps tend to cause them to get recompressed into very ugly JPG images with the default settings for Ghostscript.

One consequence of the direct embedding of PNG files is that if you can find a way to reduce the size of the PNG images then that will have a direct impact on the final size of the PDF file for your paper. Most of the size of a paper's file is due to the images embedded in it so reducing the size of the image file can have dramatic results. Image editors tend to write fairly large PNG images, even on the maximum compression settings. But there are PNG shrinking tools that will throw out superfluous metadata and then search a space of compression settings to try to find the one that reduces the file size the most. Though they were originally designed for website optimization, they work quite well shrinking PDF files too. I recommend OptiPNG and AdvPNG. They use different strategies but neither will overwrite the original image unless it can reduce the file size. So using one after the other gives the maximum benefit. Using them together, I've been able to reduce the final size of one of my papers by around 40%. Don't make folks download a 20MB paper just to see if it's worth citing!

The Billionth Fibonacci Number

2008-06-03T07:45:09Z

A few weeks ago, lindseykuper wrote a post about calculating large Fibonacci numbers. Never one to resist a program challenge, I really wanted to try my hand at it and see if I could write an even faster program for calculating Fibonacci numbers. At the time, I was rather busy working on a paper but that's done now, so I gave it a shot today. Here's what I came up with:

#include <stdio.h>
#include <stdlib.h>
#include <gmp.h>

int main(
    int argc,
    char **argv )
{
    int nth = atoi( argv[ 1 ] );
    mpz_t a, b, temp1, temp2;
    mpz_init2( a, 800000000 );
    mpz_init2( b, 800000000 );
    mpz_init2( temp1, 800000000 );
    mpz_init2( temp2, 800000000 );
    mpz_set_ui( a, 0 );
    mpz_set_ui( b, 1 );
    int bit = 1;
    for ( ; bit <= nth; bit <<= 1 );
    for ( bit >>= 1; bit; bit >>= 1 )
    {
        mpz_mul( temp1, a, a );
        mpz_mul( temp2, a, b );
        mpz_add( temp2, temp2, temp2 );
        mpz_add( a, temp1, temp2 );
        mpz_mul( temp2, b, b );
        mpz_add( b, temp1, temp2 );
        if ( nth & bit )
        {
            mpz_add( a, a, b );
            mpz_sub( b, a, b );
        }
    }
    mpz_out_str( stdout, 10, a );
    mpz_clear( a );
    mpz_clear( b );
    mpz_clear( temp1 );
    mpz_clear( temp2 );
    return 0;
}

Well, okay, that's not really C++ -- it should also compile as C99. Most of the real work is done by the GNU multiple precision arithmetic library, anyway. (Yes, I know they already have mpz_fib_ui() -- that's cheating!) This also uses a different algorithm than lindseykuper's though they're both logarithmic in the number of basic steps. Whereas the algorithm that she implemented is usually attributed to Dijkstra, my program implements the algorithm outlined by Gosper and Salamin. The loop essentially implements repeated squaring, but implemented slightly unusually with bit-logic to iterate from the most to least significant bits instead of doing the standard recursive odd/even thing. In the end, it's the same result but this approach lets it do all the arithmetic in-place. The other nice thing about the Gosper and Salamin algorithm is that it only requires three multiplications per step, instead of the four that Dijkstra's seems to need.

Giving this all a whirl on a big 3GHz Opteron machine:

[hex:~/Temp] aek% time ./fib 100000000 | head -c 75
473710347345633696254897131335103865754868289377201030193412163431081491642
real    0m29.385s
user    0m29.238s
sys     0m0.156s

Not bad. It all checks out with the results that lindseykuper reported. For some real fun, though, I've tried calculating the billionth Fibonacci number!

[hex:~/Temp] aek% time ./fib 1000000000 > billionth.txt

real    9m40.174s
user    9m34.304s
sys     0m5.888s

This number has 208,987,640 decimal digits with the first and last hundred being:

7952317874554683467829385196197148189255542185234398913453039937343246686182519370050999626136556779...
6320554356934532581033548032811298867411661975017768296198982902073319952559425703172326981560546875

It is obviously composite, as it passes the divisible-by-5 test.

The sequence "12345678" appears once, beginning at the 159,774,853 digit. The number "1248163264" appears also, beginning at the 169,057,940 digit. And so does "31415927", beginning with the 140,853,142 digit. The longest contiguous sequences of any single digit are "555555555" and "777777777" at nine digits each. The sequence "1337" occurs 20,787 times.

All digits are fairly equally represented, but zero is the most common digit, appearing 20,906,722 times. One is the least common digit, appearing only 20,889,487 times. By descending order of frequency, the digits are 0,5,2,3,8,4,7,6,9,1.

One other interesting tidbit: it's actually the conversion of the final result to decimal for output that takes the most time. If I comment out the call to mpz_out_str(), it finishes in 69 seconds.

This file is obviously a little large to post somewhere for download but if anybody would like to try confirming my results, the MD5 sum on the file is 10f1f75f783b7ae9802f38a6921ac561.

I dub thee... "triffid."

2008-01-25T04:54:38Z

It's taken some thought, but I've decided that "triffid" (24" iMac, 2.8GHz Core 2 Duo, 4GB ram, 500GB HD) shall be the name of the successor to "godzilla" (Dual 2.5GHz G5 Mac tower, 2GB ram, 250GB HD, 23" Apple Cinema) as my school machine. Other contenders for the name were "dalek" and "chupacabra".

Past and present machine names in chronological order:

boojum: 233MHz P2 desktop, main college machine
grue: 100MHz P1 desktop, toy linux server
jabberwock: 800MHz P3 desktop, first work machine
wumpus: 1.8GHz P3 laptop, second work machine
trogdor: 2.4GHz P4-M laptop (Dell Inspiron 8500), third work machine
moogle: 3.06GHz P4 Northwood desktop (Dell Dimension XPS Gen 3), current home machine
domokun: 624MHz XScale Pocket PC (Dell Axim x30)
godzilla: 2.5GHz dual-G5 Mac tower, first school machine
sphinx: 1.8GHz Core 2 Duo, 17" iMac (sonetka's current machine and choice of name)

In other news, my SIGGRAPH paper is done and off to the committee. Much thanks to tollingbell for his assistance with writing it up and to sonetka for putting up with the insanity that a paper deadline involves. Wish us luck!

Busy Computers Make Me Happy.

2007-12-28T04:39:28Z

I love it when I get some kind of metaprogramming tool or a brute force search program up and running. Then I can just send it off to a remote machine somewhere that has a few trillion spare cycles, fire it up in a screen session and go off to play some video games.

Right now, my school machine happens to be off crunching through a few million FFTs in a brute force search for some filter parameters. There's nothing quite like making the machine do all the hard work.

little_cat()

2007-11-01T03:11:21Z

/* And then Little Cat A
 * Took the hat off HIS head.
 * "It is good I have some one
 * To help ME," he said.
 * "This is Little Cat B.
 * And I keep him about,
 * And when I need help
 * Then I let him come out."
 * And then B said,
 * "I think we need Little Cat C."
 *     -- "The Cat in the Hat Comes Back"  Dr. Seuss
 */
void little_cat(
    const char letter )
{
    if ( letter == 'Z' )
        voom();
    else
        little_cat( letter + 1 );
}

If I ever end up as a tenured professor teaching first year CS, I'm going to put "The Cat in the Hat Comes Back" on the recommend reading list. I'd noticed a couple of weeks ago that the "Little Cats" stored under the Cat's hat were an excellent example of recursion, with Little Cat Z using Voom providing the base case. Also that it's tail recursive (as it should be when cats are involved). This morning while reading it once more to Daniel I noticed that the first half of the book illustrates iteration, too, with the cat transferring the spot from place to place.

On the Naming of Variables

2006-11-30T08:13:47Z

Sometimes I hate trying to name things in my programs. I work hard to try to come up with really descriptive, clear, standardized names since I think that it makes the programs much easier to understand. My programs may be a bit more verbose than some but they also tend to read pretty well. Besides, long names are why we have M-/ in Emacs.

Sometimes the right name is immediately apparent and it just jumps out and writes itself into the code. Other times, it's rather difficult. I know the Extreme Programming folks talk about finding metaphors as descriptions for what a program is supposed to do. Admittedly naming something in a program is pretty much a matter of finding a metaphor for that entity. But it feels like sometimes, even when you know what the metaphor for something should be, it still doesn't quite feel right as a name. I think sometimes there's more overlap between writing good prose and writing good code than we programmers will admit. In both cases just finding the right word can be a challenging struggle.

This evening I'd planned to do some refactoring in my renderer and merge a pair of classes together. I'm happy with what I plan to call the new class but was stopped in my tracks trying to thing of a name by which the references to the instances should be propagated around. Oh well, I'd rather take a little more time to think it through and get it right.

Tidbits

2006-11-16T03:29:56Z

I suppose I really ought to actually start posting here, rather than using this account simply for lurking. So with that I'll offer a few small tidbits from the last few days.

I've been doing CS for too long...
Stopping by another grad lab today I noticed a table with a large puzzle showing map of the world. It was probably a 1500-piece puzzle at least, given the area that the border marked off relative to the size of the pieces. So what was the first thing that popped into my head? "Ooh, that looks nice"? Nope. It was "Wait a minute! The complexity of puzzles is quadratic with the number of pieces, not linear!" I was immediately horrified that the thought had even occurred.

On asserts
I was reminded again this weekend why I really ought to be using assert() in my code more. I spent some time trying to track down the cause of spurious bright pixels from one of the particularly nasty-to-code BRDFs in my renderer and found that the BRDF was fine. It was that the code for the sphere primitive which should have been returning a unit-length normal vector was returning one with length three or so. The normal was found by subtracting the sphere's center from intersection point and dividing that by the radius. This works pretty well as long as the intersection point was actually on the sphere, which you'd expect by definition. But once every now and then it snagged on some numerical instability and the computation blew up. This of course broke all sorts of downstream assumptions in my code. Normally I'm pretty at keeping track of all sorts of dependent assumptions like this but every now and then something goes wrong. Using assert() everywhere to sanity check these assumptions would have saved me a few hours. Lesson learned. I'm thinking I might go on an assert()-adding spree soon.

Copy-and-paste code checking
Copy-and-paste code is one of those programming evils that we all preach against and we all do. Yesterday I was doing some pair programming with another guy driving and he copy-and-pasted a line for one component of a vector computation and then started changing and x to y and z respectively. Except that he missed the z and made it a y too. I called him on it and he fixed it, but it got me thinking. It'd be nice if we as programmers could admit that copy-and-paste is going to happen and stop simply chastising each other for the inevitable errors. There are tools for checking other kinds of errors, so why not something to check for copy-and-paste errors? I envision a tool that would do something like a hierarchical diff on the parse tree of the source, looking for adjacent parallel structures that differ by just a few characters. When it finds them, it would look at the parts that differ to see if they form a recognizable pattern. If it sees a pattern like "x, y, z" when it's seen the "x, y, z" pattern in 99 other places it's probably okay. If it sees a pattern like "0, 1, 2" or "1, 3, 5" where there's a linear increment, then it's probably okay. But if it see something like "x, y, y" it could spit out a warning saying, "Hey, dufus, did you really mean that?" It'd be tricky to implement and would probably need a flexible system of heuristics for pattern matching, but it'd sure be nice.

pixelherder @ 2006-04-01T21:18:00

2006-04-02T04:28:48Z

YAY! A paper with my name in the credits is going to SIGGRAPH this year. All those sleepless nights and hard work has paid off! Woohoo! Not bad for my first publication in computer graphics. (I'm only author number three, but this is still an auspicious beginning.)

And among other things, this means my little avatar here will be gracing the pages of the proceedings...

Book Meme

2006-01-11T23:28:10Z

Meme from grinnellian2001:

1. Grab the nearest book.
2. Open the book to page 123.
3. Find the fifth sentence.
4. Post the text of the sentence in your journal along with these instructions.
5. Don't search around and look for the coolest book you can find. Do what's actually next to you.

"The basic idea behind graph coloring is to construct a graph representing possible candidates for allocation to a register and then to use the graph to allocate registers."

More Snarkiness

2006-01-07T07:30:39Z

I think I need to stop reading the Joel on Software forums. JoS itself has some interesting ideas that seem fairly universally applicable to all segments of software development, even if I disagree with him on some of the particulars. But some of the opinions his readers express in the forums frankly annoy me.

I guess the main thing that bothers me is that they display a willful, almost cheerful, ignorance of the value of deeper computer science than that needed to slap a web interface onto an SQL database. This being, essentially a solved problem, they see no real need for developers to get a degree in computer science since they think most of what's needed for this kind of development can be self taught. Much of CS is seen as useless in those forums. Worse, they have a low opinion of those with CS degrees and the more advanced the degree the more condecension -- the attitude seems to be that most CS professors couldn't code their way out of a paper bag in a real production environment.

Maybe I'm just defensive of my own pursuit of degrees in CS, but that's not entirely it. I have a couple of problems with their attitude. First, my experience has been that self-taught hot shots are okay but actually produce moderately crappy code. "When everything is a hammer..." and all that. Not all of CS is immediately useful, but it at least enlarges ones toolbox. I used to be one of those self-taught hot shots, and I'd be ashamed to look at some of that code now. I've also had the pleasure of meeting some CS professors who are very talented coders in the classic sense. Some of their code is just brilliantly fast -- ray tracing 1024x1024 images in software at 60fps on a desktop, for example.

The other thing is a bit of a money issue. I'm a lot happier now working on much more challenging research problems, but I still get a little jealous of how much money some of the people whose work shows up on The Daily WTF earn. (i.e. consultants billing at $200/hr) Part of me always has this reaction of "Heck, for that price, I'll do it for you properly and make a tidy little sum for myself." And then I remember that I left for grad school to get away from those messes.

Lastly, I guess it's just a bit of pride on my part and annoyance that refering to myself as a software developer or having it as a job title on my resume lumps me in the same category as them. Calling them software developers feels like it dilutes the term, and I don't really know how to succinctly distinguish my approach to software development from theirs.

I really should stop reading those two forums. But it's like watching a train wreck where you just can't look away.

Spell it out!

2005-12-19T08:46:59Z

I think I'm getting crotchety in my old age when it comes to software design. :-) As I've gotten better at it, my tolerance of certain things is lower. But there's one particular pet peeve that's been bothering me lately.

I'm taking a graduate level course in compilers next semester and in hopes of getting ahead on the project in that course, I've been reading up on it, thumbing through the textbook for the course: "Modern Compiler Implementation in Java" by Appel. It's a decent enough book on the topic, though truth be told, I prefer the Dragon book. But every time that I flip through it, I get irritate by the naming convention in the code samples. There are method names like procEntryExit3 and adj, class names like Assem, HashT and RegAlloc, and parameter names like aa, bb, cc, t, ig, etc. Even package names are abbreviated.

I really don't care whether code use BiCapitalization, camelCase, or underscores_between_words in identifier names as long as it's consistent. But please, be nice to your readers and maintainers and SPELL IT ALL OUT! The other annoying thing is that the worst offenders don't seem to comment their code well either, let alone use something like JavaDoc or Doxygen so the reader is left to rummage through the code to try to infer their cryptic interfaces.

I'll grant there was once a time when it made sense to abbreviate identifiers. Disk space and memory was at a premium, teletypes were slow and language implementations had fixed maximum limits on names. Those days are long gone. There are no browny points to be had for minimizing the characters in source code.

Typing time is no excuse either since most tools nowadays can help with that. Type a few characters, push a button and it guesses the rest of the name. Visual Studio, Eclipse and other IDEs have code completion with Alt-Space or whatever. Emacsen have dynamic expansion with M-/ and I know there's an equivalent in Vi. Any decent code editor is going to have some sort of similar feature.

It's there, so use it! People reading your code will thank you!

Bizarre Dream

2005-03-27T20:32:29Z

So last night I had a really strange dream. I usually don't remember my dreams but I slept kind of fitfully last night, and remembered this one on waking up. The strange part about this dream is that it took place on two distince levels. The lower level part of the dream seemed to be in this sort of grainy, black and white, and slightly too-quick herky-jerky style. It was a pastiche of an old serial, with a hero flying off into into space to rescue a princess from an evil villian who wanted to conquer the Earth (or something like that -- I don't remember the details). We're talking Flash Gordon-style here.

While watching this, at the bottom of the field of view of my minds eye was overlayed the black sillouhette of theater seats with Joel and the robots from MST3K watching the other level of the dream and making fun of it. I can't remember much of what they said, but I do remember that at one point the inner dream shifted abruptly (in typical dream fashion) and the three of them all went "GAH!", and then one of them, Crow, I think said something "Continuity, people, continuity!!"

I'm still not sure quite what to make of that. At least it was an entertaining dream.

printf( "Hello World!\n" );

2005-03-14T09:10:42Z

Well, here I am. After looking over my lovely wife's shoulder all this time, I've finally created my own Livejournal account. Why? We'll so that I can have a look at what's on here more easily, so that I can post the occasional comment to someone else's Livejournal, and lastly so that I have somewhere to jot down the occasional geeky flashes of insight. So to anybody that might read this, I'll mention that this journal probably won't be of much interest to non-computer-geeks. Most of it will probably be on programming and computer graphics. You have been warned. If you like, I can promise you that I'll avoid politics, though -- I hate wading through polemics on an ostensibly tech-related site just to find some small nugget of actual tech-related content.

So, a bit about myself and the username: I've always loved programming and computer graphics. So after a couple of years as a software engineer in a decidedly non-graphics field, my wonderful wife and I have moved out here so that I could return to school as C.S. PhD candidate to study computer graphics. Eventually, I'd like to work in the special effects industry or computer graphics, though I wouldn't mind avoiding California if I can help it.

Outside of graphics, functional languages such as the ML and LISP families tend to be my other major programming interests. But really, my programming interests are rather broad and I like variety. I'm perfectly happy to study computer graphics one day, assembler language listings the next day, and DBMS theory the next. To be honest, though, if it's shiny and digital, I'll probably find it interesting.

I'll also mention that I'm something of an Emacsen fan, in case you can't tell from the journal title. I probably spend more time than I should writing Emacs LISP code and tweaking my .emacs file. XEmacs on Windows XP is my prefered flavour.

Okay, I think that's enough about me.

*scratch* Buffer