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! :-)
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.
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.
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.