This is an update to an old node by esteemed monk tilly.

Say you have a decimal number like 0.421875 and you want to print it as a fraction. Now, "obviously", that's equal to 27/64, but how do you write a program to find that out? The best way is with the method of continued fractions, and the surprise is that it's *dead simple*. This program produces a sequence of fractions that are increasingly good approximations of the input number.

`use Math::BigInt;
use Math::BigRat;
die 'number required' unless @ARGV == 1;
my $x = my $y = Math::BigRat->new($ARGV[0])->babs();
my $h = my $k1 = Math::BigInt->new(1);
my $k = my $h1 = Math::BigInt->new(0);
while (1) {
my $t = $y->as_int();
($h, $h1) = ($t * $h + $h1, $h);
($k, $k1) = ($t * $k + $k1, $k);
my $val = Math::BigRat->new($h, $k);
my $err = $val - $x;
printf "%s: %s / %s = %.16g (%.1g)\n", $t, $h, $k, $val, $err;
$y -= $t or last;
$y = 1 / $y;
}
__END__
0: 0 / 1 = 0 (-0.4)
2: 1 / 2 = 0.5 (0.08)
2: 2 / 5 = 0.4 (-0.02)
1: 3 / 7 = 0.4285714285714285 (0.007)
2: 8 / 19 = 0.4210526315789473 (-0.0008)
3: 27 / 64 = 0.421875 (0)
`

Clearly, this code is much simpler than before. What's not obvious is that it always terminates with `$h/$k` exactly equal to `$x`. In practice, you probably want to stop the loop early, perhaps when `$err` is small enough or `$k` gets too big.

This algorithm can even tackle really obnoxious inputs like 0.49420098210293 (463051/936969).

You can do away with `BigInt` and `BigRat` and use ordinary numbers, but then the loop is no longer guaranteed to terminate. To be safe, maybe put in a limit on the maximum number of iterations.

The first number on each line, `$t`, is a term in the continued fraction representation. You can mostly ignore it, but it has some interesting mathematical properties. For example, if you set `$x` to sqrt(2), all terms after the first should be 2, but only the first 18 are correct because of round-off.

Comment ondecimal to fractionDownloadCode