Every so often I want to derive a fraction from a decimal value, such as 0.571 => 4/7. The key point is I want good approximations, not exact values. That is, I rather get 4/7 than 571/1000. I had found a tool at one point that did it, but it stopped working, so I made my own.
You seem to be sort of doing this by brute force; a non-brute-force way to do this is with Aryabhata's Pulverizer Algorithm to get a continued fraction you can then truncate to get convergents.
So 571/1000 = 0 + 1/(1 + 1/(1 + 1/(3 + 1/(47 + 1/3)))), or, in the notation that is conventional for continued fractions, [0; 1, 1, 3, 47, 3]. The truncated convergents are [0], [0; 1], [0; 1, 1], [0; 1, 1, 3], [0; 1, 1, 3, 47], and the full fraction. These convert back to rational numbers respectively as 0, 1, 1/(1 + 1/1) = 1/2, 1/(1 + 1/(1 + 1/3)) = 4/7 (your desired approximation), and 1/(1 + 1/(1 + 1/(3 + 1/47))) = 189/331. Except for 0, these are exactly the same ones your program finds, but the Pulverizer only required four divisions. (The difference in efficiency is insignificant for manually entered fractions with a modern computer, though.)
This is explained in places like HAKMEM, the Machinery's Handbook, and I think the Aryabhatiya. But I don't read Sanskrit, so I've never read the Aryabhatiya.
I always get a sense of achievement when I side-step the analysis of a problem with a stupid, straight-forward simulation script (usually probability questions).
It may burn several seconds of CPU and get me only 3 significant digits where a one-step solution exists. But I'm confident in the result because the script is near-impossible to get wrong, compared to some theory I just learned. Or a probability distribution that turns out to have conflicting definitions for what its parameters mean.
https://voces.github.io/dec2fract/