MathJax

Monday, February 24, 2014

If man were meant to fly...

...he'd have been born with wings.
adventure.howstuffworks.com
...he'd have been born into a world that needs shrinking...
clearsimpleliving.com
...he'd have been born with a need to explore...
blog.getsholidays.com
...he'd have been born with curiosity...
kidspot.com.au
...he'd have been born with intellect...
wrightbrothers.org
...he'd have been born with drive...
pedalpowerplanes.co.uk
...he'd have been born annoyed with the notion of the impossible...
upload.wikimedia.org
...and he'd have been born with dreams.
redbubble.net

Monday, February 17, 2014

It's Go time.

It's no secret that I love chess. Now for the bad news: most chess games I play in-person do very little to help my brain. I'm sure this would quickly change if I signed up for some weekend tournaments, and this isn't always the case in my online play, but the truth is the lazy side of my brain is good enough to convincingly dismantle all but a few people I've met in non-chess-oriented settings.




So what are my options? I'd like to continue growing my ability to learn via games, but I'd like to get some more normal human interaction back into the mix. Playing a variety of German-style board games is one approach, but there is a (low) chance of developing metagaming heuristics effective enough to wind up in a similar situation with German board games as I currently have with chess.[1] It would limit my play to the friends I normally board game with and other board game nerds. Like I said, it's a low chance, but why not protect against this risk via portfolio diversification?

What I need is a game with a deep heuristics ladder that's also withstood centuries (if not millennia) of scrutiny. What drew me to chess was its lack of overt random elements[2], its freedom from politics as a 2-player game, and that it is a game of perfect information[3]. There's at least one other game that fits all of these criteria, plus I'm new to and therefore terrible at: Go.

I have no idea what's going on here, and I can't wait for that to change!
I'd like to commemorate my newfound enthusiasm for Go with a continued comparison against Chess. Since we've covered that both are are two-player turn-based strategy games of perfect information with deep heuristic ladders and no overt random elements that have withstood the test of time, let's go into some differences.

  • Chess has much more complex rules. There are six types of pieces, pawns move three different ways, certain material configurations are drawn by insufficient material, castling and its relationship to check and which pieces have moved is complex, and a large number of casual players don't know that en passant pawn captures exist.
  • In spite of simpler rules, Go has a much, much higher branching factor.[4] I see this partially as cheating by increasing the board size (19x19 vs. 8x8), but I'm over that.
  • The conceit of chess is much more amenable to suggesting state and directional heuristics to novice players: You want your King to live, a larger army will help capture the opponent's King, pieces have a sense of individuality and purpose both with and without the surrounding army. There's none of that in Go. The first few games of Go are a difficult process of discovery in transforming the basic set of rules and enormous branching factor into something that is within the limits of the human mind to evaluate.
  • Computers are terrible at Go. The anti-computer tactics employed by humans in Chess involve pushing games in the direction of favoring intuition over direct ply-by-ply calculation, which is Go's default setting.
  • Go is scored at the end. Chess is either a victory for one side or a draw.
  • Go's scoring mechanism and monotony of piece types allowed the creation of a simple handicap system to enable games between players of vastly different strength which are mutually useful intellectually. 
  • Philosophically, it's easy to imagine yourself as the King in a game of chess. If he's captured, you lose. It's a fight to the death, and you're right there in the middle. Go doesn't have that. You aren't any of the stones, and neither is your opponent. You play the role not of kings or battlefield commanders, but of emperor-gods hovering above a field of mortals.
  • If we insist on anthropomorphizing game pieces, Go may reflect a belief in the supremacy of groups over individual differences. Chess reflects the opposite.
  • While both games appreciate the role of forcing the opponent to respond (the Initiative in chess, Sente in go), chess's initiative is very all-or-nothing. You have it or you don't, and when you do then it's a mistake not to press it into something greater. Sente in go can be sort of "stacked," it seems, and much more difficult to put one's finger on. Whether a move in go forces an opponent to respond is harder to calculate directly, leading to more right-brained judgment calls. You see these sorts of judgment calls in chess as well (e.g. realizing an opponent's threat is a "ghost"), but it seems like a much more fundamental concept in go.
  • Similarly, developing one's pieces at the start of a chess game has a slightly different character than a ko threat in go. Areas of the board you judge as "dead" in go can still be useful as a ko threat later in the game, whereas lost material in chess will not rematerialize.
  • Go seems much more forgiving to beginners in the earlier stages of a game. Having so many more moves to choose from, there are more viable moves than you would see in chess. Many bad moves beginners make in chess have simple explanations for the nature of the error and a conclusive demonstration of why such moves are mistakes. Mistakes in any phase of a chess game can kill you. In go there is more equality between the viability of different moves absent Sente, and failing to immediately press Sente isn't a mistake the way fumbling the initiative is in intermediate+ chess games.
  • Threats in go are inaccessible before absorbing via literacy and drills several heuristics about living and dead structures and probably a few more things that I haven't learned yet, hence my poor go strength.
Come to think of it, the depth of go's heuristics ladder may be counterproductive to my interest in it. There are fewer go players than chess players that I have met in my life, so absorbing a handful of heuristics puts me at a great advantage much sooner. Wait a minute, that's what that handicap mechanism is for! This is going to be fun.





[1] This would most likely take the form of recognizing the essential games embedded in the rules of more recent board games and quickly discovering effective state and directional heuristics by combining effective strategies

[2] i.e. no dice, no cards. See Characteristics of Games.

[3] All information about the state of the game is known to both players; there's nothing like a private hand of cards.

[4] average number of options available to a player in a typical game state

Monday, February 10, 2014

Reusability is not a design goal

http://xkcd.com/974/

When software reusability is a stated goal of a software system, it encourages fitting your customers' problem to your solution's implementation rather than the other way around.

Reuse viewed as an intrinsic good encourages design missteps such as favoring inheritance over composition, resulting in tight-coupling issues.

Finally, reuse as its own goal violates YAGNI (You Aren't Going to Need It). See this great Coding Horror article, which really steals a bunch of my thunder.

Reuse has its place. Reuse occurs while following a more powerful design principle: Don't Repeat Yourself (DRY). Each piece of information in and about a system should have exactly one canonical location. Well-designed systems thus reuse their own components in the service of DRY, but what we should emulate in designing our own systems is not the reuse but the single encoding of each idea in a system.

"Okay, Mr. Smarty-Pants: Doesn't the existence and widespread use of software libraries contradict the entire point of this article? Haven't you heard of Ruby on Rails? Spring? Java? .NET?"

These are products for use by software developers (e.g. the Java Collections library). Within effective software libraries, reuse is still incidental to the more powerful DRY principle. Libraries are still designed to serve an end. Reuse comes naturally when common instances of a problem occur via DRY, not via the inherent goodness of reuse.