[rqms40]

What this changes

Before: an xbrli:fractionItemType fact with numerator 1 and denominator 3 was parsed as value='13', numeric_value=13.0, because the instance parser joined the children's text. After: the fact is the quotient with decimals='INF'. Terminating quotients are stored exactly as decimal text (9007199254740993/1 stays 9007199254740993, and 1/2**6200 keeps all 4,334 digits). The quotient is computed with one division at sig(n) + 4*sig(d) + 1 digits; if that is inexact (recurring, such as one third) it is rounded half-even to 50 significant digits. Operands must match the xsd:decimal lexical form (ASCII digits, no exponent or underscore) and be at most 10,000 characters; anything else keeps its slash text with numeric_value=None. The division ignores the caller's decimal context. Non-fraction facts are unchanged.

Fixes #1766

Verification

• Ground truth: Apple Inc. FY2023 Form 10-K, accession 0000320193-23-000106, instance aapl-20230930_htm.xml: us-gaap:Assets, context c-22 (instant 2023-09-30) = 352583000000. SEC full-text search for fractionItemType and xbrli:numerator returned no hits, so no real filing with a fraction item was found. This is an ordinary-fact control, and the fraction cases use synthetic fixtures.
• Regression test in tests/issues/regression/test_issue_1766.py; its docstring links XBRL fraction items are parsed as their numerator and denominator digits joined (1/3 reads as 13) #1766. 17 tests pass (including exponent, 1_0, non-ASCII digit, 10,000/10,001-character boundary, and 10**60/3 fallback cases), also with PYTHONINTMAXSTRDIGITS=0.
• Cassettes: tests/cassettes/test_apple_fy2023_10k_ordinary_assets_are_unchanged.yaml was recorded from live SEC and not edited afterwards. Recorded on: 2026-10-24 (SEC response date 03:33:24 GMT)
• Silence check: not changed. A bad fraction (1/0, 0/0, abc/3) keeps its text with numeric_value=None, the same as an existing non-numeric fact, and the tests assert that.
• Docs: no documented example is touched.
• Changelog: changelog.d/1766.fixed.md, changelog.d/1766-xsd-decimal.fixed.md, changelog.d/1766-operand-length.fixed.md

Other checks: regression provenance OK (556), cassettes OK (272), lint shows no new findings. test-fast was last run on 2f7d1574, with 49963 passed and 3 failed. The 3 failures are textsearch highlight tests that fail under NO_COLOR and pass with color enabled. It was not re-run after the later commits, which touch only edgar/xbrl/parsers/instance.py, the regression test and the changelog fragments. XBRL parser tests (tests/xbrl/test_xbrl_parser.py, test_jj77_instance_fact_identity.py) pass at 9898334.

6.0

• This PR adds a deprecation, a 6.0 warning, or a "removed in 6.0" note, and docs/upgrade/6.0.md says what users see now and what to do instead

Not a 6.0 change.

AI assistance

• None
• Assisted. Tool and model: Cursor (implementation), GPT-6.1 Sol via Codex (code review)

[arhancanli]

One edge case in _exact_terminating_digits, with timings. I copied the PR's helper functions out of the diff and ran them on Python 3.9, which has the same decimal module behaviour.

_exact_terminating_digits(Decimal("1"), Decimal("3"))              # None, 0.0 s
_exact_terminating_digits(Decimal("1E+300000"), Decimal("3"))      # None, 0.05 s
_exact_terminating_digits(Decimal("1"), Decimal("1E-300000"))      # 1, 81.7 s

When the shift (numerator_exp - denominator_exp) is negative, the code runs denominator_coeff *= 10 ** (-shift), then gcd and % loops on that integer. The cost grows with the exponent rather than with the number of digits in the text. 1E-300000 is 9 characters, so a 9-character denominator in a filing's instance document ties up the parser for over a minute, and 1E-3000000 would take far longer. 1E-300000 is not a valid xsd:decimal (the lexical space has no exponent), which is why the numbers in real filings never hit this. But Decimal() accepts it, and so it accepts 1_0 and non-ASCII digits too, so the Decimal(num_text) call is the real gate.

A check against the decimal lexical form before any arithmetic would close this. For example, re.fullmatch(r'[+-]?(\d+(\.\d*)?|\.\d+)', text) on both operands, falling through to the existing "keep the slash form, numeric_value=None" path. A test with <xbrli:denominator>1E-300000</xbrli:denominator> asserting it returns fast and keeps 1/1E-300000 would pin it.

Smaller point: the regression test file is 413 lines, and none of the cases I could see in the diff cover an operand with an exponent or an underscore. Those are the inputs where Decimal() and the XBRL lexical space disagree.

[arhancanli]

Read the new commit against the case I timed: fullmatch on [0-9] only, run before any Decimal arithmetic, rejects 1E-300000, 1_0 and the Arabic-Indic digit, and the strip keeps " 2 " / " 4 " as one half. That closes the exponent route.

One input still scales with text length rather than value: a long plain-decimal denominator such as 0. followed by 300,000 zeros and a 1 is a valid xsd:decimal, so it passes the regex, and 10 ** (-shift) is then taken on a 300,000-digit scale. Did you time one of those with the same helper? If it is slow, a cap on operand length (real filings never need more than a few dozen digits) before the arithmetic would bound it, and the test could pin the cap with that input.

[dgunning]

Thanks for this. The bug is real (1/3 read as 13) and the main change is in the right place. I'd like two changes before merge, plus a note on CI.

1. Check that each operand is an xsd:decimal before calling Decimal(). @arhancanli's finding reproduces at the PR head: a denominator of 1E-20000 takes 0.16 s and 1E-60000 takes 1.47 s, so the time grows with the square of the exponent. Decimal() also accepts 1_0 (read as 10) and Arabic-Indic digits (١/2 gives 0.5), and neither is valid in an instance document. A gate like re.fullmatch(r'[+-]?(?:[0-9]+(?:\.[0-9]*)?|\.[0-9]+)', text) on both operands, falling through to the existing slash-form path, closes all three. Please add tests for an exponent, an underscore and a non-ASCII digit.

2. With that gate in place, most of the exactness code can go. Once the operands have no exponent, a terminating n/d has at most sig(n) + 4*sig(d) + 1 significant digits, since log2(d) < 3.33 * digits(d). So you can divide once at that precision and read the context's Inexact flag. If it's set, the quotient recurs, and you divide again at your current 50-digit rule. This replaces _coefficient, _decimal_digit_count and _exact_terminating_digits (about 75 lines). I compared the two versions on 40,006 cases (random integers and decimals over denominators of the form 2^a*5^b, random values, 3*2^k and 10^k, plus 1/2**6200 and 9007199254740993/1) and got 0 differences:

ctx = Context(prec=max(50, sig(n) + 4 * sig(d) + 1), rounding=ROUND_HALF_EVEN,
              Emin=MIN_EMIN, Emax=MAX_EMAX, traps=[])
q = ctx.divide(N, D)
if ctx.flags[Inexact]:          # recurring: round to the 50-digit rule
    q = _decimal_context(max(50, sig(n) + sig(d))).divide(N, D)

CI: the one test-fast (3.13) failure, tests/documents/test_markdown.py::test_obscure_filing_to_markdown, has nothing to do with this change. It passes at your head commit locally and on main, so the next push should clear it.

Parse time is fine. A 21,393-fact instance (GBDC 10-Q fixture) takes 15.3 s on this branch and 16.1 s on main, which is within noise.

[rqms40]

Thanks both. dgunning: point 1 is in (79c3ac1), with the gate matching your pattern and tests for an exponent, 1_0 and an Arabic-Indic digit. Point 2 is in 9898334: _coefficient, _decimal_digit_count and _exact_terminating_digits are gone, replaced by your single division at sig(n) + 4*sig(d) + 1 with the Inexact fallback to the 50-digit rule.

arhancanli: good call on long plain decimals. 1 / 0. + 300,000 zeros + 1 took 29.4 s before. The single division alone brings it to 2.5 ms, and operands over 10,000 characters now keep the slash form with numeric_value=None (100 would have rejected values the existing tests divide exactly, like 2**6200). Tests (264f4d0) pin the 10,000/10,001 boundary on both operands, check with a spy that capped operands never reach Decimal, and add 10**60 / 3 so the recurring fallback is actually exercised. 17 tests pass.

[arhancanli]

Read the new commit. The _is_xsd_decimal gate runs before any Decimal arithmetic, the 10,000-character cap sits right after it, and I checked the precision bound. sig(n) + 4*sig(d) + 1 is enough for a terminating quotient: the longest tail comes from a denominator with a factor 2^k, which adds k digits, and k is at most about 3.33 per significant digit of d. The Inexact flag then separates the recurring case cleanly. I didn't re-time it myself, so the 2.5 ms is your number.

One case I'd want a test for: the operands pass the gate, the quotient is exact, but it is too small or large for a float. For example 1 over 1 followed by 9,999 zeros gives an exact 1E-9999, and float() returns 0.0. Your numeric == 0.0 and quotient != 0 branch returns value, None, True, so it looks handled. Does any of the 17 tests cover it? That is the input where value and numeric_value have to disagree on purpose, and where a later refactor of numeric_value handling would break it without anyone noticing.

[arhancanli]

Read c61c6e7 (not run). Both tests cover the case I asked about: 1 over 1 plus 9,999 zeros keeps the exact decimal with numeric_value unset and float(fact.value) == 0.0 pinned, and the overflow test handles the OverflowError-or-inf split across Python builds.

One band is between those two and the normal range: a quotient like 1 over 10**320 is exact and inside the cap, and float() returns a subnormal (about 1e-320), nonzero but with only a few significant bits. Your numeric == 0.0 and quotient != 0 branch does not fire, so numeric_value is set to a number that has lost most of its precision while value stays exact. Is that intended, or should the unset rule also cover subnormals? Either way a test at 10**320 would pin which.