More Project Euler problems.

For problem 51, I only had to try replacing the 0s, 1s and 2s, since there had to be 8 values in the family. And I didn't have to try replacing 1s with 0s or 2s with 1s or 0s, since those would be redundant.

I just did a brute force search from 1 on up for problem 52. It would be more complicated and maybe faster to skip numbers where the most significant digit is not 1, but the answer wasn't all that big, so it wouldn't be significantly faster, if at all.

For problem 53, since ⁿC₀ = ⁿC_n = 1, and C increases rapidly from the edges and peaks at the middle, I counted the values under a million for 0 ≤ r ≤ n/2, doubled it and subtracted.

For problem 54, using Haskell's deriving (Ord) with an appropriate data structure and mapping the card values to values that ordered the ace, face cards, and ten correctly made it simple. Also, there were no instances of A 2 3 4 5 in the data, which, if considered a straight, would have had to have a special-case constructor to be ordered correctly.

I just brute-forced problem 55 over the range 1..9999.

For problem 56, the upper bound for the sum of digits is 9b log₁₀a, and log₁₀a < 2, so the upper bound is 18b. So the maximum value for b = 99 establishes a lower bound for b that needs to be searched. Subsequent new maximums for b < 99 can raise that lower bound. I wound up searching 1 ≤ a ≤ 99 for 54 ≤ b ≤ 99.

For problem 57, I found that doing head (show numerator) < head (show denominator) was faster than counting all the digits, as it's known that numerator/denominator is approximately 1.4.

For problem 58, I just did a brute force iteration over each square, with running counts of the total and the number of primes.

For problem 59, I printed out every 3rd character decoded with each of the 26 possible key characters, and then visually chose each of the 3 characters in the key.

For problem 60, I could only come up with a super slow solution, though it did come up with the answer in about 10 minutes, and ruled out other possible answers after 30 more minutes. I made a very wide, shallow tree, spitting out results when reaching a depth of 5. I had to do a bunch of redundant calculations, because although I had a branch starting with 3,7,109,... I still needed branches starting with 3,..., 3,7,..., 3,109,..., 7,..., 7,109,..., 109,.... I'm thinking that a graph-based algorithm, instead of a tree-based algorithm would be faster, should I revisit this problem.