External links:
photographs on github on google+ on linkedin on twitter on youtube
Most popular tags:
ethics gnome guitar kernel linux olpc photography
I love a good photo project. Here are some favourites — feel free to suggest any that you’ve enjoyed in the comments.
Pierre Beteille’s Books/Livres:
Irina Werning’s Back To The Future and Back To The Future 2:
Natsumi Hayashi’s Levitating Girl:
Adele Enersen’s When My Baby Dreams:
Carli Davidson’s Portraits of loving pets with disabilities:
Adde Adesokan’s Triptychs of Strangers:
MIT Speed Go tournament, Jan 2012
There’s an attraction between computer programmers and the Asian game of Go. I think there’s a lot to like about the game — it has very simple rules, high complexity (it’s “deeper” than chess) and pleasing symmetry and aesthetics. I think the real reason programmers are so drawn to it might be a little more self-involved, though: being good at things that computers aren’t good at tends to make programmers happy, and computers are terrible at Go.1
Or at least, that’s the folk knowledge that’s been true for most of my life. Computers have always been worse than an average amateur with a few years of experience, and incomparably bad to true professionals of the game. Someone I was talking to brought up the ineptitude of computers at Go a few days ago, talking about new ideas for CAPTCHAs: “just make the human solve Go problems”, they said, and you’re done; computers can’t do that, right?
So, I’ve enjoyed this feeling of technological superiority to computers as much as anyone, and it hurts me a little to say this, but here I go: the idea that computers are bad at Go is not remotely true anymore. Computers are excellent at Go now. To illustrate this, there’s some history we should go into:
Back in 1997 — the year that Deep Blue beat chess world champion Garry Kasparov for the first time — Darren Cook asked Computer Go enthusiasts for predictions on when computers will get to shodan (a strong amateur level) and when they’ll beat World Champion players. John Tromp, an academic researcher and approximately shodan-level amateur, noticed the optimism of the guesses and wondered aloud whether the bets would continue to be optimistic if money were on the line, culminating in:
John Tromp: “I would happily bet that I won’t be beaten in a 10 game match before the year 2011.”
Darren Cook took the bet for $1000, and waited until 2010 before conducting the match against the “Many Faces of Go” program: Tromp won by 4 games to 0. That seemed to settle things, but the challenge was repeated last month, from January 13th-18th 2012, and things happened rather differently. This time Tromp was playing a rising star of a program named Zen19, which won first place at the Computer Go Olympiad in 2009 and 2011. The results are in, and:
Zen19 won by 3 games to 1. (For more reading on the challenge, see David Ormerod’s page or Darren Cook’s.)
Beating an amateur shodan-level player is shocking by itself — that’s my strength too, and I wasn’t expecting a computer to be able to beat me anytime soon — but that isn’t nearly the limit of Zen19’s accomplishments: its progress on the KGS Go server looks something like this:
| Year | KGS Rank |
|---|---|
| 2009 | 1-dan |
| 2010 | 3-dan |
| 2011 | 4-dan |
| 2012 | 5-dan |
To put the 5-dan rank in perspective: amongst the players who played American Go Association rated games in 2011, there were only 105 players that are 6-dan and above.2 This suggests that there are only around 100 active tournament players in the US who are significantly stronger than Zen19. I’m sure I’ll never become that strong myself.3
Being able to gain four dan-level ranks in three years is incredible, and there’s no principled reason to expect that Zen19 will stop improving — it seems to have aligned itself on a path where it just continues getting better the more CPU time you throw at it, which is very reminiscent of the story with computer chess. Even more reminiscent (and frustrating!) is the technique used to get it to 5-dan. Before I explain how it works, I’ll explain how an older Go program worked, using my favorite example: NeuroGo.
NeuroGo dates back to 1996, and has what seems like a very plausible design: it’s a hierarchical set of neural networks, containing a set of “Experts” that each get a chance to look at the board and evaluate moves. It’s also possible for an expert to override the other evaluators — for example, a “Life and Death Expert” module could work out whether there’s a way to “kill” a large group, and an “Opening Expert” could play the first moves of the game where balance and global position are most important. This seems to provide a nice balance to the tension of different priorities when considering what to play.
Zen19, on the other hand, incorporates almost no knowledge about how to make strong Go moves! It’s implemented using Monte Carlo Tree Search, as are all of the recent strong Go programs. Monte Carlo methods involve, at the most basic level, choosing between moves by generating many thousands of random games that stem from each possible move and picking the move that leads to the games where you have the highest score; you wouldn’t expect such a random technique to work for a game as deep as Go, but it does. This makes me sad because while I wasn’t foolish enough to believe that humans would always be better at Go than computers, I did think that the process of making a computer that is very good at Go might be equivalent to the process of acquiring a powerful understanding of how human cognition works; that the failure of brute-force solutions to Go would mean that we’d need a way to approximate how humans approach Go before we’d start to be able to beat strong human players reliably by implementing that same approach in silico.
Update: “bitti” comments below that Zen19 is choosing which move to play based on maximizing win probability, not maximizing score.
I think that programs like Zen19 have actually learned even less about how to play good Go than computer chess programs have learned about how to play good chess; at least the chess programs contain heuristics about how to play positionally and how to value different pieces (in the absence of overriding information like a path to checkmate that involves sacrificing them). This lack of inbuilt Go knowledge shows up in Zen19’s games — it regularly makes moves that look obviously bad, breaking proverbs about good play and stone connectivity, leaving you scratching your head at how it’s making decisions. You can read a commented version of one of its wins against Tromp at GoGameGuru, or you could even play against it yourself on KGS.
Update: Matthew Woodcraft comments below that Zen19 does contain significant domain knowledge about Go. It’s hard to know exactly how much; it’s closed-source.
Zen19 is beating extremely strong amateurs, but it hasn’t beaten professionals in games with no handicap yet. That said, now that we know that Zen19 is using Monte Carlo strategies, the reason why it seems to be getting stronger as it’s fed more CPU time is revealed: these strategies are the most obviously parallelizable algorithms out there, and for all we know this exact version of Zen19 could end up becoming World Champion if a few more orders of magnitude of CPU time were made available to it.
Which would feel like a shame, because I was really looking forward to seeing us figure out how brains work.
1: I think this is probably why I’ve never been interested in puzzles like Sudoku; I can’t escape the feeling of “I could write a Perl script that does this for me”. If I wouldn’t put up with such manual labor in my work life, why should I put up with it for fun?
2: Here is the query I used to come up with the 105 number.
3: In fact, KGS ranks are stronger than the same-numbered AGA rank, so the correct number of active players in the US who are stronger than Zen19 may be even smaller. Being stronger than US players isn’t the same as being stronger than professional players, though — there are many players that are much stronger than amateur 5-dan in Asia, because there are high-value tournaments and incentives to dedicating your life to mastering Go there that don’t exist elsewhere.
Last week I went to the first in a new series of events called “In the Dock” — Harvard Law professor Lawrence Lessig interviewed Jack Abramoff on the topic of Abramoff’s illegal lobbying in specific, and the state of corruption in US politics in general. I took some photos (CC-BY-SA 3.0), you can watch a video of the talk here, and my friend Ben Schwartz also has a write-up including some great quotes.
I went in willing to detest what Abramoff had done, and him by extension — and it’s not that I ended up liking or trusting him, or that I was unexpecting his “Look, you put a few guys in jail, it doesn’t mean the problem’s been solved and everything’s okay now” argument for why assigning a disproportionate amount of blame to him is unproductive, but he did manage to convince me that he’s uniquely placed to be an ally to help fix the system; that he’s someone who knows all of its intricacies and is sincere about achieving a sense of redemption by working on stopping other people from doing exactly what he did.
His argument for how his book tour isn’t a cynical attempt to make money is convincing, too: to the small extent that he’s able to make money from books and speaking, he’s forced to use it to repay a $40m restitution order to the government and his victims.
The most surprising thing I learned was that the crimes he went to jail for were not the particularly objectionable democracy-perverting forms of corruption that we ascribe to him — those are totally legal (even more so than before, thanks to Citizens United) and still happening today across Washington’s 30,000 lobbyists — but instead mostly unrelated charges, like mail fraud. He thinks that the only way to stop bribery in Congress is to ban political contributions from anyone who stands to benefit from public funds (which Lessig criticized as being far too ambiguous and broad: who doesn’t stand to benefit from public funds?), and to ban lawmakers and their staff from later working for lobbyists for the rest of their lives. He described how, before his downfall, he would agree to hire a lawmaker’s staffers later while they were still working for the lawmaker, and would then have control over them from that point onwards, even though no money had changed hands — not only is this movement from being congressional staff to becoming a lobbyist still legal, it’s daily routine.
I hope this talk series continues. I can’t think of many other examples of powerful figures being brave enough to open themselves up and engage in an extended ethical (rather than legal or technical) critique and cross-examination by their peers and the public, and it was powerful to watch and learn from.
(This is reposted from my Google+ stream.)
Oops, only three blog posts in the last year. I’ve mostly been posting over at Google+, wherein I met a bunch of photographers and picked up a fledgling photography obsession of my own. I’ll try to write a “what I did in the last year” blog post at some point.
This post isn’t about that, though — like last year, this year Madeleine and I are again donating N% of our joint pre-tax income to effective charities for each year that we’ve been married, and this year N is equal to 6. Mad has a post outlining why we’re doing this and which groups she’s chosen, and here’s a writeup of who I decided to donate my half of the 6% to:
40% to Schistosomiasis Control Initiative
It’s very common to think about international aid in terms of “lives saved”, but it makes more sense to talk about something like “number of disability-adjusted life years increased” (DALYs). GiveWell thinks that this charity — which concentrates on the “Neglected Tropical Diseases” which are usually worms/parasites — offers an extremely effective intervention at improving DALYs; because these infections are readily treatable using very inexpensive drugs, yet often come with debilitating symptoms that don’t quite kill the “host”.
25% to Give Directly
Give Directly is a fascinating project. The charity simply finds the poorest people in an area (currently they’re working in Kenya) and transfers money to them via mobile phone. This leaves the charity itself with very little overhead — all the charity has to do is identify who the poorest people are, which they often do by looking at what kind of place they live in. The claim is that this outperforms many other attempts at aid; there’s nowhere for the effect of the money to get diluted or misappropriated along the way.
I should be clear that I don’t think this is the best possible aid intervention. But, as GiveWell points out, it should be the intervention that we treat as the baseline that other interventions are measured against — if you think you have a better idea, then you should be able to prove it by comparing outcomes against this method. Give Directly has a commitment to measuring the quantitative effects of its work; I want to support finding out how well this intervention works, even though the optimist in me hopes we can do much better!
15% to GiveWell
GiveWell has dramatically changed how I think about and evaluate charitable giving. This year I’ve been pleased to see them doing things like exposing errors in commonly referenced DALY calculations, and generally acting as the quantitative sanity-checker for development charities.
15% to the Tor Project
Tor is a technology that helps its users achieve anonymous access to the Internet over a connection that may be being monitored; as a side-effect of this, it allows its users to get around filtering of their connections. I think this pairs up nicely with Madeleine’s choice of donating to the Wikimedia Foundation — it’s important to have the world’s knowledge available to everyone, not just the people who are lucky enough to have an unfiltered and unmonitored connection. I increased my donation to Tor this year after seeing how effective the Internet has been as a pro-democracy tool this year, and how many regimes tried to filter communication using it when it was being used by citizens to coordinate with each other.
5% to the EFF
While Tor works on “exporting” the Internet that we use to regimes that wish to block or filter it, the EFF is helping to keep the network itself safe from becoming controlled by groups like governments or media companies; attempting to preserve the freedoms that the net provides today.
As Scott’s preview post explained, today was “Narrative Interfaces” day at OLPC — the general motivation for this work is that the current Sugar interface leaves you able to do lots of different activities with your XO laptop, but doesn’t have any strong opinions about which you *should* do, or which order you should do them in. Wouldn’t it be better if we could come up with a plot/narrative behind the activities that can be explored on an XO?
I’ve uploaded videos of the talks now. They are:
In the discussion afterwards we chatted about comics that do a good job of presenting non-fiction, as an alternative way of using narrative to present ideas — here’s our reading list:
If you’d prefer to download the videos directly, you can find the raw files here.
Thanks to everyone who participated! If you weren’t able to attend in person but have comments after watching the videos, feel free to jump in with your thoughts on the Sugar Labs IAEP list.
I’m home from the EduJam conference in Montevideo, Uruguay — huge thanks to the organizers for a fun and productive event with around 80 Sugar and OLPC community members. We also got to spend some days before the conference visiting school deployments in Uruguay and asking about how they’re using their XOs (Uruguay is the first country to have implemented One Laptop Per Child for each of its children!), what they enjoy, and what they’re frustrated by.
I recorded video in the talks I attended, and collected video from people who recorded talks I didn’t, and have started to upload them to the Dailymotion Sugarlabs account. Here’s what I’ve got so far, and I’ll keep adding to the list as I collect more:
(Please let me know in the comments if there are problems with any of the videos. Thanks to Bert Freudenberg for help with encoding them.)
Well, that was unexpected — the Mystery Hunt team I’ve hunted with for the past three years, Codex, won the hunt this year! It’s the team’s tenth year of competing and our first win. Congrats to everyone! Here’s a Boston Globe article about the whole thing.
The hunt organizers did a beautiful job putting together the hunt (it took an estimated 20,000 person-hours), and the laser-etched “coin” we won the hunt by finding at 6am on Sunday morning was a reflection of how much effort had gone into the hunt in general:
The coin!
Of course, this means that now it’s our turn to write the hunt — as Scott says, our free time for the next year has just vanished. It’ll be fun, though; it’s always sad when the hunt ends and you realize you aren’t going to get to hang out with the awesome people you just spent a sleepless weekend solving puzzles with until next year, but having to meet up regularly to write and test the puzzles for next year will fix that. We’ve got a very high bar to live up to, and a thirty-year-old tradition to keep alive.
(Oh, yeah, geekiest moment of the hunt: one of the puzzles — Redundant Obsolescence — involved plugging an Iomega Zip drive into my desktop PC via parallel port and reading files back off it, in Linux. I couldn’t believe it worked.)
While I’m here and blogging, here’s a guitar video I recorded over Christmas. I’m happy I finally got to record a Kaki King piece.
Kaki King – Goby (youtube, download in Ogg Theora)
It’s easy to find a multitude of things to be thankful for, and I like that the US has a holiday for reflecting on how lucky we’ve been. Today we’ve been hanging out with friends and cooking up a vegetarian/vegan feast, including a tofurducken:
Mad and I had our five-year wedding anniversary last month; last year we decided to donate N% of our joint gross yearly income to effective charities each year for our anniversary, where N is the number of years we’ve been married, so we’re up to 5% this year. We decided to publish the list of charities we’ve chosen, both to show which charities we like donating to and to encourage others to consider doing something similar. My choices this year are:
Oxfam has an excellent reputation for fighting poverty in developing countries.
Givewell is a non-profit attempting to apply quantitative rigor to measuring how effective charities are, and VillageReach is in their #1 spot; they’ve proven themselves reliably able to save the lives of infants for under $1000 per child.
PSI works on global health, including HIV/AIDS, malaria and family planning.
The Fistula Foundation and ReSurge (formerly Interplast) treat health problems that we don’t see much of ourselves because they’re far more common in the developing world — a fistula operation, for example, is clearly life-transforming, and can be funded for $450.
The EFF and Tor Project fall under the banner of helping people to use technology to demand better government and uncensored access to information.
I took over maintaining the Linux kernel’s MMC/SD/SDIO subsystem recently, and quickly found that I was spending too much time saving, applying and compile-testing submitted patches (and trying to remember which of these I’d done for a given patch). The following Emacs/Gnus function helps with that — with a single keypress when looking at a mail that contains a patch, it applies the patch to my git tree, runs the kernel’s “checkpatch” tool to check for common errors, and kicks off a compile test in the background. I’m not much of an elisp coder, so feel free to critique it if you can.
(defun apply-mmc-patch () "Take a gnus patch: apply; compile-test; checkpatch." (interactive) (setq default-directory "/home/cjb/git/mmc/") (setq compilation-directory "/home/cjb/git/mmc/") ; First, apply the patch. (dvc-gnus-article-apply-patch 2) ; Run 'git format-patch', and save the filename. (let ((patchfile (dvc-run-dvc-sync 'xgit (delq nil (list "format-patch" "-k" "-1")) :finished 'dvc-output-buffer-handler))) ; Compile the result. (compile "make modules") ; Now run checkpatch. (let ((exit-code (call-process "perl" nil nil nil "scripts/checkpatch.pl" patchfile))) (if (eq exit-code 0) (message "Checkpatch: OK") (message "Checkpatch: Failed"))))) (define-key gnus-summary-mode-map "A" 'apply-mmc-patch)
First, some background: KDB (a kernel debugger shell) and KMS (kernel mode-setting) combine to let you drop into a graphical shell when something debugger-worthy happens on your Linux machine. That thing might be a panic, or a breakpoint, or a hardware trap, or a manual entry into the kdb shell. Inside the shell you can, for example: get a backtrace, inspect dmesg or ps, look at memory contents, and kill tasks.
This is a big improvement over the previous model of “something bad happens to your laptop while it’s in X, and the keyboard LEDs start blinking, and you hard-reboot and wonder what happened and wish your laptop had a serial port”.
Here’s a video of KDB+KMS in action — it’s from Jason Wessel at Wind River, who deserves massive kudos for having enough patience to get all of this debugging code merged into mainline Linux to everyone’s satisfaction:
Jesse recently wrote about how to give KDB+KMS a spin on Intel graphics chipsets, and now I’ve written patches that allow radeon and nouveau users to join in too. The method for testing them is similar to Jesse’s:
git clone git://dev.laptop.org/users/cjb/linux-2.6
cd linux-2.6git checkout kgdb-nextkgdboc=kms,kbd kernel arguments.echo g > /proc/sysrq-trigger, and type go to leave KDB.If you test with radeon or nouveau, please let me know what hardware you tested on, and whether everything worked. Thanks!