[verit]

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.

https://voces.github.io/dec2fract/

[kragen]

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.

571/1000 = 0 + 1/(1000/571) = 0 + 1/(1 + 429/571).

429/571 = 1/(1 + 142/429).

142/429 = 1/(3 + 3/142).

3/142 = 1/(47 + 1/3).

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.

[Matumio]

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 still get me only 3 significant digits, when a one-step solution exists. But I'm more 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 what its parameters mean.