71 karma · joined July 6, 2014
I don't think a maximum-number-of-guesses optimizer leads to an equilibrium (if you mean Nash equilibrium), assuming you're playing the game where the score of the game for the setter is the number of guesses. In particular, if the solver's strategy is deterministic, the setter will always pick one of the words that needs 5 guesses. There's no reason to think the nash equilibrium can be easily found.
They are fun in the same way as TIS-100 is fun, and especially the last couple (generate primes, sort input) are interestingly difficult.
Instructions and description of the machine on wikipedia: https://en.wikipedia.org/wiki/Little_man_computer
Online emulator: https://blog.paulhankin.net/lmc/lmc.html
[note: the blog post contains some minor hints, and solutions in links]
I don't think everyone should read it, because it's quite technical. There's articles on mathematics, game-theory, and computer science.
The highlight (in my opinion) is a series of articles on Fibonacci numbers, with relatively novel content: https://blog.paulhankin.net/fibonacci/, https://blog.paulhankin.net/fibonacci2/, https://blog.paulhankin.net/fibonacci_doubling/
The first two in particular, are quite fun I think, playing with short integer-only computation of the Fibonacci numbers (and also the n-acci numbers).
It's not a game, but I found it fun to write simple programs; the machine code is so limited you need to find tricks to do anything non-trivial. For a challenge, try to write 1: a program that multiples two inputs, 2: a sieve of erastothenes, and 3: a program that can sort input.
The spec for the assembler is on the wikipedia page.
I don't know if Doug Polk understands that or not, but I agree with his criticism and I think his analogy with sports reporting is sound. While "statistical tie" is true in a technical sense, it's not usually how matches are reported, and it's somewhat disingenuous and self-serving to use that language. It would be more honest to say that it's very unlikely that bot is better than humans -- given the advantages the bot had (a gruelling 2-week schedule, and pressure on the humans to get through N hands per day) it still lost by a significant margin.
I agree that the statement about avoiding large numbers was farcical, but it was not made by "Golang" but rather by someone on the go-nuts mailing list. Your sentence makes it sound like this was general advice for people programming in go from the go team, but to the best of my knowledge this is not true.
Under this assumption, a correctly implemented quicksort also runs in O(N) time.
I've skipped some details here: string comparisons can finish early, and maybe N should be the size of the phone book rather than the number of names in the phone book -- but even if you consider these factors, the runtime complexity is still more than O(log N).
It's very close (in my opinion) to a restatement of Brook's quote "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."