I just started using git for version control, and made some free repositories on github. I haven't tried anything beyond the very basics of creating a repository and committing and fetching code from multiple sites. I haven't made any branches or done any rebasing. For the basics, the only new concept I had to learn was the index, which I glossed over when first reading the documentation. After playing around a bit, I got a little confused, then kind of figured out what was going on, then read the documentation again, and it became clear.

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.

Looking at more Project Euler problems.

I thought problem 41 was going to be tough, but there are only 9! = 362880 nine-digit numbers to consider, and even fewer 8-digit numbers to consider, etc, so it was just a matter of checking for the first prime permutation.

Problem 42 was straightforward. I made a list of triangle numbers up to the maximum word value, then filtered the word values and counted.

For problem 43, I started by taking all multiples of 17 under 1000, filtering out any with repeated digits. Adding the 4th digit made the set 7 times bigger, but removing those that did not have the divisible by 13 property made the set about half the size. Iterate for the remaining digits.

I couldn't find a reasonable way to solve problem 44. It involves finding 4 pentagonal numbers, p_i, p_j, p_k, p_l, where p_i ≤ p_j < p_k < p_l, and p_i = p_k - p_j, and p_j + p_k = p_l, where p_i is minimized. For a given i, there's an upper bound for j, such that p_i ≥ p_j+1 - p_j, and the upper bound for j is O(i²), which means a brute-force search over i gets extremely slow. However, since I didn't have any better ideas, I searched i from 1 to about 350 or so without finding a solution, and gave up.

For problem 45, I made a list of hexagonal numbers, filtered out those that weren't pentagonal or triangle, and took the 3rd number in the resulting list, the first two being 1 and 40755. It would have been slightly slower to make a list of pentagonal or triangle numbers, and filter out those that weren't the other types.

For problem 46, I iterated over non-prime odd numbers, building up a list of primes and doubled squares less than it, stopping when none of the primes could be added to one of the doubled squares to get that number.

In problem 47, I only had to check every 4th number until one had at least 4 factors, then check the previous one, the one before that, and the one before that. If any didn't have at least 4 factors, I could jump forward 4 from that.

For problem 48, using mod 10¹⁰ arithmetic means not having to add gigantic numbers, while still getting the last 10 digits.

For problem 49, I took all the 4 digit primes and grouped the ones that were permutations of each other together, then searched each group for a qualifying triplet.

For problem 50, I found the longest prime sum starting with 2, as well as the list of primes after the last term of the sum. Then, I subtracted 2 and added the next largest prime, looking for the longest sum starting with 3, and iterating until subtracting the next smallest prime and adding enough of the next largest primes to make the sum have more terms than the current longest sum resulted in a sum more than a million.

Looking at the 4th ten Project Euler problems.

Problem 31 is a straightforward recursive count. Once you get to the 1p, the number of combinations is 1.

For problem 32, 99×99 = 9801 and 111×111 = 12321, so all the solutions have to be a two-digit number × a three-digit number resulting in a four-digit number. I did a brute-force search through all the combinations of 5 digits of the multiplicands.

Problem 33 just involved searching with 1 through 9 to see if any pair of digits had the property, so that was a small search. Also, there were only 36 pairs of digits to check.

Problem 34 is just like problem 30 with a larger bound.

For problem 35, I partitioned the primes by number of digits, then filtered out the numbers that were not the minimum of the digit rotations, which conveniently eliminated all numbers with zeros. I then filtered out the numbers for which not all of the rotated numbers were in its partition, which eliminated 11. 111, 1111, 11111, 111111 are all not prime. Then multiple the size of each partition by its number of digits, sum, add 1 for 11 gives the answer.

Problem 36 was a brute-force filter. Since leading zeros weren't allowed, even numbers could be eliminated, cutting the problem in half.

For problem 37, I built lists of n-digit primes that could be truncated from the left to n-1-digit primes, and lists of n-digit primes that could be truncated from the right to n-1-digit primes. The intersection of the left and right lists gives the 11 numbers.

From the example in problem 38, the first digit had to be a 9, so it was just a matter of searching 91..98, 912..987, 9123..9876, and 91234..98765.

For problem 39, p/3 < c < p-3, and c/2 < b < c-1. After that, I just did a brute-force search, which was kind of slow.

Problem 40 is just multiplying 7 single-digit numbers, and at least 2 of them are 1. It's straightforward to figure out those numbers, and, as it turns out, the product of those numbers is simple to mentally compute.

I wanted more immediate feedback about my Rock Band scores, so I modified the code I wrote that takes a picture of the television screen and does OCR (optical character recognition) to figure out what song was just played, and run text-to-speech with the name of the song and my high score. It works about half the time. But when it works, I get to know if I got a new high score without having to go over to the computer and check, which means I can be ready to play the next song.