Egyptian fraction calculator

It uses the greedy Fibonacci–Sylvester algorithm, which is guaranteed to terminate and always yields different denominators. Send two positive integers, receive the expansion, the number of terms and the whole part when the fraction is improper. The same code runs free in your browser on this page and costs $0.002 per request when you call the API.

What an Egyptian fraction is and why it still matters

Ancient Egyptian mathematics avoided general fractions almost entirely. Instead of writing 3/4, a scribe would record 1/2 + 1/4: a sum of unit fractions, each with numerator one and all denominators distinct. The Rhind papyrus opens with a long table doing exactly this for fractions of the form 2/n, because tables of unit fraction expansions were the everyday calculation tool of the time. Today the idea is more than a curiosity. Unit fraction expansions appear in number theory, in fair division problems, in teaching about fraction equivalence, and in recreational mathematics. The egyptian fraction calculator reproduces that decomposition instantly for any positive rational you give it. You supply a numerator and a denominator, both positive integers, and the endpoint returns the list of distinct denominators, the expansion written out as a sum, the term count, and a separate whole part when the fraction is greater than one. The fraction is first reduced to lowest terms so the expansion is canonical: 2/4 and 3/6 both expand as 1/2, which keeps results stable and comparable regardless of how the input was written.

How the greedy algorithm builds the expansion

The engine uses the greedy method often attributed to Fibonacci and studied by Sylvester. At each step it takes the largest unit fraction not exceeding what remains: if the remainder is n/d, the next term is 1/ceil(d/n). Subtracting that term leaves n*ceil(d/n) − d over d*ceil(d/n), and the new numerator is strictly smaller than the old one, so the process always terminates in at most n steps. A pleasant side effect is that every chosen denominator is larger than the previous one, so distinctness is guaranteed by construction rather than checked afterwards. The implementation works over arbitrary-precision integers, so values up to one trillion are handled exactly, with no floating point rounding anywhere in the computation. There is a declared ceiling on the number of terms, and inputs that would exceed it are rejected with a clear error instead of running unbounded. Because the expansion is deterministic, the same input always returns byte-identical output, which makes the endpoint safe to cache and to embed in pipelines that compare results.

Reading the output and handling edge cases

The response gives you the reduced expansion plus the original inputs echoed back, so a client can log exactly what was decomposed. The field unit_fractions holds the denominators in increasing order, expansion renders them as a human-readable sum like 1/2 + 1/11 + 1/111 + 1/1221, and count is simply the number of terms. When the fraction is improper, the integer part is returned separately in whole and the unit fractions expand only the fractional remainder, because classical Egyptian notation kept whole numbers outside the sum. Validation is strict on purpose: the denominator zero is rejected, non-integer values such as 2.5 or 1/2 as a string are rejected, and negative inputs are rejected, each with a message naming the offending field. Calling the API costs $0.002 per request, and the identical algorithm runs free in the browser widget on this page, so you can explore interactively and only pay when you automate. Everything is computed on demand and nothing you send is stored after the response is produced.