(Infinite) continued fractions (CFs) are a nice trick to store and manipulate numbers in a computer that would otherwise be hard to handle (such as irrationals and transcendentals). The nice thing about them, is that you can get a correct finite prefix of the sum/product/decimal-expansion/etc of a/two CFs using only finite* prefixes of (both) operand(s). That means that, as long as you ask for only finitely many digits of the result, a prefix of the actual correct result rolls out in finite time.

* but not always. For example, it's impossible to compare two equal infinite CFs - maybe the next term will make them differ, so you have to evaluate infinity terms. This also arises in "implicit comparisons" such as subtracting two equal infinite CFs or squaring a square root of an integer that isn't a perfect square. The CF library I've been working on tries to detect those cases, but it can get confused - it's better to just avoid those cases.

So, how do you do math with them? Didn't we all learn in school that you can't really do math with CFs in a mechanical way (ie you had to reason about it to come up with an answer)? Turns out there is a way, but I guess it's rarely taught. It's a shame, it's not really all that complicated and it's a nice trick to know.

Now, on to the library I've been working on. It's not "ready", and probably full of bugs (if you find one, please let me know), but it's "ready enough" to show some neat things that you might have thought were terribly hard to do, such as evaluating ##\frac{\pi e}{\sqrt{2}}## to 500 decimals. The example program is doing just that, and you can use Mathematica/wolfram-alpha to see it's correct. Just for fun it also tries to merge successive operations, because "one operation" is really of the form ##\frac{axy+bx+cy+d}{exy+fx+gy+h}## where x and y are the inputs, a through h are set to constants that determine the operation, so a lot of stuff can be put together in one operation, such as ##\frac{x}{y} + \frac{x}{2} + 3 = \frac{xy + 2x + 6y}{2y}##, merging 4 operations into 1.

I'm not sure if this has a real use, but maybe some of the people working on custom CASes are interested in the algorithm? The paper I linked to isn't one of the easiest papers to read, but I can explain it if anyone's interested in implementing it themselves. The limitations I mentioned would be kind of bad for a CAS, but you can hack around them by using a "maximum expansion depth". I didn't implement that because I'm still looking for a better solution.