It's great as a learning experience for the author, but it would be a good idea for the author to take a look at a JSON spec and see if the regular expressions used by the lexer support the whole spec and don't accept non-legal JSON. From a cursory glance, it seems like exponents in floating point numbers aren't supported, nor are escaped quotation marks in strings (`\"`). I think it supports string escapes that are valid in go, but not in JSON like `\xab` and 8-hexdigit unicode escapes `\U1234abcd`.
I commented elsewhere already, but I have a blog post where I go through some examples of applications of the Kelly Criterion, including two that are related to insurance: https://blog.paulhankin.net/kellycriterion/
I have a blog-post on the Kelly Criterion, and some (I think interesting) realistic examples of its application in decision-making: https://blog.paulhankin.net/kellycriterion/
It's a bit disappointing that there's been many writeups of heuristic-based solvers make the front page, but the writeup of an exact solver doesn't make it. [Note: I was the person who submitted the link to the exact solver writeup to HN].
The (exact) optimal EV-minimizing strategies (assuming each target word is equally likely) always solve in 5 of fewer guesses in normal mode, and always solve in 6 guesses in hard mode. If you wish to guarantee 5 guesses in hard mode, there's a different (optimal) strategy with slightly higher EV. See: http://sonorouschocolate.com/notes/index.php?title=The_best_...
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.
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).
I wrote a solution to this some time back: https://github.com/paulhankin/morse-decoder . It finds the most likely sentence based on n-gram frequencies and a dictionary, and runs a relatively fast dynamic program (it's been a while since I looked at the code, but I think linear if word lengths are bounded). Word list and n-gram frequencies aren't provided in the repo, although they're easy to find online.
You can do it with just integers (ie: in Z[φ]) by noting that φ^n = φFib(n) + Fib(n-1). Equivalently, compute X^n in Z[X] / (X^2-X-1). I have an article on my blog, but it's unfortunately down right now because of some github issue with changing my account to a free one.
It looks like they got the N upside-down. The top of the N (the end with two serifs, as you can see here http://www.identifont.com/similar?TI ) is pointing to M, rather than the bottom.
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.
It would be surprising to me if a completely deterministic strategy wasn't within some very close margin of an optimal strategy. For example, if you think you should raise with JJ 1/3 of the time and call the rest of the time in some spot, then you can raise JcJd and JhJs and call with the other jacks. This can give your opponent slightly more information about your range in some cases (for example, if they hold a J themselves), and of course you can only approximate correct frequencies, but it's highly unlikely (in my opinion at least) that such a deterministic strategy would be terrible.
Significance works the other way round than you described it -- if two players were equal in skill, then a winrate of -91mbb/g or larger would happen 5-10% of the time.
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.
Go's GC has been precise for heap-allocated data since go1.1 (released 3 years ago) and precise for heap and stack-allocated data since go1.3 (released 2 years ago), completely fixing any GC problems with values that look like pointers.
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.
A phone book search does O(log N) string comparisons, but its running time is not O(log N) unless you consider all string comparisons to take a constant amount of time. Because for the names in the phone book to be distinct, the strings have to be about log N in size, so each string comparison costs O(log N) in the worst case. So the cost of phone book search is O((log N)^2).
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).
I'm the author of the blog post. You're right, it requires n^2 binary digits (and I mention this at the end of the article). The formula isn't, and isn't meant to be, a good way to find Fibonacci numbers -- it's more of a fun curiosity.
I don't think the author's interpretation of #5 to mean use smart objects (which I'll guess means objects in the object-oriented sense) is correct. I interpret Pike's meaning to be to use dumber objects that make the data visible and obvious. That's also consistent with Go's emphasis on simple datatypes.
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."