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.
Surely "decoding" means returning the text that was encoded. You can't trivially decode it, you can provide a candidate solution, that's entirely different; the point of sharing this was it's not possible to decode because there's no unique solution.
...---...
you can guess it's EEETTTEEE, but the decoding is SOS, that was the plaintext I started with.
SOS is an interesting case, because it is a Morse "prosign", which means it is sent as one continuous stream of dits and dahs without any pauses between the letters we use to represent it.
In other words, SOS is sent exactly the way you wrote it, as if it were one long character:
...---...
It is not sent as three separate letters like this:
... --- ...
To indicate this special treatment, prosigns are normally typeset with a bar over the connected letters, something like this:
___
SOS
(I used underscores above the letters here; if they render as separate underscores, imagine that they all run together.)
Yes, and even a simple string like "...---..." has 200 possible solutions, including "VTTIE", "3NI", and "SMB". Especially for longer inputs, there's no way to guess which one is right.
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.
