Expanding logarithms

This API does that rewrite for you. You send the base and the list of factors with their operations, and you get back the expanded expression, one term per factor, with the correct signs and coefficients. Numeric arguments are validated: a logarithm is only defined for positive arguments, so any factor that is zero or negative is rejected with a clear error instead of producing a meaningless expression.

What expanding a logarithm means

The three laws of logarithms turn structure inside the argument into structure outside it. The product rule says log_b(x·y) equals log_b(x) plus log_b(y): multiplication inside becomes addition outside. The quotient rule says log_b(x/y) equals log_b(x) minus log_b(y): division inside becomes subtraction outside. The power rule says log_b(x^n) equals n times log_b(x): an exponent inside slides out front as a coefficient. Expanding a logarithm is applying these laws left to right until nothing inside any logarithm can be broken down further. Students meet this when simplifying expressions before differentiating, when solving exponential equations, and when linearizing data for a log-log plot. The operation is purely mechanical once you identify each factor and how it enters the argument, which is exactly why it suits an API: you describe the expression as a base plus a list of operations and factors, and the expansion comes back as a ready-to-use string with each term spelled out, its sign, its coefficient and its argument.

How to describe your expression to the API

The input has two parts. The base is the logarithm's base: any positive number other than 1, so 2, 10 and e all work, while 1, 0 and negatives are rejected because no real logarithm has such a base. The terms array lists the factors of the argument in order. Each term names an operation — multiply, divide or power — and an argument. A multiply term contributes its log with a plus sign, a divide term with a minus sign, and a power term with its exponent pulled out as a coefficient in front. So log base 2 of x·y/z³ is three terms: multiply x, multiply y, and power z with exponent 3, which expands to log₂(x) + log₂(y) − 3·log₂(z). Arguments can be symbolic, like x or price, when you want the algebraic form, or numeric, like 8, when you want a concrete check. Numeric arguments must be positive; symbolic ones are kept verbatim because their sign depends on the values you later assign. A negative exponent on a power term simply flips the term's sign, since x to the minus n is the same as dividing by x to the n.

Why validation of the domain matters

A real logarithm is only defined for strictly positive arguments. log of zero diverges to minus infinity and log of a negative number is not a real number at all, so an expansion built on a non-positive factor would be symbolic noise that silently breaks the moment anyone evaluates it. This endpoint refuses to produce that noise: when a numeric argument is zero or negative, the call fails with an invalid-input error naming the offending term, and you are not charged for the call. The same strictness applies to the base, which must be positive and different from 1, and to exponents, which must be finite numbers — an exponent of zero is rejected because the term would contribute log of 1, which is zero and almost always a mistake in the input. The result is deterministic: the same request always returns the same string, byte for byte, which makes the endpoint safe to use inside generated worksheets, automated graders and CI checks that compare outputs literally. It runs on our edge with nothing stored, and the identical algorithm runs free in the browser on this page, so you pay $0.002 per call only when you automate it.