dfan

The defecating duck robot also features heavily in Thomas Pynchon's novel Mason & Dixon.

The Stockfish chess engine: https://github.com/official-stockfish/Stockfish

I learned a ridiculous amount from reading the source code to TeX (https://www.amazon.com/Computers-Typesetting-B-TeX-Program/d...) but it is written in a very 1970s style.

The other books mentioned here are also great, but I think Cat's Cradle is the best book to start with.

That's what regularization is for. You probably know that too, so pretend that was just for the benefit of the onlookers.

> which is a weakness in the theory because how can more neurons cause more problems?

In exactly the same way that adding more terms to a polynomial fit causes more problems. The is one of the most fundamental results in the theory of statistical learning in general; don't blame Deep Learning for it.

1800 is _mastering_ the basics of chess. That seems about right to me.

When I started coding for a living in the early 1990s (in an environment where efficiency was paramount), Writing Efficient Programs was gold. I still have it, and I'm glad that to see that it's still valued.

Bluffing seems like a human tactic but in fact is completely mathematically justified and is absolutely required for optimal play. A bot that bluffs will destroy a bot that doesn't.

Well, stouset is talking about chess, but in Go, Monte Carlo Tree Search plays out all the way to the end of the game; it just does so in a much less exhaustive way, for exactly the reason you mention.

DeepMind has set their sights on StarCraft II next: https://deepmind.com/blog/deepmind-and-blizzard-release-star...

Their Nature paper says "We trained the policy network p_sigma to classify positions according to expert moves played in the KGS data set. This data set contains 29.4 million positions from 160,000 games played by KGS 6 to 9 dan human players; 35.4% of the games are handicap games."

It is possible that they fed it some pro games after the Fan Hui games but before the Lee Sedol games, but that would be weird; at that point it was already learning from self-play rather than trying to match human moves.

That said, I don't think that Master's better performance comes from being trained on pro games. The AlphaGo version that played Lee Sedol played much more like a human pro than Master does.

Human moves tend to fit a narrative and be explainable, although often for very concrete reasons. For example:

"I am sketching out territory while attacking an opponent group."

"I am making my group safe so that I will not have to worry about its life while I accomplish other strategic goals."

"I am making a very strong group so that I can use it to make it harder for my opponent to accomplish anything."

Master, on the other hand, will sometimes seemingly just plop stones down in the middle of the board in a way that is hard to assign a narrative to. One can list a bunch of ways that the stone might come in handy in various futures, but it's too "vague" a move to be played with confidence by a human professional go player.

Of course, human strategies may change in response...

One thing that isn't made clear in this writeup is that Master plays in a very nonhuman style, as opposed to the version of AlphaGo that beat Lee Sedol, which mostly played like a strong human except for a few surprising moves. My first guess when I saw Master's games was that it was a program like AlphaGo that had its policy network trained from scratch rather than being bootstrapped by being given the goal of imitating the moves of strong humans. I'm eager to find out whether that was the case or whether it just moved away from human-like play during a very long self-play phase.

It really is a bit scary to see. I would not have guessed that human strategy was that deficient. Computer chess programs still tend to play with human-like strategy (partially because humans have coded their evaluation functions!) but godlike tactics. Master is not really playing like a human at all.

Yeah, when I did the Coursera course I supplemented it with the CS229 materials to get more of the theory behind everything, which worked great. If you want more math rather than less, it's the way to go.

> Apparently after graduating from university 42% of people never read another book. Ever! Now I have no idea how accurate that statistic is, but if it is anywhere near remotely close to the truth, that’s amazing.

is not really the best way to try to convince me with statistics.

I spent 5 minutes poking around the internet and nobody seems to have the actual study, just summaries of it. The closest I could find to a real discussion was at [1]. One survey with data there said that 12% of college graduates had not read a book in the last 12 months, which is very different from 42% not reading a book ever.

[1] http://skeptics.stackexchange.com/questions/9446/do-33-of-hi...

There are so many AV setups, we had to leave calibration to the user (we tried with auto-calibration but it could not always be perfect).

The fundamental problem is that there are two independent delays that both depend on your individual system: the delay from the time that the console produces a video frame to the time that the user sees it, and the delay from the time that the console produces a sound to the time that the user hears it. In a beatmatching game, you really need the user's perceptions to be in sync, which means delaying either the video or the audio. Of course, the more you delay one or the other, the more the repercussions you run into.

In a regular video game, it's not a big deal if you fire a gun and hear the shot 50ms later, but in a beatmatching game, that delay is really noticeable.

When you are making videogames, a (video) frame of latency is a big deal.

When I worked on Guitar Hero and Rock Band, we worried about sub-frame latency (timing is more important when you're hitting a drum than when you're firing a gun).

Another enthusiastic thumbs-up for A Geometry of Music. I wouldn't take all his conclusions as far as he does, but it's all very thought-provoking and he's obviously a really sharp guy. (Some prior music theory knowledge is probably necessary, if only to understand the context of his arguments.) His music's pretty good too [1].

[1] http://dmitri.tymoczko.com/scores.html

There is about a 3-stone difference between 9p and 1p, 1p is probably about 8d, and there is about a 3-stone difference between 8d and 5d. So in total 6+ stones (AlphaGo may be stronger than 9p, of course).

The version of AlphaGo that beat Fan Hui won 77% of games against the strong engine Crazy Stone giving a 4-stone handicap, even when running on a single machine. Crazy Stone has improved since then, though.

No, it would be equivalent to LeBron James going head to head with a talented amateur basketball player. Of course he would still win every time, but it would at least be a game of basketball.

Sure. Keep in mind that the top GMs have ratings of 2700 and above, while some GMs have ratings as low as the 2400s. So a top-level GM still has a large amount of age-related distance to fall before he won't be a match for a "low-level GM".

My password manager currently has 153 passwords in it. I was surprised too once it started filling up.

This article slightly overstates how disruptive the strategy is. Of course top-level Scrabble players already knew about rack management and defensive plays, and would not always just greedily play the highest-scoring word. It's more a question of finding the optimal weightings of the different elements, and the Nigerians have shown that the conventional wisdom was probably weighted too highly towards making big plays immediately.

This looks very nice. Is there any editor support yet (Emacs, vim)? Or do you currently just edit Stanza files in text mode?

I do this with chess. I take positions from tournament games in which I made a correctable mistake (generally not positions in which there was just a lot of calculation to be done and I wasn't up to the task) and add them as flashcards to my spaced repetition system.

It is true that software engineers often treat bugs as unfortunate but unavoidable noise in the system; when one pops up, you fix it and move on. But it's really worth thinking them as an inherent part of the process of software development, one which you can improve and learn from, just like anything else.

Yeah, the headline should really be "Stanford archaeologist traces the origins of authority in the Andes of Peru".

As a member of the Ultima Underworld team, I'm looking forward to seeing what Jimmy has to say about it. It's been really fun to watch him cover the stories behind the games of my youth.

Julia lets you use Unicode in your code as well, and it's great. I use Julia for math a lot and it's really nice to go straight from your equations to code with variables named α and ϵ instead of alpha and epsilon. The vim and emacs modes also make it make it easy to enter characters like this.

http://iaindunning.com/blog/julia-unicode.html (note: 2 years old)

With an equal-tempered n-tone scale, two pitches that are x units apart have a frequency ratio of 2^(x/n).

"Nice-sounding" intervals have small integer frequency ratios.

It so happens that 3/2 = 1.5 is very close to 2^(7/12) = 1.498, 4/3 = 1.333 is very close to 2^(5/12) = 1.335, and 5/4 = 1.25 is very close to 2^(4/12) = 1.260. So 12 works very well as the number of pitches to divide an octave into.

The fact that 12 is highly divisible is handy for certain aspects of music composition. For example, if you have a diminished seventh chord, which consists of every third pitch, due to its symmetry you can think of it as being in any of four different keys. So it is easy to use it to pivot from one key to another. But none of that has to do with the reasons that it sounds good.

Yes, exactly. Assuming that the error was not in the rendering system, which took the bulk of the CPU time and which was isolated as much as possible, the recording could even be replayed at high speed by omitting the rendering of most frames.

I forgot to mention that we actually found a lot of bugs by seeing a playback diverge from the original recording; this was often due to uninitialized variables or reading from random memory. We could generally see when the divergence happened because we computed a checksum of the state of the world every frame and stored it in the recording as well.