Got that corrected and now I'm running the program and when the denominator gets to 4142 it goes off the rails. What the heck could be causing that? It's been working fine for the first 4141 denominators, why should it choke on 4142? It blows up when it is checking the Farey addition. Doing this only involves integer operations, and they are all relatively small integers, we aren't going to overflow the accumulator. What could possibly be go wrong? This one had me stymied for a couple of days, I couldn't even think of what to look at. There is nothing wrong except it doesn't work.
This morning my brain served up a clue. When I generate the fractions, I compute their decimal value and use that to sort my list of fractions. The problem is that I also depend on this value being unique. If two fractions have the same decimal value, I presume they are duplicates and eliminate one. The problem might be (I haven't verified it yet) is that two fractions could have the same decimal value, but be different. For instance, Google delivers these values:
2048 / 4007 = 0.51110556526The first 6 digits of these three fractions are all the same. After that they diverge. In my debug output, they all show the same value, but then I am only printing the first six digits. Standard floating point values hold much more than six digits, so maybe there is something else going on here. Anyway, I've got a place to start looking which is more than I had a couple of days ago.
2071 / 4052 = 0.51110562685
2117 / 4142 = 0.51110574601
No comments:
Post a Comment