indessed roscivs

This has to be the very nerdiest thing I’ve seen in a long, long time.

Remember the Erector set? A bunch of metal pieces with nuts and bolts to stick’em together, and a little battery-powered motor to make the toy crane or train or whatever actually move?

Well, there’s a company called 80/20 that makes what they call an “Industrial Erector Set”: the same fundamental principle as the Erector set of yesterday—simple individual parts that can be combined in many different ways—but taken to the “industrial” level. The devices made from parts they provide can actually be used in production environments to do real things—they’re not just toys for kids to play with.

So, this company, using their “industrial” erector set parts, put together a device of sorts that could manipulate a Rock Band guitar. As if this wasn’t geeky enough, they then hooked up a camera and a computer to this device. The camera watches the screen, as a human would, detects the symbols that mean a button on the guitar should be pressed, and then sends synchronized signals to the guitar-bot that will play Rock Band (near) perfectly.

Truly, this is a triumph of amazingly geeky proportions.

Today, I finished up enough to make a first release of my tsumego program. Thankfully, the web site I mentioned last week is back up and running, so hopefully this week I’ll get enough time to package everything together, make a post about it, and start getting some feedback. I finished the problem serialization (which was most of the work), then added some problem de-duping, and fixed up the statistics placeholders. Everything now seems to be working just fine.

Fortunately, all the quiz work I’ve been doing will carry over quite nicely to the old Japanese quiz program project. Somebody actually emailed me this week saying that they really like the program, and sent me a patch for a minor bug it had. They also asked me if I could add more kanji, so I’ll probably start working on that next. I’ve been trying to get rid of the nasty, nasty flat-file format underneath everything, and today I managed to finish up the last bit of refactoring that gets rid of any direct dependencies on that flat-file format. Now I have a solid API that I can write my database code against, and once I have that API completed, the flat-file code can disappear forever.

Speaking of kanji, I originally wrote the program to study for the JLPT—the Japanese Language Proficiency Test—and I just got an email from the test organizers saying that they’ve sent my admission voucher in the mail, and I should be getting it shortly. The test is on the first Sunday of December every year—if my calculations are correct, that puts it at four weeks from today. I’m excited! I’m only taking the very easiest level (JLPT 4), but it’s not a trivial test to pass. I’ll have to study hard!

My tsumego quiz program is coming along nicely. I have a database of half a dozen or so problem trees, making a little over a hundred individual tsumego problems. The GUI is more or less complete, and the Leitner engine from my Japanese quiz program has been separated into its own module and successfully integrated with this new program.

There’s still plenty to do, though, even before a first release. I haven’t come up with a good way of serializing the problems to disk, so progress can’t be saved yet. I’m also not doing any sort of de-duping in the problem trees, so sometimes the same problem shows up multiple times, even though it should really only appear once. And there are some statistics that I’d like to show, but currently just have placeholders for.

Unfortunately, the web site I typically post on and read for all my Go-related needs has been out of commission for nearly a week now. Maybe that means I can get an initial release ready before the web site comes back—but much of my motivation for Go-related endeavors comes from that site, so without that source of inspiration, who knows how long I’ll have before the fickle winds change and I’m blown to a different, newly-exciting project.

I suddenly switched to a new project. (Ever wonder why none of my projects ever get “finished”? I have project ADD.) Now I’m working on another quiz program. (I’ll be re-using bits of the Leitner method system I described in earlier posts.) This quiz program is for Go, though.

One of the most common ways to study Go is to look at “tsumego”, or “life and death problems”. Given some board position, the student has to determine what move to play in order to capture (kill) a group of stones, or prevent its capture (make it live). These problems can start out simple, so that any beginner can understand them, and end up heinously complex such that even a pro player would have difficulty discerning the answer.

My program is intended to help practice these “life and death” shapes in an incremental way, by memorizing simple shapes first, then memorizing what moves lead to those simple shapes, then memorizing more and more moves incrementally until one can simply see, at a glance, the correct move.

I’ve actually been spending more time working on my projects lately than writing about them, yay! I promise I’ll try to write more often, though. (At least if life settles down a bit.)

I’ve been working lately on implementing the “end-game protocol” for my Go server. The game of Go is a little odd in that there’s no concrete point at which the game is over. The object is to surround territory on the board, and when a player feels that all the territory on the board is solidly captured and well-defended, he simply passes. If both players pass, then the game is considered over.

After both players pass, there will likely be left on the board stones that could have been captured throughout the course of the game. The players will typically recognize that these stones are, in fact, “dead,” and remove them after passing but before counting the score.

It turns out to be rather difficult for a computer program to figure out which stones are “dead,” so servers where computer programs typically play don’t have any mechanism for removing dead stones from the board, since that would make things more complicated. The programs just tediously spend the time capturing all the stones, one by one, until all “dead” stones have actually been removed from the board through play.

This would be outrageously boring for human players to do. In fact, I don’t know of a single server for humans that requires them to capture all stones manually, like servers for computer programs do. (I think one of the Facebook Go apps did originally, but hardly anyone used it until they added a “mark stones dead” feature.)

Normal Go servers just have the players click on the dead stones to remove them from the board. Human players almost always agree on which stones are dead, but on the rare occasion when they disagree, most Go servers don’t have any way to deal with this. On KGS (one of the most common Go servers in the US), the players will typically ask a stronger player for help resolving the issue. The stronger player will take one glance at the situation, and tell the players whether the stones are, in fact, capturable.

This tactic works for human-versus-human matches, but obviously it is more difficult when there is a computer involved. How do you “convince” a computer that it’s wrong about the status of some troublesome stones?

For my server, I wanted it to work well for both human and computer program matches, so I had to devise a way to resolve disputes about dead stones. I ended up implementing a very simple approach—if after two passes, the players disagree, then play continues. If both players pass again, then all disputed stones are considered alive. This gives the player who thinks they’re dead incentive to actually capture the stones through play. If he cannot do so, then he will have to pass and the game will be over.

I now have this end-game protocol implemented and working well. Although it’s not going across the REST server yet, I’m able to play against GnuGo and successfully resolve games where we “disagree” about the status. The client still needs a bit of cleaning up, but the concepts are sound and the functionality is there.

A few months ago, we were talking at work about what it means to be “truly rich” (in a financial sense). I realized then that there are many, many different perspectives on what it means to be rich, or what it means to be poor.

My coworker’s definition was as follows: if, when purchasing a plane ticket, you always get a first class ticket—in fact, it doesn’t even cross your mind not to—there’s no weighing of the pros and cons or considering the extra cost. That was his definition of what it meant to be truly wealthy. None of us were “rich” under that definition. None of our bosses were, or our bosses’ bosses. Possibly their bosses, who are senior level at the company, might qualify, we theorized.

This was worlds away from what my definition had always been. In fact, it struck me how different a perpective I held from most of my peers. For me, “truly rich” was the point at which you could buy food without thinking about the cost. You could go grocery shopping whenever it was convenient during the month—you didn’t have to wait until the paycheck cleared or to check to make sure there was enough money in your accounts. You bought food based on nutritional value or your particular tastes—you weren’t checking the prices, trying to find the best value so you could make sure to have enough food to last through the month.

Such a stark contrast between the two. Such a humbling reminder of the tremendous wealth inequality, even just here in America.

What’s your definition of “truly wealthy”? At what point would you consider yourself “truly rich”? And has that definition changed over time?

The project I’m working on at the moment is an open-source, open-protocol Go server. Basically, that means that anybody could write a program to connect to this server to play Go. At the moment, most servers don’t allow this—you have to use their program to connect, and if there are features you want that their program doesn’t have, you’re out of luck.

It’s a bit strange testing this server, however, because I’m not actually writing my own program to connect to it. Instead, I’m using somebody else’s program that speaks a different protocol (the “Go Text Protocol”), and writing a thin wrapper that translates GTP to my server’s protocol.

In the end, it seems really odd, because in essence I’m writing an extra bit of logic between two programs—that, by themselves, could talk to each other just fine—just to add my new server in between and make sure it works fine. In the end, of course, this will be great because other programs that couldn’t normally talk to each other will be able to because of my server. But in the meantime, it’s more than a little strange to be looking at these odd conversions back and forth that seemingly could be all stripped away without any change in behavior.

Life has been busy lately, but I thought I’d drop in with a quick update and let you all know how life is going.

The Dow continues to drop. Work continues to be busy. Pneumonia continues to lurk around our house. The normal hockey season has officially started. Metric Thanksgiving is on Monday. I did the laundry and the dishes but the house is still a mess. I’m taking a Japanese class on Tuesdays that is totally fun. When I watch Hikaru I understand a surprising lot of the Japanese. We had less than two weeks of autumn—it went straight from summer to winter with hardly a breath in between. I’m posting this from a MacBook. And now it’s time for bed.

It’s been a while since I’ve done the typical “project update” post that was supposed to be the heartbeat of my revived blog. I guess part of that is because I haven’t actually done much with my projects lately. Things have been so busy and hectic at work that, for the first time in a long time, when I get home at the end of the day I want to do something besides more programming. (Fortunately, as I noted in my last post, hockey season is coming up.)

Meanwhile, I did discover a cool program called f-spot, which is a Linux photo-managing application (much like iPhoto or Picasa). It allows you to sift through dozens of photos fairly easily, tag them, and export them to Flickr and other such programs. I’ll have to see if it fulfills my needs well enough that I can resume cataloguing and organizing my enormous photo collection, but at the moment it looks promising. Apparently it even has Wordpress integration.

This weekend marks the 2008 NHL Premiere—four regular-season games played in Prague and Stockholm to celebrate the National Hockey League both here and abroad. So far the games have been exciting, and I’m more ready than ever for the rest of the season to start this coming Thursday.

Every year, teams change—people leave old teams, people join new teams, old stars retire, new stars appear—there’s always something different. It’s strange for me to see Jarkko Ruutu playing for Ottawa, especially in these first games against his old team, the Pittsburgh Penguins. He was always such a staple on that team that it’s strange to see him skating a different direction on the ice.

But the most surprising change for me this season is that Roberto Luongo has become the first goalie to be named the team’s captain in the modern NHL. In fact, it’s actually technically against NHL rules for the goalie to be the captain! So Luongo won’t have a “C” stitched to his jersey, in order to comply with the official rules, but in all other ways he’ll be considered the leader of Vancouver Canucks.

Congratulations, Luongo! You deserve it.