Pow with an integer exponent (and Exp) truncates the result to 1 significant digit: 1.234^2 == 2

[matt-edmondson]

What's wrong

SignificantNumber.Pow (SignificantNumber/SignificantNumber.cs, ~line 579) sets the result precision with LowestSignificantDigits(this, power). An integer exponent such as 2 or 3 has 1 significant digit, and only -1, 0 and 1 are treated as exact, so the result is rounded to 1 significant digit. Exp has the same problem (~line 602).

This is separate from #101, which covers the lost sign of a negative base. The precision loss happens for positive bases too.

Expression	Returned	Expected
1.234.Pow(2)	2	1.523 (as 1.234 * 1.234 returns)
(-2.5).Pow(3)	20	about -15.6 (sign is #101; the magnitude also collapses to 1 digit)
SignificantNumber.Exp(2)	7	more than 1 significant digit

Reproduced against the current main build.

Why it matters

x.Pow(2) and x * x should agree, but they differ by up to an order of magnitude in reported precision. Any formula using squares or cubes (areas, volumes, kinetic energy, variance) silently collapses to one significant digit, which defeats the purpose of a significant-figures type.

Suggested fix

• Treat an integer exponent as exact, like the counting numbers in a multiplication. The result should keep the base's significant digits, which matches the behaviour of repeated multiplication.
• Apply the same rule to Exp: its precision should come from the exponent's value, not collapse to 1 digit for an integer input.
• Ideally, compute integer powers by repeated multiplication (or BigInteger) rather than Exp(Log(|x|) * p). That also keeps the sign, which would let this land together with the Pow returns a positive result for a negative base: (-2)^3 == 8, (-1)^3 == 1 #101 fix.

Acceptance criteria

• 1.234.Pow(2) == 1.234 * 1.234.
• Exp(2) returns more than 1 significant digit.
• Tests for integer exponents on non-trivial bases.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. Pow and Exp are core operations, and with an integer exponent they silently drop the result to one significant digit (1.234.Pow(2) == 2). Any formula with a square or cube gives a wrong answer and raises no error, which undermines the point of a significant-figures type.
• Area / suggested assignee: SignificantNumber.Pow / Exp precision selection (LowestSignificantDigits(this, power)). Maintainer: @matt-edmondson.
• Duplicates / in progress: Not a duplicate. It is related to Pow returns a positive result for a negative base: (-2)^3 == 8, (-1)^3 == 1 #101 (lost sign of a negative base), and open PR Keep the sign of a negative base in Pow, and reject undefined powers #102 fixes Pow returns a positive result for a negative base: (-2)^3 == 8, (-1)^3 == 1 #101 by editing the same Pow method. That PR does not change the precision rule. Land Keep the sign of a negative base in Pow, and reject undefined powers #102 first, or rebase this fix onto it, to avoid conflicting edits. The suggested repeated-multiplication approach for integer powers would also cover Pow returns a positive result for a negative base: (-2)^3 == 8, (-1)^3 == 1 #101's sign handling.
• Next steps: Treat integer exponents as exact, so the result keeps the base's significant digits. Give Exp the same rule. Add tests asserting x.Pow(2) == x * x and x.Pow(3) == x * x * x for non-trivial bases, and asserting that Exp(2) returns more than 1 significant digit.

---

Generated by Claude Code