Intel's Ronler Acres Plant

Silicon Forest
If the type is too small, Ctrl+ is your friend

Friday, June 8, 2018

Bugs

I've been working on my Farey addition program and I found a couple of bugs. The first one a simple mistake that took me four days to find, mostly because my mind was a bit fuzzy. The problem was that I was using abs (absolute value function for integers) instead of fabs, which is the same function, but for floating point numbers. One little letter and everything is wrong.

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.51110556526
2071 / 4052 = 0.51110562685
2117 / 4142 = 0.51110574601
The 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.
 

No comments: