Gnumeric Circular Dependencies: Check the Formula, Not Just the Display
A circular dependency exists when a formula depends on its own result, directly or through other cells. A displayed number does not prove that such a model is correct. Repeatedly recalculating or increasing an iteration limit is not a substitute for checking the equations.
Scope: English Gnumeric desktop, official 1.12.62 source reviewed October 21, 2026. The source exposes workbook iteration controls and a calculation-cycle handler. This guide does not claim a particular warning, error code, starting value or numerical result for an unrepaired circular formula. No new Gnumeric execution or screenshot was performed; the repaired results and algebra below were independently checked. Distribution builds, translations and imported workbook settings can differ.
Preserve the workbook and inspect the setting
Work on a separately named copy. Record the affected cell, its exact formula, its direct inputs and whether the problem began after filling formulas, inserting rows or moving a total. Inspect the formula entry area rather than trusting a formatted result.
In File → Document Properties → Calculation, record Automatic/Manual, Iteration, Maximum iterations and Maximum change. Do not toggle Iteration in the original as an exploratory fix. The 1.12.62 implementation handles calculation cycles and uses iteration count and successive-value change in its stopping logic. Those controls limit or stop calculation; they do not independently validate the intended model. The documented labels and implementation are in the official source archive, particularly src/dialogs/doc-meta-data.ui, src/dialogs/dialog-doc-metadata.c and src/dependent.c.
A stale noncircular result belongs in the calculation-freshness exercise. Here the first question is whether following the references eventually returns to the starting cell.
A total accidentally includes itself
On an empty practice sheet, enter numeric 12, 18 and 9 in B2:B4. The intended total cell is B5. Its correct formula is =SUM(B2:B4), giving 39.
Suppose the copied formula in B5 instead reads =SUM(B2:B5). Inspect this expression without needing to execute it: B5 occurs inside the range used to calculate B5. The equation is “total = 39 + total,” which has no finite solution. A numeric display, an error or an unchanged cached value cannot make that equation valid.
- In your diagnostic copy, replace B5 with
=SUM(B2:B4)after confirming those are the intended detail rows. - Request Edit → Recalculate if needed. B5 should be 39.
- Change B3 from 18 to 23. B5 should become 44.
- Restore B3 to 18 and confirm 39 again.
- Inspect the total’s range after any later row insertion. Do not blindly shorten every SUM range; some legitimately include subtotal cells, while others must exclude them to prevent double-counting.
The changed-input test establishes that the repaired total depends on the intended detail rows. Overwriting B5 with the constant 39 would only hide the problem and would fail that test.
An indirect loop can look more plausible
Consider a separate synthetic model:
| Cell | Entry |
|---|---|
| D2 | 40 |
| D3 | 0.2 |
| D4 | =D2+D5 |
| D5 | =D3*D4 |
D4 depends on D5, which depends on D4. Unlike the self-including total, this pair has an algebraic solution: writing D4 as x gives x = 40 + 0.2x, so x = 40 / (1 − 0.2) = 50, with D5 = 10. The equations have a solution, but that alone does not establish that feedback was intended or that a particular iterative run found it.
If the model owner confirms this relationship, remove the circular dependency by changing D4 to =D2/(1-D3) and keeping D5 as =D3*D4. In F4 enter =D4-D2-D5 as an independent equation check. Expected results are D4 50, D5 10, and F4 0. Change D2 to 64: the corresponding expectations are 80, 16, and 0. Restore D2 to 40 afterward. Minor floating-point residuals in other inputs need a justified tolerance, not arbitrary deletion of digits.
The boundary matters: if D3 becomes 1 while D2 remains 40, the original equation would require x = 40 + x, and the rewritten expression has a zero denominator. Do not replace that failure with zero or silently clamp the rate. Ask whether the input is valid for the intended model. This algebraic rewrite is for this particular relationship, not a general repair for all circular workbooks.
Verify the repair rather than the symptom
Trace every reference in the affected chain until you reach independent inputs. For a larger model, write the chain down and mark where an address repeats; use the cell-reference guide to distinguish relative references from intentionally fixed inputs.
Keep deliberate iterative models separate from accidental loops. Record why iteration is needed and check the governing equations independently; a small change between iterations is not itself a proof of accuracy. This guide does not prescribe enabling iteration or any universal tolerance.
Save and reopen the repaired copy, inspect the formulas and calculation settings, and repeat the changed-input check. Keep the original until the repaired dependency and expected results are verified on your installation. For ordinary arithmetic failures, use division-by-zero diagnosis or the error selector; do not assume a circular dependency must display either of those errors.