Discovered quirks

Every case below is a real, executed formula whose result did not match Excel’s documented/expected behavior. This is the flagship content of Can I Spreadsheet?: cross-engine divergence that only shows up when you actually run the formula. All three executed engines are represented — LibreOffice Calc 25.8.7.3, Google Sheets (Drive import, 2026-09-01) and Excel for the web (recalc, 2026-09-01) — each measured against Microsoft’s documentation for desktop Excel. We do not run desktop Excel, so nothing in the “documented / expected” column is a measurement.

What an Excel-for-the-web row means, and what it does not. Excel for the web is a separate implementation of the calculation engine from the desktop product, and we have no desktop run to set beside it. So a row badged Excel for the web asserts exactly one thing: the web engine’s executed result disagreed with Microsoft’s documentation for desktop Excel. It is evidence about the web engine and about nothing else. The disagreement may be a genuine web-versus-desktop difference, or it may be a documentation gap that affects both products — this page does not decide which, and the badge should not be read as deciding it either.

For the other question — where the three engines we execute disagree with each other, with no documentation involved and no error to warn anyone — see silent divergences.

1194 quirks found across 280 functions (617 in LibreOffice, 290 in Google Sheets, 287 in Excel for the web). A further 9 Google Sheets cases are excluded as inconclusive — explained by the .xlsx import/export round trip, not by Sheets. 7 Excel-for-the-web cases are excluded for the same class of reason on its own transport — the OneDrive round trip deleted a LAMBDA-bearing formula outright, or turned an INDIRECT into an unresolved external-workbook link — so the value that came back measures the trip, not the function. A further 7 functions never reached the web engine at all: its file-open refuses any workbook whose stored formulas carry the LAMBDA-family serialization, so those functions carry no Excel-for-the-web verdict and can hold no Excel-for-the-web quirk. See Coverage. 47 further executed cases are excluded because the function’s documented behaviour needs something no test workbook can supply — an external data server, a live fetch, another user’s authorization. Those results are published on their own pages with the reason; none of them is a quirk, because none of them is a statement about the engine. See Coverage.

ACCRINT LibreOffice Calc

=ACCRINT(A2,A3,A4,A5,A6,3,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, ACCRINT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACCRINT LibreOffice Calc

=ROUND(ACCRINT(DATE(2008,3,5),A3,A4,A5,A6,A7,A8,FALSE),6)

Actual result
#VALUE!

Documented / expected
15.555556

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft's page publishes this example's result as 15.555556. Re-derived on the same 30/360 basis: 2008-03-05 to 2008-05-01 is (5-3)*30 + (1-5) = 56 days, so 1000*0.1*56/360 = 15.55555556 -> 15.555556 at 6 dp; MISMATCH vs expected: expected 15.555556, got '#VALUE!'
ACCRINT LibreOffice Calc

=ROUND(ACCRINT(DATE(2008,4,5),A3,A4,A5,A6,A7,A8,TRUE),7)

Actual result
#VALUE!

Documented / expected
7.2222222

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft's page publishes this example's result as 7.2222222. Re-derived on the same 30/360 basis: 2008-04-05 to 2008-05-01 is (5-4)*30 + (1-5) = 26 days, so 1000*0.1*26/360 = 7.22222222 -> 7.2222222 at 7 dp; MISMATCH vs expected: expected 7.2222222, got '#VALUE!'
ACCRINT LibreOffice Calc

=ACCRINT(A4,A3,A2,A5,A6,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If issue >= settlement, ACCRINT returns the #NUM! error value." Here issue = serial 39569 (2008-05-01) and settlement = 39508 (2008-03-01); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACCRINT LibreOffice Calc

=ACCRINT(A2,A3,A4,0,A6,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If rate <= 0 or if par <= 0, ACCRINT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACCRINTM LibreOffice Calc

=ACCRINTM(A2,A3,A4,A5,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, ACCRINTM returns the #NUM! error value." The documented basis table stops at 4 (European 30/360); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACCRINTM LibreOffice Calc

=ACCRINTM(A3,A2,A4,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If issue >= settlement, ACCRINTM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACCRINTM LibreOffice Calc

=ACCRINTM(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If rate <= 0 or if par <= 0, ACCRINTM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACOSH LibreOffice Calc

=ACOSH(0.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents that number must be "any real number equal to or greater than 1"; below that the inverse hyperbolic cosine is not real, which is Excel's documented #NUM! case; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ACOT Google Sheets

=ROUND(ACOT(-2),9)

Actual result
-0.463647609

Documented / expected
2.677945045

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

Excel documents the result is in the range 0 to pi, so for a negative argument ACOT(-2) = pi + atan(1/-2) = pi - 0.4636476090008061 = 2.677945044588987 -> 2.677945045 at 9 dp, NOT the negative -0.4636 that atan(1/x) alone would give; MISMATCH vs expected: expected 2.677945045, got -0.463647609
ACOTH LibreOffice Calc

=ACOTH(0.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "If Number is less than 1, ACOTH returns the #NUM! error value." (The page's next line repeats the rule for the absolute value but misnames the function as ACOT and misnames the error as #VALUE!; the #NUM! statement is the one that names ACOTH, and 0.5 satisfies both stated conditions); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ADD Excel for the web

=ADD(A2,A3)

Actual result
#NAME?

Documented / expected
42

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The second Sample Usage line, ADD(A2,A3), with cells this corpus chose; 42 is derived from the "+ operator" equivalence, not published. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 42, got '#NAME?'
ADD LibreOffice Calc

=ADD(A2,A3)

Actual result
#NAME?

Documented / expected
42

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The second Sample Usage line, ADD(A2,A3), with cells this corpus chose; 42 is derived from the "+ operator" equivalence, not published. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 42, got '#NAME?'
ADD Excel for the web

=ADD(3,4)

Actual result
#NAME?

Documented / expected
7

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints the formula ADD(3,4) AND NOTHING ELSE -- there is no result column on this page, so 7 is DERIVED, not quoted, from the page's one-line definition: "Returns the sum of two numbers. Equivalent to the `+` operator." Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 7, got '#NAME?'
ADD LibreOffice Calc

=ADD(3,4)

Actual result
#NAME?

Documented / expected
7

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints the formula ADD(3,4) AND NOTHING ELSE -- there is no result column on this page, so 7 is DERIVED, not quoted, from the page's one-line definition: "Returns the sum of two numbers. Equivalent to the `+` operator." Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 7, got '#NAME?'
ADD Excel for the web

=ADD(A2,A3)-(A2+A3)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant. The page defines ADD as "Equivalent to the `+` operator", so the difference between the two spellings must be exactly zero whatever the engine computes. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 0, got '#NAME?'
ADD LibreOffice Calc

=ADD(A2,A3)-(A2+A3)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant. The page defines ADD as "Equivalent to the `+` operator", so the difference between the two spellings must be exactly zero whatever the engine computes. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 0, got '#NAME?'
ADD Excel for the web

=ADD(3,4)-SUM(3,4)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The Notes bullet reads: "Unlike SUM, ADD only supports the addition of two scalar values and takes neither ranges nor more than two arguments." The DIFFERENCE it draws is about what each accepts, not about what they compute, so on two scalars the two must agree. The page names no error value for the range/three-argument cases it excludes, so this corpus asserts nothing about them. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 0, got '#NAME?'
ADD LibreOffice Calc

=ADD(3,4)-SUM(3,4)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The Notes bullet reads: "Unlike SUM, ADD only supports the addition of two scalar values and takes neither ranges nor more than two arguments." The DIFFERENCE it draws is about what each accepts, not about what they compute, so on two scalars the two must agree. The page names no error value for the range/three-argument cases it excludes, so this corpus asserts nothing about them. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected 0, got '#NAME?'
ADD Excel for the web

=ROUND(ADD(-2.5,0.25),10)

Actual result
#NAME?

Documented / expected
-2.25

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the same one-line definition; the page publishes no example with negative or fractional arguments at all. ROUND-wrapped so binary floating point cannot decide the case. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected -2.25, got '#NAME?'
ADD LibreOffice Calc

=ROUND(ADD(-2.5,0.25),10)

Actual result
#NAME?

Documented / expected
-2.25

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the same one-line definition; the page publishes no example with negative or fractional arguments at all. ROUND-wrapped so binary floating point cannot decide the case. Google's ADD page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093590.; MISMATCH vs expected: expected -2.25, got '#NAME?'
AGGREGATE Google Sheets

=AGGREGATE(9,6,A1:A4)

Actual result
#NAME?

Documented / expected
70

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Math and trigonometry

MISMATCH vs expected: expected 70, got '#NAME?'
AMORDEGRC Google Sheets

=AMORDEGRC(A2,A3,A4,A5,A6,A7,A8)

Actual result
#NAME?

Documented / expected
776

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft's page publishes this example's result as 776. Independently derived from the documented depreciation-coefficient rule: life = 1/rate = 6.667 years, which is "More than 6 years", so the documented coefficient is 2.5 and the effective rate is 0.15*2.5 = 0.375. Serial 39679 = 2008-08-19 and 39813 = 2008-12-31, so on basis 1 (actual) the prorated first period is 134/366 of a year (2008 is a leap year) and period 0 depreciates ROUND(2400*0.375*134/366) = ROUND(329.508) = 330. Period 1 then depreciates ROUND((2400-330)*0.375) = ROUND(776.25) = 776, reproducing the published figure exactly; MISMATCH vs expected: expected 776, got '#NAME?'
AMORDEGRC Excel for the web

=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)

Actual result
937

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Financial

Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got 937
AMORDEGRC Google Sheets

=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
AMORDEGRC LibreOffice Calc

=AMORDEGRC(A2,A3,A4,A5,A6,0.4,A8)

Actual result
820

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents the same #NUM! rule for a life "between ... 2 and 3"; here 1/0.4 = 2.5 years; MISMATCH vs expected: expected '#NUM!', got 820
AMORDEGRC Excel for the web

=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)

Actual result
886

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Financial

Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got 886
AMORDEGRC Google Sheets

=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got '#NAME?'
AMORDEGRC LibreOffice Calc

=AMORDEGRC(A2,A3,A4,A5,A6,0.22,A8)

Actual result
696

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If the life of assets is between 0 (zero) and 1, 1 and 2, 2 and 3, or 4 and 5, the #NUM! error value is returned." Here 1/0.22 = 4.545 years falls in the excluded 4-to-5 band (the documented coefficient table only covers 3-4, 5-6 and >6); MISMATCH vs expected: expected '#NUM!', got 696
AMORDEGRC Google Sheets

=AMORDEGRC(A2,A3,A4,A5,0,A7,A8)

Actual result
#NAME?

Documented / expected
330

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Not published directly by Microsoft, but forced by the published period-1 figure: 776 = ROUND((2400 - period0)*0.375) has period0 = 330 as its only integer solution consistent with the documented mid-period proration ROUND(cost * rate * coefficient * days/year) = ROUND(2400*0.375*134/366) = ROUND(329.508) = 330. Verified in Python; MISMATCH vs expected: expected 330, got '#NAME?'
AND Excel for the web

=AND(TRUE,"abc")

Actual result
True

Documented / expected
#VALUE!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Logical

MISMATCH vs expected: expected '#VALUE!', got True
AREAS Google Sheets

=AREAS(B2:D4 B2)

Actual result
#ERROR!

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

Microsoft's page publishes this example's result as 1. The space operator intersects B2:D4 with B2, and the single-cell result is one contiguous area; MISMATCH vs expected: expected 1, got '#ERROR!'; NOTE: #ERROR! is Google Sheets' parse-failure error (no Excel equivalent); it means Sheets could not parse the formula, which is not the same as #NAME?
AREAS Google Sheets

=AREAS(B2)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

Follows directly from the documented definition that "an area is a range of contiguous cells or a single cell", so a lone cell reference is exactly one area; MISMATCH vs expected: expected 1, got '#NAME?'
AREAS Google Sheets

=AREAS(B2:D4)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

Microsoft's page publishes this example's result as 1. Follows directly from the documented definition: "An area is a range of contiguous cells or a single cell"; MISMATCH vs expected: expected 1, got '#NAME?'
AREAS Google Sheets

=AREAS((B2:D4,E5,F6:I9))

Actual result
#ERROR!

Documented / expected
3

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

Microsoft's page publishes this example's result as 3. The documentation specifies the extra set of parentheses so Excel does not read the commas as argument separators; the union then contains three areas (a 3x3 range, a single cell, and a 4x4 range); MISMATCH vs expected: expected 3, got '#ERROR!'; NOTE: #ERROR! is Google Sheets' parse-failure error (no Excel equivalent); it means Sheets could not parse the formula, which is not the same as #NAME?
ARRAYFORMULA Excel for the web

=ARRAYFORMULA(SUM(IF(A1:A10>5,A1:A10,0)))

Actual result
#NAME?

Documented / expected
40

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

The page's own second sample formula, over data this corpus supplied. 6+7+8+9+10 = 40. This is the case that exercises the SECOND half of the definition, "the use of non-array functions with arrays" -- IF is scalar, and without the wrapper it would see the range as a single condition rather than ten. DERIVED, not published. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 40, got '#NAME?'
ARRAYFORMULA LibreOffice Calc

=ARRAYFORMULA(SUM(IF(A1:A10>5,A1:A10,0)))

Actual result
#NAME?

Documented / expected
40

Engine
LibreOffice Calc 25.8.7.3

Category
Google

The page's own second sample formula, over data this corpus supplied. 6+7+8+9+10 = 40. This is the case that exercises the SECOND half of the definition, "the use of non-array functions with arrays" -- IF is scalar, and without the wrapper it would see the range as a single condition rather than ten. DERIVED, not published. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 40, got '#NAME?'
ARRAYFORMULA Excel for the web

=ARRAYFORMULA(A1:C1+A2:C2)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{11, 22, 33}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

Google's Sample Usage prints ARRAYFORMULA(A1:C1+A2:C2) and NO result, and populates none of the cells, so both the data and the answer here are this corpus's. The result is DERIVED from the page's definition -- "Enables the display of values returned from an array formula into multiple rows and/or columns" -- with the `array_formula` argument described as "a mathematical expression using one cell range or multiple ranges of the same size". ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 11, got '#NAME?'
ARRAYFORMULA LibreOffice Calc

=ARRAYFORMULA(A1:C1+A2:C2)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{11, 22, 33}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

Google's Sample Usage prints ARRAYFORMULA(A1:C1+A2:C2) and NO result, and populates none of the cells, so both the data and the answer here are this corpus's. The result is DERIVED from the page's definition -- "Enables the display of values returned from an array formula into multiple rows and/or columns" -- with the `array_formula` argument described as "a mathematical expression using one cell range or multiple ranges of the same size". ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 11, got '#NAME?'
ARRAYFORMULA Excel for the web

=SUM(ARRAYFORMULA(LEN(A1:A3)))

Actual result
#NAME?

Documented / expected
6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED from the same "use of non-array functions with arrays" clause: LEN of a range yields 1, 2 and 3, which sum to 6. Summed rather than spilled so the assertion is a single unambiguous number. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 6, got '#NAME?'
ARRAYFORMULA LibreOffice Calc

=SUM(ARRAYFORMULA(LEN(A1:A3)))

Actual result
#NAME?

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED from the same "use of non-array functions with arrays" clause: LEN of a range yields 1, 2 and 3, which sum to 6. Summed rather than spilled so the assertion is a single unambiguous number. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 6, got '#NAME?'
ARRAYFORMULA Excel for the web

=ARRAYFORMULA(1+1)

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED. The page describes ARRAYFORMULA as ENABLING array display, never as changing a value, so wrapping a scalar must be a no-op. Google publishes no example of this. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 2, got '#NAME?'
ARRAYFORMULA LibreOffice Calc

=ARRAYFORMULA(1+1)

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED. The page describes ARRAYFORMULA as ENABLING array display, never as changing a value, so wrapping a scalar must be a no-op. Google publishes no example of this. Google's ARRAYFORMULA page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093275.; MISMATCH vs expected: expected 2, got '#NAME?'
ARRAYTOTEXT Google Sheets

=ARRAYTOTEXT({1,2;3,4})

Actual result
#NAME?

Documented / expected
1, 2, 3, 4

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected '1, 2, 3, 4', got '#NAME?'
ARRAYTOTEXT LibreOffice Calc

=ARRAYTOTEXT({1,2;3,4})

Actual result
#NAME?

Documented / expected
1, 2, 3, 4

Engine
LibreOffice Calc 25.8.7.3

Category
Text

MISMATCH vs expected: expected '1, 2, 3, 4', got '#NAME?'
ARRAYTOTEXT Google Sheets

=ARRAYTOTEXT({1,2,3})

Actual result
#NAME?

Documented / expected
1, 2, 3

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected '1, 2, 3', got '#NAME?'
ARRAYTOTEXT LibreOffice Calc

=ARRAYTOTEXT({1,2,3})

Actual result
#NAME?

Documented / expected
1, 2, 3

Engine
LibreOffice Calc 25.8.7.3

Category
Text

MISMATCH vs expected: expected '1, 2, 3', got '#NAME?'
ARRAYTOTEXT Google Sheets

=ARRAYTOTEXT({1,2,3},1)

Actual result
#NAME?

Documented / expected
{1,2,3}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected '{1,2,3}', got '#NAME?'
ARRAYTOTEXT LibreOffice Calc

=ARRAYTOTEXT({1,2,3},1)

Actual result
#NAME?

Documented / expected
{1,2,3}

Engine
LibreOffice Calc 25.8.7.3

Category
Text

MISMATCH vs expected: expected '{1,2,3}', got '#NAME?'
ARRAYTOTEXT Google Sheets

=ARRAYTOTEXT({"a","b"},1)

Actual result
#NAME?

Documented / expected
{"a","b"}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected '{"a","b"}', got '#NAME?'
ARRAYTOTEXT LibreOffice Calc

=ARRAYTOTEXT({"a","b"},1)

Actual result
#NAME?

Documented / expected
{"a","b"}

Engine
LibreOffice Calc 25.8.7.3

Category
Text

MISMATCH vs expected: expected '{"a","b"}', got '#NAME?'
ARRAY_CONSTRAIN Excel for the web

=ARRAY_CONSTRAIN(A1:C10, 2, 3)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{1, 2, 3}, {4, 5, 6}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

The page's first sample formula, verbatim. The result is the TOP-LEFT 2x3 block, which is what "constrains" has to mean if the function is to be usable at all -- the page never says which corner it keeps, and this case is what makes that concrete. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. ARRAY_CONSTRAIN's page publishes NO results at all: two Sample Usage formulas, a three-line argument list and one Note. Every value below is DERIVED from the one-line definition, "Constrains an array result to a specified size", plus the argument descriptions "the number of rows the result should contain" and "the number of columns the result should contain". The 10x3 block of the integers 1..30, filled row-major, is this corpus's; the page names A1:C10 without populating it. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
ARRAY_CONSTRAIN LibreOffice Calc

=ARRAY_CONSTRAIN(A1:C10, 2, 3)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{1, 2, 3}, {4, 5, 6}}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

The page's first sample formula, verbatim. The result is the TOP-LEFT 2x3 block, which is what "constrains" has to mean if the function is to be usable at all -- the page never says which corner it keeps, and this case is what makes that concrete. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. ARRAY_CONSTRAIN's page publishes NO results at all: two Sample Usage formulas, a three-line argument list and one Note. Every value below is DERIVED from the one-line definition, "Constrains an array result to a specified size", plus the argument descriptions "the number of rows the result should contain" and "the number of columns the result should contain". The 10x3 block of the integers 1..30, filled row-major, is this corpus's; the page names A1:C10 without populating it. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
ARRAY_CONSTRAIN Excel for the web

=ARRAY_CONSTRAIN(A1:C10, 1, 1)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

DERIVED; a 1x1 result is a single value and needs no spill range. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036.; MISMATCH vs expected: expected 1, got '#NAME?'
ARRAY_CONSTRAIN LibreOffice Calc

=ARRAY_CONSTRAIN(A1:C10, 1, 1)

Actual result
#NAME?

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Array

DERIVED; a 1x1 result is a single value and needs no spill range. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036.; MISMATCH vs expected: expected 1, got '#NAME?'
ARRAY_CONSTRAIN Excel for the web

=ARRAY_CONSTRAIN(SORT(A1:C10, 1, FALSE), 2, 3)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{28, 29, 30}, {25, 26, 27}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

The shape of the page's second Sample Usage line, ARRAY_CONSTRAIN(SORT(A1:F100, 1, TRUE), 10, 6), scaled to this corpus's 10x3 block and sorted DESCENDING so the constrained result cannot coincide with the unsorted one. It is the case the page's Note is about: "Generally used in combination with other functions that return an array result when a fewer number of rows or columns are desired." Sorting 1..30 by its first column descending puts row (28,29,30) first and (25,26,27) second. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036. POST-EXECUTION ADDENDUM -- THE ONLY CROSS-BUILD DIFFERENCE IN THIS BATCH, AND IT IS ABOUT AN ERROR CODE, NOT A VALUE. This case returns #NAME? on 24.2.0.3 but #VALUE! on 24.8.7.2, 25.2.0.3 and 25.8.7.3. ARRAY_CONSTRAIN is absent from all four builds under all five storage spellings, so the difference is not about ARRAY_CONSTRAIN at all -- it is about the nested SORT. The harness stores SORT as _xlfn._xlws.SORT; 24.2 does not implement it, so the whole expression fails to resolve a name and the result is #NAME?, while on the three later builds SORT resolves and LibreOffice reports the still-unrecognised OUTER name as #VALUE! instead. LibreOffice's error code for an unknown function is therefore not stable: it depends on whether that function's ARGUMENTS resolved. Every other ARRAY_CONSTRAIN case in this file is #NAME? on all four builds, which is what the published verdict rests on.; MISMATCH vs expected: value mismatch: expected 28, got '#NAME?'
ARRAY_CONSTRAIN LibreOffice Calc

=ARRAY_CONSTRAIN(SORT(A1:C10, 1, FALSE), 2, 3)

Actual result
{#VALUE!, #VALUE!, #VALUE!, #VALUE!, #VALUE!, #VALUE!}

Documented / expected
{{28, 29, 30}, {25, 26, 27}}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

The shape of the page's second Sample Usage line, ARRAY_CONSTRAIN(SORT(A1:F100, 1, TRUE), 10, 6), scaled to this corpus's 10x3 block and sorted DESCENDING so the constrained result cannot coincide with the unsorted one. It is the case the page's Note is about: "Generally used in combination with other functions that return an array result when a fewer number of rows or columns are desired." Sorting 1..30 by its first column descending puts row (28,29,30) first and (25,26,27) second. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036. POST-EXECUTION ADDENDUM -- THE ONLY CROSS-BUILD DIFFERENCE IN THIS BATCH, AND IT IS ABOUT AN ERROR CODE, NOT A VALUE. This case returns #NAME? on 24.2.0.3 but #VALUE! on 24.8.7.2, 25.2.0.3 and 25.8.7.3. ARRAY_CONSTRAIN is absent from all four builds under all five storage spellings, so the difference is not about ARRAY_CONSTRAIN at all -- it is about the nested SORT. The harness stores SORT as _xlfn._xlws.SORT; 24.2 does not implement it, so the whole expression fails to resolve a name and the result is #NAME?, while on the three later builds SORT resolves and LibreOffice reports the still-unrecognised OUTER name as #VALUE! instead. LibreOffice's error code for an unknown function is therefore not stable: it depends on whether that function's ARGUMENTS resolved. Every other ARRAY_CONSTRAIN case in this file is #NAME? on all four builds, which is what the published verdict rests on.; MISMATCH vs expected: value mismatch: expected 28, got '#VALUE!'
ARRAY_CONSTRAIN Excel for the web

=ARRAY_CONSTRAIN(A1:C10, 3, 1)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{1, 4, 7}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

DERIVED. Rows and columns are constrained independently, so 3 rows by 1 column keeps the first cell of each of the first three rows. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
ARRAY_CONSTRAIN LibreOffice Calc

=ARRAY_CONSTRAIN(A1:C10, 3, 1)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{1, 4, 7}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

DERIVED. Rows and columns are constrained independently, so 3 rows by 1 column keeps the first cell of each of the first three rows. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's ARRAY_CONSTRAIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3267036.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
ASC Excel for the web

=ASC("Ａ１２３　")

Actual result
Ａ１２３　

Documented / expected
A123

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

Derived from the same documented full-width-to-half-width rule: U+FF21 -> A, U+FF11/FF12/FF13 -> 1/2/3, and U+3000 IDEOGRAPHIC SPACE -> U+0020 half-width space, giving the five-character string "A123 " (trailing half-width space); MISMATCH vs expected: expected 'A123 ', got 'Ａ１２３\u3000'
ASC LibreOffice Calc

=ASC("Ａ１２３　")

Actual result
A123U+3000

Documented / expected
A123U+0020

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Derived from the same documented full-width-to-half-width rule: U+FF21 -> A, U+FF11/FF12/FF13 -> 1/2/3, and U+3000 IDEOGRAPHIC SPACE -> U+0020 half-width space, giving the five-character string "A123 " (trailing half-width space); MISMATCH vs expected: expected 'A123 ', got 'A123\u3000'
ASC Excel for the web

=ASC("ＥＸＣＥＬ")

Actual result
ＥＸＣＥＬ

Documented / expected
EXCEL

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page's second example is the same word in full-width characters, but it is rendered as inline images so the literal argument cannot be copied from the page; this case reconstructs it from the documented rule that the function "changes full-width (double-byte) characters to half-width (single-byte) characters". The argument is U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), whose documented half-width forms are the ASCII letters EXCEL; MISMATCH vs expected: expected 'EXCEL', got 'ＥＸＣＥＬ'
ATAN2 LibreOffice Calc

=ATAN2(0,0)

Actual result
0

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "If both x_num and y_num are 0, ATAN2 returns the #DIV/0! error value." Note this is #DIV/0!, not the #NUM! that most out-of-domain math arguments produce; MISMATCH vs expected: expected '#DIV/0!', got 0
ATANH LibreOffice Calc

=ATANH(1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents "Number must be between -1 and 1 (excluding -1 and 1)"; at 1 the inverse hyperbolic tangent diverges, which is Excel's documented #NUM! case; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
AVERAGE.WEIGHTED Excel for the web

=ROUND(AVERAGE.WEIGHTED(B2:B6, C2:C6),10)

Actual result
#NAME?

Documented / expected
87.7

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT from the page's second example table: =AVERAGE.WEIGHTED(B2:B6, C2:C6) -> 87.7, over grades 95/90/85/88/82 weighted 25%/10%/15%/20%/30%. Derived independently as 23.75 + 9 + 12.75 + 17.6 + 24.6 = 87.7. The percentages are stored here as the numbers 0.25 ... 0.3, which is what a cell displaying "25%" contains. This is the only published example whose weights sum to exactly 1. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 87.7, got '#NAME?'
AVERAGE.WEIGHTED LibreOffice Calc

=ROUND(AVERAGE.WEIGHTED(B2:B6, C2:C6),10)

Actual result
#NAME?

Documented / expected
87.7

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT from the page's second example table: =AVERAGE.WEIGHTED(B2:B6, C2:C6) -> 87.7, over grades 95/90/85/88/82 weighted 25%/10%/15%/20%/30%. Derived independently as 23.75 + 9 + 12.75 + 17.6 + 24.6 = 87.7. The percentages are stored here as the numbers 0.25 ... 0.3, which is what a cell displaying "25%" contains. This is the only published example whose weights sum to exactly 1. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 87.7, got '#NAME?'
AVERAGE.WEIGHTED Excel for the web

=ROUND(AVERAGE.WEIGHTED(2, 10, 4, 15),10)

Actual result
#NAME?

Documented / expected
3.2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT: =AVERAGE.WEIGHTED(2, 10, 4, 15) -> 3.2. Derived independently as (2*10 + 4*15)/(10+15) = 80/25 = 3.2. This row is what fixes the ARGUMENT ORDER as value, weight, value, weight -- the syntax line alone (values, weights, [additional values], [additional weights]) could be read the other way. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 3.2, got '#NAME?'
AVERAGE.WEIGHTED LibreOffice Calc

=ROUND(AVERAGE.WEIGHTED(2, 10, 4, 15),10)

Actual result
#NAME?

Documented / expected
3.2

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT: =AVERAGE.WEIGHTED(2, 10, 4, 15) -> 3.2. Derived independently as (2*10 + 4*15)/(10+15) = 80/25 = 3.2. This row is what fixes the ARGUMENT ORDER as value, weight, value, weight -- the syntax line alone (values, weights, [additional values], [additional weights]) could be read the other way. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 3.2, got '#NAME?'
AVERAGE.WEIGHTED Excel for the web

=ROUND(AVERAGE.WEIGHTED(A1:A2, B1:B2, A3, B3),10)

Actual result
#NAME?

Documented / expected
6.2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

THE PUBLISHED FORMULA IN THIS ROW CANNOT PRODUCE THE PUBLISHED ANSWER, AND THE PAGE'S OWN LAYOUT SHOWS WHY. Google prints "=AVERAGE.WEIGHTED(A1:A2, B1:B2, C1, C2)" -> 6.2. But in that same example table column C is the FORMULA column and column D the RESULT column: C1 holds the header word "Formula" and C2 holds the first example formula. A weighted average cannot take a header string as an additional value and another formula as its weight. The data the row must have meant is the third row of the table's own data block, A3=8 and B3=6, and that reproduces the published figure exactly: (2*1 + 4*3 + 8*6)/(1+3+6) = 62/10 = 6.2. This case therefore asserts Google's published RESULT through the references its data requires, and records the printed references as wrong. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 6.2, got '#NAME?'
AVERAGE.WEIGHTED LibreOffice Calc

=ROUND(AVERAGE.WEIGHTED(A1:A2, B1:B2, A3, B3),10)

Actual result
#NAME?

Documented / expected
6.2

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

THE PUBLISHED FORMULA IN THIS ROW CANNOT PRODUCE THE PUBLISHED ANSWER, AND THE PAGE'S OWN LAYOUT SHOWS WHY. Google prints "=AVERAGE.WEIGHTED(A1:A2, B1:B2, C1, C2)" -> 6.2. But in that same example table column C is the FORMULA column and column D the RESULT column: C1 holds the header word "Formula" and C2 holds the first example formula. A weighted average cannot take a header string as an additional value and another formula as its weight. The data the row must have meant is the third row of the table's own data block, A3=8 and B3=6, and that reproduces the published figure exactly: (2*1 + 4*3 + 8*6)/(1+3+6) = 62/10 = 6.2. This case therefore asserts Google's published RESULT through the references its data requires, and records the printed references as wrong. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 6.2, got '#NAME?'
AVERAGE.WEIGHTED Excel for the web

=ROUND(AVERAGE.WEIGHTED(A1:A2, B1:B2),10)

Actual result
#NAME?

Documented / expected
3.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT, from the Formula/Result table in the article body: =AVERAGE.WEIGHTED(A1:A2, B1:B2) -> 3.5, over the table's own data (A1=2, A2=4, A3=8, B1=1, B2=3, B3=6). Derived independently as (2*1 + 4*3)/(1+3) = 14/4 = 3.5. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 3.5, got '#NAME?'
AVERAGE.WEIGHTED LibreOffice Calc

=ROUND(AVERAGE.WEIGHTED(A1:A2, B1:B2),10)

Actual result
#NAME?

Documented / expected
3.5

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT, from the Formula/Result table in the article body: =AVERAGE.WEIGHTED(A1:A2, B1:B2) -> 3.5, over the table's own data (A1=2, A2=4, A3=8, B1=1, B2=3, B3=6). Derived independently as (2*1 + 4*3)/(1+3) = 14/4 = 3.5. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 3.5, got '#NAME?'
AVERAGE.WEIGHTED Excel for the web

=ROUND(AVERAGE.WEIGHTED(A1:A3, C1:C3),10)

Actual result
#NAME?

Documented / expected
5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

DERIVED from the `weights` argument description: "Weights cannot be negative, though they can be zero. At least one of the weights must be positive." A zero weight must therefore drop its value out of both the numerator and the denominator: (2*1 + 4*0 + 8*1)/(1+0+1) = 10/2 = 5. Google publishes no example with a zero weight and names NO error value for a negative weight, so this corpus asserts nothing about negative weights. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 5, got '#NAME?'
AVERAGE.WEIGHTED LibreOffice Calc

=ROUND(AVERAGE.WEIGHTED(A1:A3, C1:C3),10)

Actual result
#NAME?

Documented / expected
5

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

DERIVED from the `weights` argument description: "Weights cannot be negative, though they can be zero. At least one of the weights must be positive." A zero weight must therefore drop its value out of both the numerator and the denominator: (2*1 + 4*0 + 8*1)/(1+0+1) = 10/2 = 5. Google publishes no example with a zero weight and names NO error value for a negative weight, so this corpus asserts nothing about negative weights. Google's AVERAGE.WEIGHTED page, read live on 2026-08-31 at https://support.google.com/docs/answer/9084098.; MISMATCH vs expected: expected 5, got '#NAME?'
BESSELI Google Sheets

=ROUND(BESSELI(1.5,1),8)

Actual result
#NAME?

Documented / expected
0.98166643

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Microsoft's page publishes this example's result as 0.981666428. Independently re-derived to 20 significant digits with mpmath: besseli(1, 1.5) = 0.98166642857790758565, so the true value rounds to 0.981666429 at 9 dp -- the page's trailing 8 is a TRUNCATION of ...4285 rather than a round. Asserting at 8 dp (0.98166643) is the deepest precision at which the published figure and the true value agree, so a mismatch here is an engine difference and not a documentation artefact; MISMATCH vs expected: expected 0.98166643, got '#NAME?'
BESSELI Google Sheets

=BESSELI(1.5,-1)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If n < 0, BESSELI returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BESSELI LibreOffice Calc

=BESSELI(1.5,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If n < 0, BESSELI returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BESSELI Google Sheets

=ROUND(BESSELI(1.5,1.9),8)

Actual result
#NAME?

Documented / expected
0.98166643

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents "If n is not an integer, it is truncated", so order 1.9 must behave exactly as order 1 and return the same 0.98166643 as the documented example above. Independently verified with mpmath: besseli(1, 1.5) = 0.9816664285779076; besseli(1.9, 1.5) would be 0.38286062, so this case distinguishes truncation from a real fractional-order evaluation; MISMATCH vs expected: expected 0.98166643, got '#NAME?'
BESSELI Google Sheets

=BESSELI("abc",1)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If x is nonnumeric, BESSELI returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
BESSELJ Google Sheets

=ROUND(BESSELJ(1.9,2),6)

Actual result
#NAME?

Documented / expected
0.329926

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Microsoft's page publishes this example's result as 0.329925829, but that figure is WRONG in the 7th decimal place. Re-derived to 20 significant digits with mpmath: besselj(2, 1.9) = 0.32992572769238721660 (scipy.special.jv agrees to machine precision), which differs from the published 0.329925829 by 1.01e-07 -- far larger than the ~1e-10 rounding residue seen on the sibling BESSELY page. Asserting at 6 dp (0.329926) is the deepest precision at which the published figure and the mathematically correct value still agree, so this case tests the function rather than Microsoft's typo; MISMATCH vs expected: expected 0.329926, got '#NAME?'
BESSELJ Google Sheets

=BESSELJ(1.9,-1)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BESSELJ LibreOffice Calc

=BESSELJ(1.9,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BESSELJ Google Sheets

=ROUND(BESSELJ(1.9,2.7),6)

Actual result
#NAME?

Documented / expected
0.329926

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents "If n is not an integer, it is truncated", so order 2.7 must behave exactly as order 2. Independently verified with mpmath: besselj(2, 1.9) = 0.3299257276923872, while a genuine fractional-order besselj(2.7, 1.9) would be about 0.16248, so this case separates truncation from fractional-order evaluation; MISMATCH vs expected: expected 0.329926, got '#NAME?'
BESSELJ Google Sheets

=BESSELJ("abc",2)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If x is nonnumeric, BESSELJ returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
BESSELJ Excel for the web

=ROUND(BESSELJ(0,0),9)

Actual result
1.000000003

Documented / expected
1.0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly; MISMATCH vs expected: expected 1.0, got 1.000000003
BESSELJ Google Sheets

=ROUND(BESSELJ(0,0),9)

Actual result
#NAME?

Documented / expected
1.0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly; MISMATCH vs expected: expected 1.0, got '#NAME?'
BESSELK Google Sheets

=ROUND(BESSELK(1.5,1),8)

Actual result
#NAME?

Documented / expected
0.2773878

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Microsoft's page publishes this example's result as 0.277387804. Independently re-derived to 20 significant digits with mpmath: besselk(1, 1.5) = 0.27738780045684381609, so the correct 9-dp value is 0.277387800 and the page's trailing ...804 is off by 3.5e-09. Asserting at 8 dp (0.2773878) is the deepest precision at which the published figure and the true value agree; MISMATCH vs expected: expected 0.2773878, got '#NAME?'
BESSELK Google Sheets

=BESSELK(1.5,-1)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If n < 0, BESSELK returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BESSELK LibreOffice Calc

=BESSELK(1.5,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If n < 0, BESSELK returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BESSELK Google Sheets

=ROUND(BESSELK(1.5,1.4),8)

Actual result
#NAME?

Documented / expected
0.2773878

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents "If n is not an integer, it is truncated", so order 1.4 must behave exactly as order 1 and return the documented 0.2773878. Independently verified with mpmath: a genuine fractional-order besselk(1.4, 1.5) would be about 0.35394, so this case separates truncation from fractional-order evaluation; MISMATCH vs expected: expected 0.2773878, got '#NAME?'
BESSELK Google Sheets

=BESSELK("abc",1)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If x is nonnumeric, BESSELK returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
BESSELY Google Sheets

=ROUND(BESSELY(2.5,1),9)

Actual result
#NAME?

Documented / expected
0.145918138

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Microsoft's page publishes this example's result as 0.145918138. Independently re-derived to 20 significant digits with mpmath: bessely(1, 2.5) = 0.14591813796678579888 -> 0.145918138 at 9 dp, an exact match (unlike the sibling BESSELI/BESSELJ/BESSELK pages, whose published last digits are truncated or wrong); MISMATCH vs expected: expected 0.145918138, got '#NAME?'
BESSELY Google Sheets

=BESSELY(2.5,-1)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If n < 0, BESSELY returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BESSELY LibreOffice Calc

=BESSELY(2.5,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If n < 0, BESSELY returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BESSELY Google Sheets

=ROUND(BESSELY(2.5,1.6),9)

Actual result
#NAME?

Documented / expected
0.145918138

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents "If n is not an integer, it is truncated", so order 1.6 must behave exactly as order 1. Independently verified with mpmath: a genuine fractional-order bessely(1.6, 2.5) would be about -0.19313, so this case separates truncation from fractional-order evaluation; MISMATCH vs expected: expected 0.145918138, got '#NAME?'
BESSELY Google Sheets

=BESSELY("abc",1)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If x is nonnumeric, BESSELY returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
BETA.DIST LibreOffice Calc

=BETA.DIST(A2,0,A4,TRUE,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or beta <= 0, BETA.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETA.DIST LibreOffice Calc

=BETA.DIST(4,A3,A4,TRUE,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x < A, x > B, or A = B, BETA.DIST returns the #NUM! error value." Here x = 4 exceeds B = 3; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETA.INV LibreOffice Calc

=BETA.INV(0.5,8,0,1,3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or beta <= 0, BETA.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETA.INV LibreOffice Calc

=BETA.INV(1.5,8,10,1,3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents the same rule for probability > 1; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETA.INV LibreOffice Calc

=BETA.INV(0,8,10,1,3)

Actual result
1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability <= 0 or probability > 1, BETA.INV returns the #NUM! error value." Note the asymmetry -- probability = 1 is allowed but probability = 0 is not; MISMATCH vs expected: expected '#NUM!', got 1
BETADIST LibreOffice Calc

=BETADIST(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or beta <= 0, BETADIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETADIST LibreOffice Calc

=BETADIST(A2,A3,A4,2,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents the same rule for the degenerate case A = B, where the rescaling (x-A)/(B-A) would divide by zero -- note the documented error is #NUM!, not #DIV/0!; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETADIST LibreOffice Calc

=BETADIST(0,A3,A4,A5,A6)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x < A, x > B, or A = B, BETADIST returns the #NUM! error value." Here x = 0 is below A = 1; MISMATCH vs expected: expected '#NUM!', got 0
BETAINV LibreOffice Calc

=BETAINV(0.5,0,10,1,3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or beta <= 0, BETAINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BETAINV LibreOffice Calc

=BETAINV(0,8,10,1,3)

Actual result
1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability <= 0 or probability > 1, BETAINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got 1
BINOM.DIST LibreOffice Calc

=BINOM.DIST(A2,A3,1.5,FALSE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability_s < 0 or probability_s > 1, BINOM.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BINOM.DIST LibreOffice Calc

=BINOM.DIST(11,A3,A4,FALSE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If number_s < 0 or number_s > trials, BINOM.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BINOM.DIST.RANGE LibreOffice Calc

=ROUND(BINOM.DIST.RANGE(60,0.75,45,50),3)

Actual result
#NAME?

Documented / expected
0.524

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft's page publishes this example's result as 0.524 (52.4%). Independently derived by summing the binomial mass over k = 45..50 inclusive (the documented equation sums from s to s2): 0.5236297934718872 -> 0.524 at 3 dp. This case also pins the INCLUSIVE upper bound: excluding k=50 would give 0.482911; MISMATCH vs expected: expected 0.524, got '#NAME?'
BINOM.DIST.RANGE LibreOffice Calc

=ROUND(BINOM.DIST.RANGE(60,0.75,48),3)

Actual result
#NAME?

Documented / expected
0.084

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft's page publishes this example's result as 0.084 (8.4%). Independently derived from the documented summation with s2 omitted (so the sum has the single term k=48): C(60,48)*0.75^48*0.25^12 = 0.0839749674290475 -> 0.084 at 3 dp; MISMATCH vs expected: expected 0.084, got '#NAME?'
BINOM.DIST.RANGE LibreOffice Calc

=BINOM.DIST.RANGE(60,1.5,48)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents that Probability_s "must be greater than or equal to 0 and less than or equal to 1", with #NUM! for arguments outside their constraints; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BINOM.DIST.RANGE LibreOffice Calc

=ROUND(BINOM.DIST.RANGE(60,0.75,48),6)

Actual result
#NAME?

Documented / expected
0.083975

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft rounds this example to 0.084 on the page. Re-derived exactly from the documented equation: C(60,48)*0.75^48*0.25^12 = 0.0839749674290475 -> 0.083975 at 6 dp. Asserting at 6 dp catches an engine that agrees to the published 3 dp but computes the tail differently; MISMATCH vs expected: expected 0.083975, got '#NAME?'
BINOM.DIST.RANGE LibreOffice Calc

=BINOM.DIST.RANGE(60,0.75,61)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents that Number_s "must be greater than or equal to 0 and less than or equal to Trials" and that "If any arguments are outside of their constraints, BINOM.DIST.RANGE returns the #NUM! error value"; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
BINOM.DIST.RANGE LibreOffice Calc

=BINOM.DIST.RANGE(60,0.75,"abc")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If any arguments are non-numeric values, BINOM.DIST.RANGE returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
BINOM.INV LibreOffice Calc

=BINOM.INV(6,0.5,0)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or alpha => 1, BINOM.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got 0
BINOM.INV LibreOffice Calc

=BINOM.INV(6,1,0.75)

Actual result
6

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability_s is <= 0 or probability_s => 1, BINOM.INV returns the #NUM! error value." Note that unlike BINOM.DIST, the endpoints 0 and 1 are EXCLUDED here; MISMATCH vs expected: expected '#NUM!', got 6
BINOMDIST LibreOffice Calc

=BINOMDIST(A2,A3,-0.1,FALSE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability_s < 0 or probability_s > 1, BINOMDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BINOMDIST LibreOffice Calc

=BINOMDIST(11,A3,A4,FALSE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If number_s < 0 or number_s > trials, BINOMDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
BYCOL LibreOffice Calc

=BYCOL(A1:B2,LAMBDA(c,SUM(c)))

Actual result
{#NAME?, #NAME?}

Documented / expected
{4, 6}

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: value mismatch: expected 4, got '#NAME?'
BYROW LibreOffice Calc

=BYROW(A1:B2,LAMBDA(r,SUM(r)))

Actual result
{#NAME?, #NAME?}

Documented / expected
{3, 7}

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: value mismatch: expected 3, got '#NAME?'
CHAR LibreOffice Calc

=UNICODE(CHAR(160))

Actual result
65533

Documented / expected
160

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Excel's CHAR maps its argument through the Windows-1252 (ANSI) code page, where 160 is the non-breaking space -- which is why Microsoft's TRIM page can call CHAR(160) "the nonbreaking space character ... commonly used in web pages as the HTML entity  " (https://support.microsoft.com/en-us/office/trim-function-410388fa-c5df-49c6-b16c-9e5630b479f9). LibreOffice's help instead defines CHAR as converting "a number into a character according to the current code table", so the result is platform/locale dependent there; UNICHAR(160) is the portable spelling. Source: https://support.microsoft.com/en-us/office/char-function-bbd249c8-b36e-4a91-8017-1c133f9b837a; MISMATCH vs expected: expected 160, got 65533
CHAR Google Sheets

=CHAR(256)

Actual result
Ā

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Source: https://support.microsoft.com/en-us/office/char-function-bbd249c8-b36e-4a91-8017-1c133f9b837a - valid range is 1-255; values outside it are invalid; MISMATCH vs expected: expected '#VALUE!', got 'Ā'
CHAR Google Sheets

=CHAR(0)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Microsoft docs: CHAR takes "A number between 1 and 255 specifying which character you want." Source: https://support.microsoft.com/en-us/office/char-function-bbd249c8-b36e-4a91-8017-1c133f9b837a; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
CHAR LibreOffice Calc

=CHAR(0)

Actual result
_x0000_

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft docs: CHAR takes "A number between 1 and 255 specifying which character you want." Source: https://support.microsoft.com/en-us/office/char-function-bbd249c8-b36e-4a91-8017-1c133f9b837a; MISMATCH vs expected: expected '#VALUE!', got '_x0000_'
CHIDIST LibreOffice Calc

=CHIDIST(-1,A3)

Actual result
1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x is negative, CHIDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got 1
CHIDIST LibreOffice Calc

=CHIDIST(A2,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If deg_freedom < 1 or deg_freedom > 10^10, CHIDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHIINV LibreOffice Calc

=CHIINV(1.5,A3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability < 0 or probability > 1, CHIINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHIINV LibreOffice Calc

=CHIINV(A2,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If deg_freedom < 1, CHIINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.DIST LibreOffice Calc

=CHISQ.DIST(-1,3,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x is negative, CHISQ.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.DIST LibreOffice Calc

=CHISQ.DIST(0.5,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom < 1 or deg_freedom > 10^10, CHISQ.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.DIST.RT LibreOffice Calc

=CHISQ.DIST.RT(A2,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom < 1 or deg_freedom > 10^10, CHISQ.DIST.RT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.INV LibreOffice Calc

=CHISQ.INV(1.5,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability < 0 or probability > 1, CHISQ.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.INV LibreOffice Calc

=CHISQ.INV(0.93,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom < 1 or deg_freedom > 10^10, CHISQ.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.INV.RT LibreOffice Calc

=CHISQ.INV.RT(-0.5,A3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability < 0 or probability > 1, CHISQ.INV.RT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.INV.RT LibreOffice Calc

=CHISQ.INV.RT(A2,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom < 1, CHISQ.INV.RT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CHISQ.TEST LibreOffice Calc

=CHISQ.TEST(A2:B4,A6:B7)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If actual_range and expected_range have a different number of data points, CHISQ.TEST returns the #N/A error value." Here the actual range holds 6 values and the expected range 4; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
CHISQ.TEST Google Sheets

=CHISQ.TEST(A2,A6)

Actual result
0.06031830659

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "r = c= 1 is not allowed and #N/A is returned." With one row and one column there are no degrees of freedom left after conditioning on the margins, so CHISQ.TEST has no distribution to evaluate; MISMATCH vs expected: expected '#N/A', got 0.06031830659
CHISQ.TEST LibreOffice Calc

=CHISQ.TEST(A2,A6)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "r = c= 1 is not allowed and #N/A is returned." With one row and one column there are no degrees of freedom left after conditioning on the margins, so CHISQ.TEST has no distribution to evaluate; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
CHISQDIST Excel for the web

=ROUND(CHISQDIST(3,2,FALSE())-CHISQDIST(3,2,0),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

A structural assertion with no derived constant, from the same sentence. The page lists 0 and False as equivalent, and this is the case that says so. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0, got '#NAME?'
CHISQDIST Google Sheets

=ROUND(CHISQDIST(3,2,FALSE())-CHISQDIST(3,2,0),12)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

A structural assertion with no derived constant, from the same sentence. The page lists 0 and False as equivalent, and this is the case that says so. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0, got '#NAME?'
CHISQDIST Excel for the web

=ROUND(CHISQDIST(3,2,1),12)

Actual result
#NAME?

Documented / expected
0.776869839852

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. CHISQDIST's entry in Statistical Functions Part One carries a description and a Syntax block and NO Example section at all -- unlike its neighbours CHISQ.DIST.RT and CHISQ.INV.RT on the same page, which do publish worked examples. Every value in this file is therefore DERIVED from the page's stated semantics: "Returns the value of the probability density function or the cumulative distribution function for the chi-square distribution", with "Cumulative (optional): 0 or False calculates the probability density function. Other values or True or omitted calculates the cumulative distribution function." Derived independently at 40 decimal digits with mpmath as the regularised lower incomplete gamma function P(k/2, x/2) = P(1, 1.5) = 1 - exp(-1.5) = 0.7768698398515701710667195292359874786578, then rounded to the 12 places asserted here. The ROUND() wrapper keeps the assertion clear of last-bit formatting differences. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.776869839852, got '#NAME?'
CHISQDIST Google Sheets

=ROUND(CHISQDIST(3,2,1),12)

Actual result
#NAME?

Documented / expected
0.776869839852

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. CHISQDIST's entry in Statistical Functions Part One carries a description and a Syntax block and NO Example section at all -- unlike its neighbours CHISQ.DIST.RT and CHISQ.INV.RT on the same page, which do publish worked examples. Every value in this file is therefore DERIVED from the page's stated semantics: "Returns the value of the probability density function or the cumulative distribution function for the chi-square distribution", with "Cumulative (optional): 0 or False calculates the probability density function. Other values or True or omitted calculates the cumulative distribution function." Derived independently at 40 decimal digits with mpmath as the regularised lower incomplete gamma function P(k/2, x/2) = P(1, 1.5) = 1 - exp(-1.5) = 0.7768698398515701710667195292359874786578, then rounded to the 12 places asserted here. The ROUND() wrapper keeps the assertion clear of last-bit formatting differences. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.776869839852, got '#NAME?'
CHISQDIST Excel for the web

=ROUND(CHISQDIST(3,2)-CHISQDIST(3,2,1),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

A structural assertion with no derived constant, from the Cumulative parameter's own sentence. Asserted as a difference so that the case tests only the default, and would still be meaningful if the corpus's derived constant above were ever revised. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0, got '#NAME?'
CHISQDIST Google Sheets

=ROUND(CHISQDIST(3,2)-CHISQDIST(3,2,1),12)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

A structural assertion with no derived constant, from the Cumulative parameter's own sentence. Asserted as a difference so that the case tests only the default, and would still be meaningful if the corpus's derived constant above were ever revised. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0, got '#NAME?'
CHISQDIST Excel for the web

=ROUND(CHISQDIST(3,2,0),12)

Actual result
#NAME?

Documented / expected
0.111565080074

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

DERIVED from the same sentence, taking the other branch: with two degrees of freedom the chi-square density is exp(-x/2)/2, so at x = 3 it is 0.1115650800742149144666402353820062606711 (mpmath, 40 digits). This case and the one above are what make the Cumulative argument's two branches separately visible; an implementation that ignored the flag would pass one and fail the other. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.111565080074, got '#NAME?'
CHISQDIST Google Sheets

=ROUND(CHISQDIST(3,2,0),12)

Actual result
#NAME?

Documented / expected
0.111565080074

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

DERIVED from the same sentence, taking the other branch: with two degrees of freedom the chi-square density is exp(-x/2)/2, so at x = 3 it is 0.1115650800742149144666402353820062606711 (mpmath, 40 digits). This case and the one above are what make the Cumulative argument's two branches separately visible; an implementation that ignored the flag would pass one and fail the other. LibreOffice's CHISQDIST help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.111565080074, got '#NAME?'
CHISQINV Excel for the web

=ROUND(CHISQINV(0.5,2),12)

Actual result
#NAME?

Documented / expected
1.38629436112

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

NOTHING ON THIS PAGE IS A PUBLISHED RESULT: like CHISQDIST above, CHISQINV's entry carries a description and a Syntax block and no Example section, while the COM.MICROSOFT-namespaced CHISQ.INV immediately above it on the same page does publish one. DERIVED from the page's whole description, which is one sentence: "Returns the inverse of CHISQDIST." Read together with CHISQDIST's own page that makes this the inverse of the CUMULATIVE branch (the default branch), i.e. the left-tailed quantile -- and the two cases below check that reading rather than assuming it. Derived independently: with two degrees of freedom the cumulative function is 1 - exp(-x/2), so its inverse at 0.5 is 2*ln(2) = 1.386294361119890618834464242916353136151 (mpmath, 40 digits). STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 1.38629436112, got '#NAME?'
CHISQINV Google Sheets

=ROUND(CHISQINV(0.5,2),12)

Actual result
#NAME?

Documented / expected
1.38629436112

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

NOTHING ON THIS PAGE IS A PUBLISHED RESULT: like CHISQDIST above, CHISQINV's entry carries a description and a Syntax block and no Example section, while the COM.MICROSOFT-namespaced CHISQ.INV immediately above it on the same page does publish one. DERIVED from the page's whole description, which is one sentence: "Returns the inverse of CHISQDIST." Read together with CHISQDIST's own page that makes this the inverse of the CUMULATIVE branch (the default branch), i.e. the left-tailed quantile -- and the two cases below check that reading rather than assuming it. Derived independently: with two degrees of freedom the cumulative function is 1 - exp(-x/2), so its inverse at 0.5 is 2*ln(2) = 1.386294361119890618834464242916353136151 (mpmath, 40 digits). STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 1.38629436112, got '#NAME?'
CHISQINV Excel for the web

=ROUND(CHISQDIST(CHISQINV(0.7,4),4,1),10)

Actual result
#NAME?

Documented / expected
0.7

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

A structural assertion with no derived constant, and the case that carries the page's entire documented claim: feeding CHISQINV's output back into CHISQDIST must return the probability it started from. This is also what pins the inverse to the cumulative branch -- the density is not monotonic, so no such round trip exists for it. Asserted at 10 places rather than 12 to leave room for the root-finder's own convergence tolerance, which the page does not specify. LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.7, got '#NAME?'
CHISQINV Google Sheets

=ROUND(CHISQDIST(CHISQINV(0.7,4),4,1),10)

Actual result
#NAME?

Documented / expected
0.7

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

A structural assertion with no derived constant, and the case that carries the page's entire documented claim: feeding CHISQINV's output back into CHISQDIST must return the probability it started from. This is also what pins the inverse to the cumulative branch -- the density is not monotonic, so no such round trip exists for it. Asserted at 10 places rather than 12 to leave room for the root-finder's own convergence tolerance, which the page does not specify. LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 0.7, got '#NAME?'
CHISQINV Excel for the web

=ROUND(CHISQINV(0.95,1),12)

Actual result
#NAME?

Documented / expected
3.841458820694

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical Part One

DERIVED independently as the solution of P(0.5, x/2) = 0.95, which is 3.841458820694124469101699415925084172617 (mpmath, 40 digits). Chosen because a left-tailed and a right-tailed reading of "the inverse" give wildly different answers here (3.8414588 versus 0.0039321), so the case would catch a tail-convention error that the symmetric-looking median case above could not. LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 3.841458820694, got '#NAME?'
CHISQINV Google Sheets

=ROUND(CHISQINV(0.95,1),12)

Actual result
#NAME?

Documented / expected
3.841458820694

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Statistical Part One

DERIVED independently as the solution of P(0.5, x/2) = 0.95, which is 3.841458820694124469101699415925084172617 (mpmath, 40 digits). Chosen because a left-tailed and a right-tailed reading of "the inverse" give wildly different answers here (3.8414588 versus 0.0039321), so the case would catch a tail-convention error that the symmetric-looking median case above could not. LibreOffice's CHISQINV help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060181.html.; MISMATCH vs expected: expected 3.841458820694, got '#NAME?'
CHITEST LibreOffice Calc

=CHITEST(A2:B4,A6:B7)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If actual_range and expected_range have a different number of data points, CHITEST returns the #N/A error value." Here the actual range holds 6 values and the expected range 4; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
CHITEST Google Sheets

=CHITEST(A2,A6)

Actual result
0.06031830659

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Excel documents: "r = c= 1 is not allowed and #N/A is returned." With one row and one column there are no degrees of freedom left after conditioning on the margins, so CHITEST has no distribution to evaluate; MISMATCH vs expected: expected '#N/A', got 0.06031830659
CHITEST LibreOffice Calc

=CHITEST(A2,A6)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "r = c= 1 is not allowed and #N/A is returned." With one row and one column there are no degrees of freedom left after conditioning on the margins, so CHITEST has no distribution to evaluate; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
CHOOSE Google Sheets

=CHOOSE(5,"a","b","c")

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

https://support.microsoft.com/en-us/office/choose-function-fc5c184f-cb62-4ec7-a46e-38653b98f5bc -- 'If index_num is less than 1 or greater than the number of the last value in the list, CHOOSE returns the #VALUE! error value.'; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
CONCAT Google Sheets

=CONCAT(A1:B2)

Actual result
#N/A

Documented / expected
abcd

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'abcd', got '#N/A'
CONCAT Google Sheets

=CONCAT("a","b","c")

Actual result
#N/A

Documented / expected
abc

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'abc', got '#N/A'
CONCAT Google Sheets

=CONCAT(A1:A3)

Actual result
#N/A

Documented / expected
xyz

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'xyz', got '#N/A'
CONFIDENCE LibreOffice Calc

=CONFIDENCE(0,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If Alpha is <= 0 or >= 1, CONFIDENCE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE Google Sheets

=ROUND(CONFIDENCE(A2,A3,A4),9)

Actual result
0.692951913

Documented / expected
0.692951912

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Microsoft's page publishes this example's result as 0.692951912. Independently derived from the documented normal-distribution confidence half-width z_(1-alpha/2) * standard_dev / sqrt(size): scipy.stats.norm.isf(0.05/2) = 1.9599639845400545 (the +/-1.96 the page names in prose), so 1.9599639845400545 * 2.5 / sqrt(50) = 0.6929519121748391 -> 0.692951912 at 9 dp; MISMATCH vs expected: expected 0.692951912, got 0.692951913
CONFIDENCE LibreOffice Calc

=CONFIDENCE(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If Size < 1, CONFIDENCE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE Google Sheets

=ROUND(CONFIDENCE(A2,A3,50.9),9)

Actual result
0.692951913

Documented / expected
0.692951912

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Excel documents "If Size is not an integer, it is truncated", so 50.9 must behave exactly as 50 and return the documented 0.692951912. Independently checked that this discriminates: a genuine size of 50.9 would give 1.9599639845400545 * 2.5 / sqrt(50.9) = 0.686798; MISMATCH vs expected: expected 0.692951912, got 0.692951913
CONFIDENCE LibreOffice Calc

=CONFIDENCE(A2,0,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If Standard_dev <= 0, CONFIDENCE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE.NORM LibreOffice Calc

=CONFIDENCE.NORM(1,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or alpha >= 1, CONFIDENCE.NORM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE.NORM Google Sheets

=ROUND(CONFIDENCE.NORM(A2,A3,A4),9)

Actual result
0.692951913

Documented / expected
0.692951912

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft's CONFIDENCE.NORM page publishes this example's result rounded to 0.692952; its CONFIDENCE page publishes the identical calculation to more digits as 0.692951912, and the two agree. Independently derived from the documented normal-distribution half-width z_(1-alpha/2) * standard_dev / sqrt(size): scipy.stats.norm.isf(0.05/2) = 1.9599639845400545, so 1.9599639845400545 * 2.5 / sqrt(50) = 0.6929519121748391 -> 0.692951912 at 9 dp. Asserted at 9 dp rather than the page's 6 because the deeper figure is derived, not merely copied; MISMATCH vs expected: expected 0.692951912, got 0.692951913
CONFIDENCE.NORM LibreOffice Calc

=CONFIDENCE.NORM(A2,-1,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If standard_dev <= 0, CONFIDENCE.NORM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE.NORM LibreOffice Calc

=CONFIDENCE.NORM(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If size < 1, CONFIDENCE.NORM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE.NORM Google Sheets

=ROUND(CONFIDENCE.NORM(A2,A3,50.9),9)

Actual result
0.692951913

Documented / expected
0.692951912

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents "If size is not an integer, it is truncated", so 50.9 must behave exactly as 50. Independently checked that this discriminates: a genuine size of 50.9 would give 1.9599639845400545 * 2.5 / sqrt(50.9) = 0.686798; MISMATCH vs expected: expected 0.692951912, got 0.692951913
CONFIDENCE.T LibreOffice Calc

=CONFIDENCE.T(0,1,50)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or alpha >= 1, CONFIDENCE.T returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONFIDENCE.T Google Sheets

=CONFIDENCE.T(0.05,1,1)

Actual result
#NUM!

Documented / expected
#DIV/0!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If size equals 1, CONFIDENCE.T returns #DIV/0! error value." This is the one place the .T variant's error contract differs from CONFIDENCE.NORM's, which returns #NUM! only below size 1 and computes normally at size 1: with size 1 there are zero degrees of freedom for the t distribution; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
CONFIDENCE.T LibreOffice Calc

=CONFIDENCE.T(0.05,0,50)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If standard_dev <= 0, CONFIDENCE.T returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CONVERT_OOO Excel for the web

=ROUND(CONVERT_OOO(1,"EUR","DEM"),10)

Actual result
#NAME?

Documented / expected
1.95583

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Mathematical

THE PAGE PUBLISHES THE RULE BUT NOT THE RATES, SO THIS CASE CITES A SECOND AUTHORITY FOR THE NUMBER. LibreOffice's page states the semantics -- "Converts to euros a currency value expressed in one of the legacy currencies of 19 member states of the Eurozone, and vice versa. The conversion uses the fixed exchange rates at which the legacy currencies entered the euro" -- and prints two examples, =CONVERT_OOO(100;"ATS";"EUR") and =CONVERT_OOO(100;"EUR";"DEM"), BOTH OF WHICH ARE DESCRIBED IN WORDS RATHER THAN GIVEN A RESULT ("returns the euro value of 100 Austrian schillings"). The rates themselves are not on the page. The rate used here is the irrevocably fixed conversion rate adopted by the Council of the European Union, Council Regulation (EC) No 2866/98 of 31 December 1998 on the conversion rates between the euro and the currencies of the Member States adopting the euro: 1 EUR = 1.95583 DEM. That is a legal constant, not a market quotation, which is exactly why the page can call it fixed. The case is written EUR -> DEM so that the asserted number IS the published rate rather than its reciprocal. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CONVERT_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.; MISMATCH vs expected: expected 1.95583, got '#NAME?'
CONVERT_OOO Google Sheets

=ROUND(CONVERT_OOO(1,"EUR","DEM"),10)

Actual result
#NAME?

Documented / expected
1.95583

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Mathematical

THE PAGE PUBLISHES THE RULE BUT NOT THE RATES, SO THIS CASE CITES A SECOND AUTHORITY FOR THE NUMBER. LibreOffice's page states the semantics -- "Converts to euros a currency value expressed in one of the legacy currencies of 19 member states of the Eurozone, and vice versa. The conversion uses the fixed exchange rates at which the legacy currencies entered the euro" -- and prints two examples, =CONVERT_OOO(100;"ATS";"EUR") and =CONVERT_OOO(100;"EUR";"DEM"), BOTH OF WHICH ARE DESCRIBED IN WORDS RATHER THAN GIVEN A RESULT ("returns the euro value of 100 Austrian schillings"). The rates themselves are not on the page. The rate used here is the irrevocably fixed conversion rate adopted by the Council of the European Union, Council Regulation (EC) No 2866/98 of 31 December 1998 on the conversion rates between the euro and the currencies of the Member States adopting the euro: 1 EUR = 1.95583 DEM. That is a legal constant, not a market quotation, which is exactly why the page can call it fixed. The case is written EUR -> DEM so that the asserted number IS the published rate rather than its reciprocal. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's CONVERT_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.; MISMATCH vs expected: expected 1.95583, got '#NAME?'
CONVERT_OOO Excel for the web

=ROUND(CONVERT_OOO(CONVERT_OOO(100,"ATS","EUR"),"EUR","ATS"),8)

Actual result
#NAME?

Documented / expected
100

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Mathematical

A structural assertion with no constant from any source: whatever fixed rate the implementation holds for the Austrian schilling, converting to euros and back must return the original amount. This is the strongest claim that can be made from LibreOffice's page alone, since it prints the example but not its value. LibreOffice's CONVERT_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.; MISMATCH vs expected: expected 100, got '#NAME?'
CONVERT_OOO Google Sheets

=ROUND(CONVERT_OOO(CONVERT_OOO(100,"ATS","EUR"),"EUR","ATS"),8)

Actual result
#NAME?

Documented / expected
100

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Mathematical

A structural assertion with no constant from any source: whatever fixed rate the implementation holds for the Austrian schilling, converting to euros and back must return the original amount. This is the strongest claim that can be made from LibreOffice's page alone, since it prints the example but not its value. LibreOffice's CONVERT_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060106.html.; MISMATCH vs expected: expected 100, got '#NAME?'
COT LibreOffice Calc

=COT(2^27)

Actual result
-0.846108835418734

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COT returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds ignore this range check and return -0.846108835418734 instead of the documented error -- and that number is not garbage: cot(2^27) re-derived with mpmath at 60 digits is -0.84610883541873383485, so LibreOffice's argument reduction is accurate to full double precision here and it simply declines to refuse an input Excel refuses; MISMATCH vs expected: expected '#NUM!', got -0.846108835418734
COT LibreOffice Calc

=COT(0)

Actual result
#NUM!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "COT(0) returns the #DIV/0! error value." This follows from the documented identity COT(n) = 1/TAN(n) with TAN(0) = 0, and is a different error class from the #NUM! the same page specifies for out-of-range arguments. EXECUTED RESULT: all four LibreOffice builds return #NUM! here, i.e. they collapse the two documented error classes onto the out-of-range one; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
COTH Excel for the web

=COTH(2^27)

Actual result
1

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COTH returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. Mathematically coth(134217728) is indistinguishable from 1, so this case tests the documented range check rather than the arithmetic. EXECUTED RESULT: all four LibreOffice builds return 1 instead of the documented error, i.e. they answer the mathematics and ignore the range check; MISMATCH vs expected: expected '#NUM!', got 1
COTH LibreOffice Calc

=COTH(2^27)

Actual result
1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, COTH returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. Mathematically coth(134217728) is indistinguishable from 1, so this case tests the documented range check rather than the arithmetic. EXECUTED RESULT: all four LibreOffice builds return 1 instead of the documented error, i.e. they answer the mathematics and ignore the range check; MISMATCH vs expected: expected '#NUM!', got 1
COUNT LibreOffice Calc

=COUNT(A1:A1)

Actual result
1

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Per Microsoft's COUNT documentation, booleans in a referenced range are excluded from COUNT, unlike booleans typed directly as literal arguments; MISMATCH vs expected: expected 0, got 1
COUNT LibreOffice Calc

=COUNT(A1:A6)

Actual result
3

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

A3 and A6 are blank, A2 is text, A4 is a boolean cell; only A1=10 and A5=20 are counted; MISMATCH vs expected: expected 2, got 3
COUNTUNIQUE Excel for the web

=COUNTUNIQUE(1,1,2,3,5,8,13)

Actual result
#NAME?

Documented / expected
6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math

The page's Sample Usage prints COUNTUNIQUE(1,1,2,3,5,8,13,A2,B6:B9) and NO result. This case takes the literal head of that sample; 6 is DERIVED from the definition "Counts the number of unique values in a list of specified values and ranges" -- the seven arguments hold six distinct values because 1 appears twice. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 6, got '#NAME?'
COUNTUNIQUE LibreOffice Calc

=COUNTUNIQUE(1,1,2,3,5,8,13)

Actual result
#NAME?

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Math

The page's Sample Usage prints COUNTUNIQUE(1,1,2,3,5,8,13,A2,B6:B9) and NO result. This case takes the literal head of that sample; 6 is DERIVED from the definition "Counts the number of unique values in a list of specified values and ranges" -- the seven arguments hold six distinct values because 1 appears twice. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 6, got '#NAME?'
COUNTUNIQUE Excel for the web

=COUNTUNIQUE(1,1,2,3,5,8,13,A2,B6:B9)

Actual result
#NAME?

Documented / expected
9

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math

The page's own sample formula, with the cells it names populated by this corpus (Google leaves them unset). The union of {1,2,3,5,8,13}, {2} and {21,34,55,1} has nine distinct members -- A2's 2 and B9's 1 are both already present, which is the point of choosing them. DERIVED, not published. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 9, got '#NAME?'
COUNTUNIQUE LibreOffice Calc

=COUNTUNIQUE(1,1,2,3,5,8,13,A2,B6:B9)

Actual result
#NAME?

Documented / expected
9

Engine
LibreOffice Calc 25.8.7.3

Category
Math

The page's own sample formula, with the cells it names populated by this corpus (Google leaves them unset). The union of {1,2,3,5,8,13}, {2} and {21,34,55,1} has nine distinct members -- A2's 2 and B9's 1 are both already present, which is the point of choosing them. DERIVED, not published. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 9, got '#NAME?'
COUNTUNIQUE Excel for the web

=COUNTUNIQUE(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35)

Actual result
#NAME?

Documented / expected
35

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math

DERIVED FROM THE PAGE'S ONE NOTE, which is the only substantive claim it makes: "Although COUNTUNIQUE is specified as taking a maximum of 30 arguments, Google Sheets supports an arbitrary number of arguments for this function." Thirty-five distinct arguments therefore must count 35. Without that Note the same call would be a documented error rather than a documented value. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 35, got '#NAME?'
COUNTUNIQUE LibreOffice Calc

=COUNTUNIQUE(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35)

Actual result
#NAME?

Documented / expected
35

Engine
LibreOffice Calc 25.8.7.3

Category
Math

DERIVED FROM THE PAGE'S ONE NOTE, which is the only substantive claim it makes: "Although COUNTUNIQUE is specified as taking a maximum of 30 arguments, Google Sheets supports an arbitrary number of arguments for this function." Thirty-five distinct arguments therefore must count 35. Without that Note the same call would be a documented error rather than a documented value. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 35, got '#NAME?'
COUNTUNIQUE Excel for the web

=COUNTUNIQUE(A1:A5)

Actual result
#NAME?

Documented / expected
3

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math

Derived from the same definition; the page publishes no results and populates none of the cells its samples name. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 3, got '#NAME?'
COUNTUNIQUE LibreOffice Calc

=COUNTUNIQUE(A1:A5)

Actual result
#NAME?

Documented / expected
3

Engine
LibreOffice Calc 25.8.7.3

Category
Math

Derived from the same definition; the page publishes no results and populates none of the cells its samples name. Google's COUNTUNIQUE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093405.; MISMATCH vs expected: expected 3, got '#NAME?'
COUPDAYBS LibreOffice Calc

=COUPDAYBS(A2,A3,A4,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPDAYBS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYBS LibreOffice Calc

=COUPDAYBS(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPDAYBS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYBS LibreOffice Calc

=COUPDAYBS(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPDAYBS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYS LibreOffice Calc

=COUPDAYS(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPDAYS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYS LibreOffice Calc

=COUPDAYS(A2,A3,A4,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPDAYS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYS LibreOffice Calc

=COUPDAYS(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPDAYS returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYSNC LibreOffice Calc

=COUPDAYSNC(A2,A3,A4,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPDAYSNC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYSNC LibreOffice Calc

=COUPDAYSNC(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPDAYSNC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPDAYSNC LibreOffice Calc

=COUPDAYSNC(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPDAYSNC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNCD LibreOffice Calc

=COUPNCD(A2,A3,A4,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPNCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNCD LibreOffice Calc

=COUPNCD(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPNCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNCD LibreOffice Calc

=COUPNCD(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPNCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNUM LibreOffice Calc

=COUPNUM(A2,A3,A4,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPNUM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNUM LibreOffice Calc

=COUPNUM(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPNUM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPNUM LibreOffice Calc

=COUPNUM(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPNUM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPPCD LibreOffice Calc

=COUPPCD(A2,A3,A4,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, COUPPCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPPCD LibreOffice Calc

=COUPPCD(A2,A3,3,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, COUPPCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
COUPPCD LibreOffice Calc

=COUPPCD(A3,A2,A4,A5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, COUPPCD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CRITBINOM LibreOffice Calc

=CRITBINOM(A2,A3,1)

Actual result
6

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or alpha => 1, CRITBINOM returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds return 6 -- the trial count itself, since no cumulative probability strictly exceeds a criterion of exactly 1 until the last one -- rather than the documented error. As with the probability_s case, the modern BINOM.INV shows the same behaviour elsewhere in this corpus; MISMATCH vs expected: expected '#NUM!', got 6
CRITBINOM LibreOffice Calc

=CRITBINOM(-1,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If trials < 0, CRITBINOM returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
CRITBINOM LibreOffice Calc

=CRITBINOM(A2,0,A4)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability_s is <= 0 or probability_s => 1, CRITBINOM returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds return 0 rather than the documented error -- a plausible-looking answer for an input the documentation excludes. The same silent substitution was already recorded for CRITBINOM's modern replacement BINOM.INV elsewhere in this corpus, so it is the function family's behaviour and not a one-off; MISMATCH vs expected: expected '#NUM!', got 0
CSC LibreOffice Calc

=CSC(2^27)

Actual result
-1.30992372349448

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, CSC returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. EXECUTED RESULT: all four LibreOffice builds return -1.30992372349448 instead of the documented error; csc(2^27) re-derived with mpmath at 60 digits is -1.3099237234944811929, so the value is correct to full double precision and only the documented range check is missing; MISMATCH vs expected: expected '#NUM!', got -1.30992372349448
CSCH Excel for the web

=CSCH(2^27)

Actual result
0

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, CSCH returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. Mathematically csch(134217728) underflows to 0, so this case tests the documented range check rather than the arithmetic. EXECUTED RESULT: all four LibreOffice builds return 0 instead of the documented error, i.e. they answer the mathematics and ignore the range check; MISMATCH vs expected: expected '#NUM!', got 0
CSCH LibreOffice Calc

=CSCH(2^27)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "The absolute value of Number must be less than 2^27" and "If Number is outside its constraints, CSCH returns the #NUM! error value." 2^27 = 134217728 is exactly the excluded boundary. Mathematically csch(134217728) underflows to 0, so this case tests the documented range check rather than the arithmetic. EXECUTED RESULT: all four LibreOffice builds return 0 instead of the documented error, i.e. they answer the mathematics and ignore the range check; MISMATCH vs expected: expected '#NUM!', got 0
DATEDIF LibreOffice Calc

=DATEDIF(DATE(2024,1,10),DATE(2024,1,1),"D")

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Microsoft docs state end<start raises #NUM!; record engines' ACTUAL error code here since this is a known point of cross-engine divergence; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DAY Google Sheets

=DAY(1)

Actual result
31

Documented / expected
1

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1, got 31
DAY LibreOffice Calc

=DAY(1)

Actual result
31

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1, got 31
DAYSINMONTH Excel for the web

=DAYSINMONTH(DATE(2026,2,1))

Actual result
#NAME?

Documented / expected
28

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from "Calculates the number of days of the month in which the date entered occurs." 2026 is not divisible by 4, so February has 28 days. Paired with the published leap-year case above, this is what shows the function reads the YEAR of its argument and not just the month. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 28, got '#NAME?'
DAYSINMONTH Google Sheets

=DAYSINMONTH(DATE(2026,2,1))

Actual result
#NAME?

Documented / expected
28

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from "Calculates the number of days of the month in which the date entered occurs." 2026 is not divisible by 4, so February has 28 days. Paired with the published leap-year case above, this is what shows the function reads the YEAR of its argument and not just the month. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 28, got '#NAME?'
DAYSINMONTH Excel for the web

=DAYSINMONTH(DATE(1968,2,17))

Actual result
#NAME?

Documented / expected
29

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=DAYSINMONTH(A1) returns 29 days if A1 contains 1968-02-17, a valid date for February 1968." The published example passes the date through a cell reference; it is written here as DATE(1968,2,17) instead, because the page's own sibling entry ISLEAPYEAR warns in the same words that a date typed with slashes is evaluated as arithmetic ("Never use =ISLEAPYEAR(2/29/68), because this would first evaluate 2 divided by 29 divided by 68"), and DATE() is the locale-independent form that page recommends. Derived independently as well: 1968 is divisible by 4 and not by 100, so February has 29 days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 29, got '#NAME?'
DAYSINMONTH Google Sheets

=DAYSINMONTH(DATE(1968,2,17))

Actual result
#NAME?

Documented / expected
29

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=DAYSINMONTH(A1) returns 29 days if A1 contains 1968-02-17, a valid date for February 1968." The published example passes the date through a cell reference; it is written here as DATE(1968,2,17) instead, because the page's own sibling entry ISLEAPYEAR warns in the same words that a date typed with slashes is evaluated as arithmetic ("Never use =ISLEAPYEAR(2/29/68), because this would first evaluate 2 divided by 29 divided by 68"), and DATE() is the locale-independent form that page recommends. Derived independently as well: 1968 is divisible by 4 and not by 100, so February has 29 days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 29, got '#NAME?'
DAYSINMONTH Excel for the web

=DAYSINMONTH(DATE(2026,4,30))

Actual result
#NAME?

Documented / expected
30

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the same sentence. April has 30 days. The argument is the last day of the month, which is the boundary an off-by-one implementation would get wrong. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 30, got '#NAME?'
DAYSINMONTH Google Sheets

=DAYSINMONTH(DATE(2026,4,30))

Actual result
#NAME?

Documented / expected
30

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the same sentence. April has 30 days. The argument is the last day of the month, which is the boundary an off-by-one implementation would get wrong. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 30, got '#NAME?'
DAYSINMONTH Excel for the web

=DAYSINMONTH(DATE(2026,8,1))

Actual result
#NAME?

Documented / expected
31

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the same sentence. August has 31 days; the argument is the first day of the month, the other boundary. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 31, got '#NAME?'
DAYSINMONTH Google Sheets

=DAYSINMONTH(DATE(2026,8,1))

Actual result
#NAME?

Documented / expected
31

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the same sentence. August has 31 days; the argument is the first day of the month, the other boundary. LibreOffice's DAYSINMONTH help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 31, got '#NAME?'
DAYSINYEAR Excel for the web

=DAYSINYEAR(DATE(2100,7,4))

Actual result
#NAME?

Documented / expected
365

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the same sentence plus the Gregorian rule. 2100 is divisible by 100 but not by 400, so it is NOT a leap year -- the complement of the case above, and the one that catches an implementation testing divisibility by 4 alone. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 365, got '#NAME?'
DAYSINYEAR Google Sheets

=DAYSINYEAR(DATE(2100,7,4))

Actual result
#NAME?

Documented / expected
365

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the same sentence plus the Gregorian rule. 2100 is divisible by 100 but not by 400, so it is NOT a leap year -- the complement of the case above, and the one that catches an implementation testing divisibility by 4 alone. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 365, got '#NAME?'
DAYSINYEAR Excel for the web

=DAYSINYEAR(DATE(2000,7,4))

Actual result
#NAME?

Documented / expected
366

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the same sentence plus the Gregorian rule. 2000 is divisible by 400, so it IS a leap year -- the case that separates a correct implementation from one that only checks divisibility by 4 and 100. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 366, got '#NAME?'
DAYSINYEAR Google Sheets

=DAYSINYEAR(DATE(2000,7,4))

Actual result
#NAME?

Documented / expected
366

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the same sentence plus the Gregorian rule. 2000 is divisible by 400, so it IS a leap year -- the case that separates a correct implementation from one that only checks divisibility by 4 and 100. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 366, got '#NAME?'
DAYSINYEAR Excel for the web

=DAYSINYEAR(DATE(2026,1,1))

Actual result
#NAME?

Documented / expected
365

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from "Calculates the number of days of the year in which the date entered occurs." 2026 is not a leap year. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 365, got '#NAME?'
DAYSINYEAR Google Sheets

=DAYSINYEAR(DATE(2026,1,1))

Actual result
#NAME?

Documented / expected
365

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from "Calculates the number of days of the year in which the date entered occurs." 2026 is not a leap year. LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 365, got '#NAME?'
DAYSINYEAR Excel for the web

=DAYSINYEAR(DATE(1968,2,29))

Actual result
#NAME?

Documented / expected
366

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=DAYSINYEAR(A1) returns 366 days if A1 contains 1968-02-29, a valid date for the year 1968." Written with DATE() rather than a cell reference for the reason the sibling ISLEAPYEAR entry gives on the same page. Derived independently: 1968 is a leap year, so it has 366 days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 366, got '#NAME?'
DAYSINYEAR Google Sheets

=DAYSINYEAR(DATE(1968,2,29))

Actual result
#NAME?

Documented / expected
366

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=DAYSINYEAR(A1) returns 366 days if A1 contains 1968-02-29, a valid date for the year 1968." Written with DATE() rather than a cell reference for the reason the sibling ISLEAPYEAR entry gives on the same page. Derived independently: 1968 is a leap year, so it has 366 days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's DAYSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 366, got '#NAME?'
DBCS Google Sheets

=DBCS("ＥＸＣＥＬ")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
DBCS LibreOffice Calc

=DBCS("ＥＸＣＥＬ")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. This case is unambiguous under either reading of the page: the argument contains no half-width English letters or katakana, so the documented no-change clause applies and the result is the argument itself. EXECUTED RESULT: #NAME? on all four LibreOffice builds; see DBCS_halfwidth_latin_to_fullwidth for the three-spelling probe and for LibreOffice's JIS equivalent.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
DBCS Excel for the web

=DBCS("EXCEL")

Actual result
EXCEL

Documented / expected
ＥＸＣＥＬ

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got 'EXCEL'
DBCS Google Sheets

=DBCS("EXCEL")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
DBCS LibreOffice Calc

=DBCS("EXCEL")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's DBCS page documents the rule as: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and adds "If text does not contain any half-width English letters or katakana, text is not changed". The page also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. PUBLISHED EXAMPLE CONTRADICTS THE PUBLISHED RULE: the page's first worked example reads '=DBCS("EXCEL") equals "EXCEL"', i.e. it shows the argument coming back unchanged -- which is the documented behaviour of the INVERSE function ASC, whose page carries the identical line, and is impossible under DBCS's own stated rule because "EXCEL" is five half-width English letters. The value asserted here is derived from the rule instead: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E X C E L), exactly the inverse of the mapping batch A's ASC cases assert in the other direction. The page's second example, which does show a conversion, is rendered as inline GIF images (media/fe337.gif ...) so no literal argument can be copied from it. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? -- and a name-form probe confirms this is a genuine gap rather than a storage-prefix artefact: the plain name, the _xlfn. storage form and the COM.MICROSOFT. add-in form all return #NAME? on every build. LibreOffice nevertheless PERFORMS this conversion under a different name: on all four builds '=JIS("EXCEL")' returns exactly the full-width string asserted here, which independently confirms both the derived expected value and that the gap is a missing alias, not a missing capability.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
DBCS Google Sheets

=LEN(DBCS("EXCEL"))

Actual result
#NAME?

Documented / expected
5

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.; MISMATCH vs expected: expected 5, got '#NAME?'
DBCS LibreOffice Calc

=LEN(DBCS("EXCEL"))

Actual result
#NAME?

Documented / expected
5

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents DBCS as changing half-width characters to full-width characters -- a one-for-one character mapping, not an encoding change -- so a five-character input yields a five-character result whether or not the mapping fires. This is the mirror of batch A's ASC_length_preserved case and separates a genuine width conversion from a byte-level reinterpretation. EXECUTED RESULT: #NAME? on all four LibreOffice builds -- LEN is supported, so the unrecognized name is DBCS.; MISMATCH vs expected: expected 5, got '#NAME?'
DBCS Google Sheets

=ASC(DBCS("EXCEL"))

Actual result
#NAME?

Documented / expected
EXCEL

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
DBCS LibreOffice Calc

=ASC(DBCS("EXCEL"))

Actual result
#NAME?

Documented / expected
EXCEL

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Deliberately locale-independent, and the reason this case exists. If DBCS converts (the documented rule), ASC converts back and the result is "EXCEL"; if DBCS is a no-op under a non-DBCS default language, ASC leaves the already-half-width text alone and the result is still "EXCEL". Both readings of Microsoft's page agree here, so a failure of this case cannot be blamed on the harness locale -- it can only mean the engine lacks one of the two functions or mangles the text. EXECUTED RESULT: #NAME? on all four LibreOffice builds. Because ASC itself is supported there (batch A executed it), the failure is entirely DBCS's, which is what this locale-independent case was built to establish.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
DCOUNTA Google Sheets

=DCOUNTA(A6:E12,,A3:F4)

Actual result
#VALUE!

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Database

Microsoft documents: "The field argument is optional. If field is omitted, DCOUNTA counts all records in the database that match the criteria." The same criteria as the documented example match exactly one record, so the count is 1 with or without the field. This case exists because an engine that treats the middle argument as required fails here while passing the documented example. Set up from Microsoft's own worked example for the database functions: the orchard table, which is one criteria header row, two criteria rows, a database header row and six records. HARNESS PLACEMENT: the page pastes the table at A1, but this harness writes the formula under test into cell F1, which the table's second "Height" criteria header would occupy, so the whole block is pasted two rows lower instead. Every relative offset the page describes is preserved -- the database header is still the row immediately below the last criteria row -- which puts the criteria at A3:F5 and the database at A6:E12 here. One further deviation: the page writes its tree criteria as the cell entry ="=Apple" (the documented trick for storing the literal text =Apple, which forces an exact match). openpyxl cannot author that cell -- any string beginning with = is serialized as a formula -- so the criteria cells here hold the plain text Apple and Pear. On this data the two forms select the same records, because no other tree name in the table begins with "Apple" or "Pear".; MISMATCH vs expected: expected 1, got '#VALUE!'
DGET LibreOffice Calc

=DGET(A1:B4,"Sales",D1:D2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Database

MISMATCH vs expected: expected #NUM!, got #VALUE!
DISC LibreOffice Calc

=DISC(DATE(2018,7,1),DATE(2048,1,1),97.975,100,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents five bases (0-4) and: "If basis < 0 or if basis > 4, DISC returns the #NUM! error value." 5 is the first excluded value. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DISC Google Sheets

=ROUND(DISC(DATE(2018,7,1),DATE(2048,1,1),97.975,100,1),12)

Actual result
0.000686345065

Documented / expected
0.000686384169

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

MICROSOFT-PUBLISHED RESULT CORRECTED. The page's example data is settlement 07/01/2018, maturity 01/01/2048, price 97.975, redemption 100, basis 1 (actual/actual), and it publishes the result 0.001038. That figure does not belong to those inputs. Derived independently from the formula the page itself states, DISC = ((redemption - pr)/redemption) * (B/DSM): (100 - 97.975)/100 = 0.02025, DSM = 10776 actual days from 2018-07-01 to 2048-01-01, and B under the documented actual/actual basis is the average length of the calendar years spanned, giving a year fraction of 29.50242868497748 and a discount rate of 0.0006863841691213483. The published 0.001038 is reproducible only by moving the maturity back ten years: with maturity 01/01/2038 the same arithmetic gives 0.0010381908237747707, which rounds to exactly the printed 0.001038. The published number is therefore a stale figure left behind when the example's dates were rolled forward, not a rounding of the correct answer, so the correct value is asserted here and the discrepancy recorded rather than buried. Asserted at 12 decimal places (0.000686384169), which is roughly 9 significant digits of the independently derived value and well inside double precision; the ROUND() wrapper keeps the assertion free of last-bit formatting differences. EXECUTED RESULT: all four LibreOffice builds return 0.000686384169121348, matching the independently derived value to full double precision -- so LibreOffice agrees with the derivation and with the page's stated inputs, and it is Microsoft's printed 0.001038 that stands alone.; MISMATCH vs expected: expected 0.000686384169, got 0.000686345065
DISC LibreOffice Calc

=DISC(DATE(2018,7,1),DATE(2048,1,1),0,100,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If pr <= 0 or if redemption <= 0, DISC returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DISC LibreOffice Calc

=DISC(DATE(2048,1,1),DATE(2018,7,1),97.975,100,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, DISC returns the #NUM! error value." The example's two dates are simply swapped here. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DIVIDE Excel for the web

=DIVIDE(A2,B2)

Actual result
#NAME?

Documented / expected
2.25

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the same definition; the page publishes no results. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 2.25, got '#NAME?'
DIVIDE LibreOffice Calc

=DIVIDE(A2,B2)

Actual result
#NAME?

Documented / expected
2.25

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the same definition; the page publishes no results. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 2.25, got '#NAME?'
DIVIDE Excel for the web

=DIVIDE(4,2)

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints DIVIDE(4,2) with no result; 2 is DERIVED from the page's definition, "Returns one number divided by another. Equivalent to the `/` operator." Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 2, got '#NAME?'
DIVIDE LibreOffice Calc

=DIVIDE(4,2)

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints DIVIDE(4,2) with no result; 2 is DERIVED from the page's definition, "Returns one number divided by another. Equivalent to the `/` operator." Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 2, got '#NAME?'
DIVIDE Excel for the web

=DIVIDE(A2,B2)-(A2/B2)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from the `/` operator equivalence. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0, got '#NAME?'
DIVIDE LibreOffice Calc

=DIVIDE(A2,B2)-(A2/B2)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from the `/` operator equivalence. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0, got '#NAME?'
DIVIDE Excel for the web

=DIVIDE(7,2)-QUOTIENT(7,2)

Actual result
#NAME?

Documented / expected
0.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

THE PAGE CONTRADICTS ITSELF AND THIS CASE ASSERTS THE SIDE THAT WINS. The Notes section says flatly: "DIVIDE is equivalent to QUOTIENT." The same page's own See-also list describes QUOTIENT as "Returns one number divided by another, WITHOUT THE REMAINDER", and the page's headline definition equates DIVIDE with the `/` operator. Those cannot both hold: 7/2 is 3.5 and QUOTIENT(7,2) is 3, so the difference is 0.5, not 0. This corpus asserts 0.5 -- the value implied by the two statements that agree with each other -- and records the Notes bullet as wrong rather than quietly asserting around it. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0.5, got '#NAME?'
DIVIDE LibreOffice Calc

=DIVIDE(7,2)-QUOTIENT(7,2)

Actual result
#NAME?

Documented / expected
0.5

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

THE PAGE CONTRADICTS ITSELF AND THIS CASE ASSERTS THE SIDE THAT WINS. The Notes section says flatly: "DIVIDE is equivalent to QUOTIENT." The same page's own See-also list describes QUOTIENT as "Returns one number divided by another, WITHOUT THE REMAINDER", and the page's headline definition equates DIVIDE with the `/` operator. Those cannot both hold: 7/2 is 3.5 and QUOTIENT(7,2) is 3, so the difference is 0.5, not 0. This corpus asserts 0.5 -- the value implied by the two statements that agree with each other -- and records the Notes bullet as wrong rather than quietly asserting around it. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0.5, got '#NAME?'
DIVIDE Excel for the web

=ROUND(DIVIDE(1,3),9)

Actual result
#NAME?

Documented / expected
0.333333333

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the `/` equivalence and ROUND-wrapped. The page states that divisor "cannot equal 0" but names NO error value for that case, so this corpus asserts nothing about division by zero. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0.333333333, got '#NAME?'
DIVIDE LibreOffice Calc

=ROUND(DIVIDE(1,3),9)

Actual result
#NAME?

Documented / expected
0.333333333

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the `/` equivalence and ROUND-wrapped. The page states that divisor "cannot equal 0" but names NO error value for that case, so this corpus asserts nothing about division by zero. Google's DIVIDE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093973.; MISMATCH vs expected: expected 0.333333333, got '#NAME?'
DOLLARDE LibreOffice Calc

=DOLLARDE(1.02,-4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if fraction is less than 0; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DOLLARDE LibreOffice Calc

=DOLLARDE(1.02,0)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Verbatim from Microsoft: 'If fraction is greater than or equal to 0 and less than 1, DOLLARDE returns the #DIV/0! error value.' Note the band is 0 <= fraction < 1, which is worded more widely than DOLLARFR's page (which names only fraction = 0) even though truncation makes the two equivalent in practice; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
DOLLARFR LibreOffice Calc

=DOLLARFR(1.125,-4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if fraction is less than 0; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DOLLARFR LibreOffice Calc

=DOLLARFR(1.125,0)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Verbatim from Microsoft: 'If fraction is 0, DOLLARFR returns the #DIV/0! error value.' The DOLLARDE page words the same condition as the wider band 0 <= fraction < 1; because fraction is truncated first the two are equivalent, but the published wording differs between the pages; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
DROP Google Sheets

=DROP(A1:C3,1,1)

Actual result
{#NAME?, , , }

Documented / expected
{{5, 6}, {8, 9}}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 5, got '#NAME?'
DSTDEV LibreOffice Calc

=DSTDEV(A6:E12,"Yield",H3:H4)

Actual result
#NUM!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Database

Not spelled out on the DSTDEV page, which lists no error conditions at all; derived from the documented definition instead. DSTDEV "estimates the standard deviation of a population based on a sample", i.e. the n-1 denominator estimator, and the criteria block in H3:H4 selects exactly one record (the cherry), making that denominator zero. Excel's documented behaviour for the same n-1-denominator situation in its non-database sibling STDEV is #DIV/0!, and that is the value asserted here; an engine returning 0 instead is claiming a sample of one has no spread rather than an undefined one. Set up from Microsoft's own worked example for the database functions: the orchard table, which is one criteria header row, two criteria rows, a database header row and six records. HARNESS PLACEMENT: the page pastes the table at A1, but this harness writes the formula under test into cell F1, which the table's second "Height" criteria header would occupy, so the whole block is pasted two rows lower instead. Every relative offset the page describes is preserved -- the database header is still the row immediately below the last criteria row -- which puts the criteria at A3:F5 and the database at A6:E12 here. One further deviation: the page writes its tree criteria as the cell entry ="=Apple" (the documented trick for storing the literal text =Apple, which forces an exact match). openpyxl cannot author that cell -- any string beginning with = is serialized as a formula -- so the criteria cells here hold the plain text Apple and Pear. On this data the two forms select the same records, because no other tree name in the table begins with "Apple" or "Pear". EXECUTED RESULT: all four LibreOffice builds return #NUM! rather than the #DIV/0! this estimator's zero denominator calls for -- an error-CLASS collapse (a division by zero reported as an out-of-range argument), not a computation difference. Both engines agree that the case is an error; they disagree about which one, exactly as batch B recorded for COT(0).; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
DURATION LibreOffice Calc

=DURATION(DATE(2018,7,1),DATE(2048,1,1),0.08,0.09,2,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents five bases (0-4) and: "If basis < 0 or if basis > 4, DURATION returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DURATION LibreOffice Calc

=ROUND(DURATION(DATE(2018,7,1),DATE(2048,1,1),0.08,0.09,2,1),7)

Actual result
10.921574

Documented / expected
10.9191453

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft's page publishes this example's result as 10.9191453. Derived independently from the documented definition, "the Macauley duration for an assumed par value of $100 ... the weighted average of the present value of cash flows". Settlement 2018-07-01 falls exactly on a coupon date of the 2048-01-01 maturity at semiannual frequency, so there are 59 remaining coupons at times 0.5, 1.0, ... 29.5 years; discounting each 4.00 coupon (plus 100 redemption at t = 29.5) at 9% nominal semiannual and taking the cash-flow-weighted mean time gives 10.919145281591925, which rounds to the published 10.9191453 at 7 dp. EXECUTED RESULT -- SILENT WRONG VALUE, the most serious class in this batch. All four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return 10.9215739665694 where both Microsoft's published figure and the independent derivation give 10.919145281591925: a plausible number, no error, wrong in the third decimal (2.2e-4 relative). The mechanism is pinned down exactly rather than guessed. The discrepancy is 10.9215739665694 - 10.9191452815919 = 0.0024286849775, and YEARFRAC over the same two dates on the same basis 1 returns 29.5024286849775 where the coupon schedule gives 59 coupons / 2 per year = 29.5 exactly -- the excess, 0.0024286849775, matches the error to twelve digits. LibreOffice is therefore taking the cash-flow times from an actual/actual year fraction instead of from the coupon count, which shifts EVERY cash flow later by the same amount and so shifts the weighted average by that amount. The companion case DURATION_basis_30_360 is the control: on basis 0, where YEARFRAC over these dates is exactly 29.5, all four builds return 10.9191452815919 and agree with the documented value.; MISMATCH vs expected: expected 10.9191453, got 10.921574
DURATION LibreOffice Calc

=DURATION(DATE(2018,7,1),DATE(2048,1,1),0.08,0.09,3,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, DURATION returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DURATION LibreOffice Calc

=DURATION(DATE(2018,7,1),DATE(2048,1,1),-0.08,0.09,2,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If coupon < 0 or if yld < 0, DURATION returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DURATION LibreOffice Calc

=DURATION(DATE(2048,1,1),DATE(2018,7,1),0.08,0.09,2,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, DURATION returns the #NUM! error value." The example's two dates are simply swapped. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
DVAR LibreOffice Calc

=DVAR(A6:E12,"Yield",H3:H4)

Actual result
#NUM!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Database

Not spelled out on the DVAR page, which lists no error conditions; derived from the documented n-1 sample estimator, whose denominator is zero when the criteria select a single record (here the cherry). Excel's documented behaviour in the same situation for the non-database sibling VAR is #DIV/0!. Set up from Microsoft's own worked example for the database functions: the orchard table, which is one criteria header row, two criteria rows, a database header row and six records. HARNESS PLACEMENT: the page pastes the table at A1, but this harness writes the formula under test into cell F1, which the table's second "Height" criteria header would occupy, so the whole block is pasted two rows lower instead. Every relative offset the page describes is preserved -- the database header is still the row immediately below the last criteria row -- which puts the criteria at A3:F5 and the database at A6:E12 here. One further deviation: the page writes its tree criteria as the cell entry ="=Apple" (the documented trick for storing the literal text =Apple, which forces an exact match). openpyxl cannot author that cell -- any string beginning with = is serialized as a formula -- so the criteria cells here hold the plain text Apple and Pear. On this data the two forms select the same records, because no other tree name in the table begins with "Apple" or "Pear". EXECUTED RESULT: all four LibreOffice builds return #NUM! rather than #DIV/0!, the same error-class collapse as DSTDEV_single_record_div0 on the same one-record sample.; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
EASTERSUNDAY Excel for the web

=EASTERSUNDAY(2026)-DATE(2026,4,5)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED, not published: the page publishes only the year 2000. Easter Sunday 2026 falls on 5 April by the Gregorian computus, computed independently here with the Meeus/Jones/Butcher algorithm. This is the case that tests the function rather than one memorised answer. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Google Sheets

=EASTERSUNDAY(2026)-DATE(2026,4,5)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED, not published: the page publishes only the year 2000. Easter Sunday 2026 falls on 5 April by the Gregorian computus, computed independently here with the Meeus/Jones/Butcher algorithm. This is the case that tests the function rather than one memorised answer. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Excel for the web

=EASTERSUNDAY(2026)-2-DATE(2026,4,3)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

A structural assertion with no derived constant beyond the Easter date above, from the page's own list: "Good Friday = EASTERSUNDAY(Year) - 2". Good Friday 2026 is therefore 3 April. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Google Sheets

=EASTERSUNDAY(2026)-2-DATE(2026,4,3)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

A structural assertion with no derived constant beyond the Easter date above, from the page's own list: "Good Friday = EASTERSUNDAY(Year) - 2". Good Friday 2026 is therefore 3 April. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Excel for the web

=EASTERSUNDAY(2000)-DATE(2000,4,23)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=EASTERSUNDAY(2000) returns 2000-04-23." Asserted as a difference against DATE(2000,4,23) so the case depends on neither the locale's date format nor on whether the engine hands the harness a date object or a serial number -- the two published examples above and here therefore check the same underlying value through two independent routes. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Google Sheets

=EASTERSUNDAY(2000)-DATE(2000,4,23)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "=EASTERSUNDAY(2000) returns 2000-04-23." Asserted as a difference against DATE(2000,4,23) so the case depends on neither the locale's date format nor on whether the engine hands the harness a date object or a serial number -- the two published examples above and here therefore check the same underlying value through two independent routes. LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 0, got '#NAME?'
EASTERSUNDAY Excel for the web

=EASTERSUNDAY(2000)+49

Actual result
#NAME?

Documented / expected
36688

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, and the only figure on the page given as a number rather than as a date: "=EASTERSUNDAY(2000)+49 returns the internal serial number 36688. The result is 2000-06-11." It is quoted here in the exact form the page prints it -- with the +49 -- rather than back-solved to the Easter serial itself, so the assertion is the published one. Derived independently: Easter Sunday 2000 falls on 23 April by the Gregorian computus (Meeus/Jones/Butcher algorithm, computed here rather than looked up), which is serial 36639 in the 1899-12-30-origin system, and 36639 + 49 = 36688, matching the printed figure exactly. 49 days is the offset the page itself gives for Pentecost Sunday. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 36688, got '#NAME?'
EASTERSUNDAY Google Sheets

=EASTERSUNDAY(2000)+49

Actual result
#NAME?

Documented / expected
36688

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, and the only figure on the page given as a number rather than as a date: "=EASTERSUNDAY(2000)+49 returns the internal serial number 36688. The result is 2000-06-11." It is quoted here in the exact form the page prints it -- with the +49 -- rather than back-solved to the Easter serial itself, so the assertion is the published one. Derived independently: Easter Sunday 2000 falls on 23 April by the Gregorian computus (Meeus/Jones/Butcher algorithm, computed here rather than looked up), which is serial 36639 in the 1899-12-30-origin system, and 36639 + 49 = 36688, matching the printed figure exactly. 49 days is the offset the page itself gives for Pentecost Sunday. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's EASTERSUNDAY help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_eastersunday.html.; MISMATCH vs expected: expected 36688, got '#NAME?'
ENCODEURL LibreOffice Calc

=ENCODEURL("http://contoso.sharepoint.com/Finance/Profit and Loss Statement.xlsx")

Actual result
http%3A%2F%2Fcontoso%2Esharepoint%2Ecom%2FFinance%2FProfit%20and%20Loss%20Statement%2Exlsx

Documented / expected
http%3A%2F%2Fcontoso.sharepoint.com%2FFinance%2FProfit%20and%20Loss%20Statement.xlsx

Engine
LibreOffice Calc 25.8.7.3

Category
Web

Microsoft's page publishes this example verbatim, argument and result. Re-derived character by character from the documented rule ("returns a URL-encoded string, replacing certain non-alphanumeric characters with the percentage symbol (%) and a hexadecimal number"): the colon becomes %3A, each forward slash %2F and each space %20, while the letters, digits and -- decisively for this case -- the PERIODS are left literal. The published result keeps "contoso.sharepoint.com" and ".xlsx" unencoded, so the period is one of the non-alphanumeric characters Excel deliberately does not escape. EXECUTED RESULT -- SILENT WRONG VALUE. All four LibreOffice builds return 'http%3A%2F%2Fcontoso%2Esharepoint%2Ecom%2FFinance%2FProfit%20and%20Loss%20Statement%2Exlsx': identical to the documented result except that every PERIOD has been percent-encoded as %2E, which Microsoft's published example leaves literal. No error is raised and the string is still a decodable URL, so the difference survives into any downstream comparison, cache key or signature that expects Excel's output byte for byte. The period is an unreserved character in RFC 3986, so encoding it is legal but not what Excel does.; MISMATCH vs expected: expected 'http%3A%2F%2Fcontoso.sharepoint.com%2FFinance%2FProfit%20and%20Loss%20Statement.xlsx', got 'http%3A%2F%2Fcontoso%2Esharepoint%2Ecom%2FFinance%2FProfit%20and%20Loss%20Statement%2Exlsx'
EPOCHTODATE Excel for the web

=ROUND(EPOCHTODATE(0,2),6)

Actual result
#NAME?

Documented / expected
25569

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

A PUBLISHED CONSTANT THAT IS WRONG, CONTRADICTED BY THE PAGE'S OWN EXAMPLE TABLE. The last Notes bullet reads: "The result is computed by dividing the timestamp (converted to milliseconds) by the number of milliseconds in a day and adding 25,568." For timestamp 0 that recipe yields serial 25,568. But the same page's example table prints timestamp 0 -> 1/1/1970 0:00:00, and in the 1899-12-30-origin serial system Google Sheets uses, 1970-01-01 is serial 25569, not 25568: (1970-01-01) - (1899-12-30) = 25569 days, verified independently. The constant in the Notes is one day short. This corpus asserts 25569 -- the value the page's own worked example requires -- and records the Notes bullet as the error. The bullet was re-read on a second, separate fetch on 2026-08-31 to rule out a transcription slip; it says 25,568 both times. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 25569, got '#NAME?'
EPOCHTODATE LibreOffice Calc

=ROUND(EPOCHTODATE(0,2),6)

Actual result
#NAME?

Documented / expected
25569

Engine
LibreOffice Calc 25.8.7.3

Category
Date

A PUBLISHED CONSTANT THAT IS WRONG, CONTRADICTED BY THE PAGE'S OWN EXAMPLE TABLE. The last Notes bullet reads: "The result is computed by dividing the timestamp (converted to milliseconds) by the number of milliseconds in a day and adding 25,568." For timestamp 0 that recipe yields serial 25,568. But the same page's example table prints timestamp 0 -> 1/1/1970 0:00:00, and in the 1899-12-30-origin serial system Google Sheets uses, 1970-01-01 is serial 25569, not 25568: (1970-01-01) - (1899-12-30) = 25569 days, verified independently. The constant in the Notes is one day short. This corpus asserts 25569 -- the value the page's own worked example requires -- and records the Notes bullet as the error. The bullet was re-read on a second, separate fetch on 2026-08-31 to rule out a transcription slip; it says 25,568 both times. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 25569, got '#NAME?'
EPOCHTODATE Excel for the web

=TEXT(EPOCHTODATE(1584033897),"yyyy-mm-dd hh:mm:ss")

Actual result
#NAME?

Documented / expected
2020-03-12 17:24:57

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1584033897 with =EPOCHTODATE(A5) -> 3/12/2020 17:24:57. Independently recomputed as 2020-03-12T17:24:57Z. This is the row that pins the default, and the Note agrees: "Seconds is the default unit of time." Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected '2020-03-12 17:24:57', got '#NAME?'
EPOCHTODATE LibreOffice Calc

=TEXT(EPOCHTODATE(1584033897),"yyyy-mm-dd hh:mm:ss")

Actual result
#NAME?

Documented / expected
2020-03-12 17:24:57

Engine
LibreOffice Calc 25.8.7.3

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1584033897 with =EPOCHTODATE(A5) -> 3/12/2020 17:24:57. Independently recomputed as 2020-03-12T17:24:57Z. This is the row that pins the default, and the Note agrees: "Seconds is the default unit of time." Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected '2020-03-12 17:24:57', got '#NAME?'
EPOCHTODATE Excel for the web

=ROUND((EPOCHTODATE(1656356678000410,3)-DATE(2022,6,27))*86400,3)

Actual result
#NAME?

Documented / expected
68678.0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1656356678000410 with =EPOCHTODATE(A6,3) -> 6/27/2022 19:04:38. Independently recomputed as 2022-06-27T19:04:38.000410Z, i.e. 19*3600 + 4*60 + 38 = 68678 seconds past midnight. Asserted at three decimals, ONE THOUSAND TIMES COARSER than the input's resolution, deliberately: 410 microseconds is far below what a day-based serial number can carry, so asserting it would test the float, not the function. What this case does establish is that unit 3 divides by a million -- any other unit puts the result in a different year. "Negative timestamps aren't accepted" is the page's only other constraint and it names no error value, so nothing is asserted about negative input. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 68678.0, got '#NAME?'
EPOCHTODATE LibreOffice Calc

=ROUND((EPOCHTODATE(1656356678000410,3)-DATE(2022,6,27))*86400,3)

Actual result
#NAME?

Documented / expected
68678.0

Engine
LibreOffice Calc 25.8.7.3

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1656356678000410 with =EPOCHTODATE(A6,3) -> 6/27/2022 19:04:38. Independently recomputed as 2022-06-27T19:04:38.000410Z, i.e. 19*3600 + 4*60 + 38 = 68678 seconds past midnight. Asserted at three decimals, ONE THOUSAND TIMES COARSER than the input's resolution, deliberately: 410 microseconds is far below what a day-based serial number can carry, so asserting it would test the float, not the function. What this case does establish is that unit 3 divides by a million -- any other unit puts the result in a different year. "Negative timestamps aren't accepted" is the page's only other constraint and it names no error value, so nothing is asserted about negative input. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 68678.0, got '#NAME?'
EPOCHTODATE Excel for the web

=ROUND((EPOCHTODATE(1655906568893,2)-DATE(2022,6,22))*86400,3)

Actual result
#NAME?

Documented / expected
50568.893

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

GOOGLE'S OWN PUBLISHED ROW, ASSERTED BELOW THE PRECISION IT DISPLAYS. The table prints timestamp 1655906568893 with =EPOCHTODATE(A2,2) -> 6/22/2022 14:02:49, but 1655906568.893 s after the epoch is 14:02:48.893 UTC, not 14:02:49 -- the published cell is the DISPLAY of a value whose seconds field has been rounded by the cell's number format, not a different value. This case asserts the underlying quantity as seconds past midnight, 14*3600 + 2*60 + 48.893 = 50568.893, which is consistent with the published display and with the Note "Fractional amounts of milliseconds are shortened". Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 50568.893, got '#NAME?'
EPOCHTODATE LibreOffice Calc

=ROUND((EPOCHTODATE(1655906568893,2)-DATE(2022,6,22))*86400,3)

Actual result
#NAME?

Documented / expected
50568.893

Engine
LibreOffice Calc 25.8.7.3

Category
Date

GOOGLE'S OWN PUBLISHED ROW, ASSERTED BELOW THE PRECISION IT DISPLAYS. The table prints timestamp 1655906568893 with =EPOCHTODATE(A2,2) -> 6/22/2022 14:02:49, but 1655906568.893 s after the epoch is 14:02:48.893 UTC, not 14:02:49 -- the published cell is the DISPLAY of a value whose seconds field has been rounded by the cell's number format, not a different value. This case asserts the underlying quantity as seconds past midnight, 14*3600 + 2*60 + 48.893 = 50568.893, which is consistent with the published display and with the Note "Fractional amounts of milliseconds are shortened". Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 50568.893, got '#NAME?'
EPOCHTODATE Excel for the web

=TEXT(EPOCHTODATE(1655906710,1),"yyyy-mm-dd hh:mm:ss")

Actual result
#NAME?

Documented / expected
2022-06-22 14:05:10

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1655906710 with =EPOCHTODATE(A3,1) -> 6/22/2022 14:05:10. Independently recomputed as 1970-01-01T00:00:00Z + 1655906710 s = 2022-06-22T14:05:10Z. Asserted through TEXT with an explicit unambiguous pattern rather than against the page's US-format display string, so that a cell's number format cannot decide the case. The Note that makes UTC the right frame reads: "The result will be in UTC, not the local time zone of your spreadsheet." EPOCHTODATE's page carries a real Timestamp/Result/Formula table in the article body, so the five rows below are Google's own published outputs rather than derivations. Each was independently recomputed here from the Unix epoch in UTC before being written down, and all five reproduce. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '2022-06-22 14:05:10', got '#NAME?'
EPOCHTODATE LibreOffice Calc

=TEXT(EPOCHTODATE(1655906710,1),"yyyy-mm-dd hh:mm:ss")

Actual result
#NAME?

Documented / expected
2022-06-22 14:05:10

Engine
LibreOffice Calc 25.8.7.3

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 1655906710 with =EPOCHTODATE(A3,1) -> 6/22/2022 14:05:10. Independently recomputed as 1970-01-01T00:00:00Z + 1655906710 s = 2022-06-22T14:05:10Z. Asserted through TEXT with an explicit unambiguous pattern rather than against the page's US-format display string, so that a cell's number format cannot decide the case. The Note that makes UTC the right frame reads: "The result will be in UTC, not the local time zone of your spreadsheet." EPOCHTODATE's page carries a real Timestamp/Result/Formula table in the article body, so the five rows below are Google's own published outputs rather than derivations. Each was independently recomputed here from the Unix epoch in UTC before being written down, and all five reproduce. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '2022-06-22 14:05:10', got '#NAME?'
EPOCHTODATE Excel for the web

=EPOCHTODATE(0,2)-DATE(1970,1,1)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 0 with =EPOCHTODATE(A4,2) -> 1/1/1970 0:00:00. Asserted as a difference against DATE(1970,1,1) so that no date format enters the comparison. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 0, got '#NAME?'
EPOCHTODATE LibreOffice Calc

=EPOCHTODATE(0,2)-DATE(1970,1,1)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Date

GOOGLE'S OWN PUBLISHED RESULT: timestamp 0 with =EPOCHTODATE(A4,2) -> 1/1/1970 0:00:00. Asserted as a difference against DATE(1970,1,1) so that no date format enters the comparison. Google's EPOCHTODATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/13193461.; MISMATCH vs expected: expected 0, got '#NAME?'
EQ Excel for the web

=EQ("a","A")=("a"="A")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected True, got '#NAME?'
EQ LibreOffice Calc

=EQ("a","A")=("a"="A")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected True, got '#NAME?'
EQ Excel for the web

=EQ(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected False, got '#NAME?'
EQ LibreOffice Calc

=EQ(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected False, got '#NAME?'
EQ Excel for the web

=EQ(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints EQ(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `=` operator" clause. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
EQ LibreOffice Calc

=EQ(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints EQ(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `=` operator" clause. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
EQ Excel for the web

=EQ(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `=` equivalence. This is the case that separates EQ from its neighbours, and Google publishes no example of it. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected True, got '#NAME?'
EQ LibreOffice Calc

=EQ(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `=` equivalence. This is the case that separates EQ from its neighbours, and Google publishes no example of it. Google's EQ page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093593.; MISMATCH vs expected: expected True, got '#NAME?'
ERROR.TYPE Google Sheets

=ERROR.TYPE(A1:A2 C1:C2)

Actual result
#ERROR!

Documented / expected
1

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Information

#NULL!=1 confirmed via https://support.microsoft.com/en-us/office/error-type-function-10958677-7c8d-44f7-ae77-b9a9ee6eefaa; MISMATCH vs expected: expected 1, got '#ERROR!'; NOTE: #ERROR! is Google Sheets' parse-failure error (no Excel equivalent); it means Sheets could not parse the formula, which is not the same as #NAME?
ERROR.TYPE LibreOffice Calc

=ERROR.TYPE(SQRT(-1))

Actual result
#N/A

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Information

MISMATCH vs expected: expected 6, got '#N/A'
ERROR.TYPE LibreOffice Calc

=ERROR.TYPE(OFFSET(A1,-1,0))

Actual result
#N/A

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Information

MISMATCH vs expected: expected 4, got '#N/A'
ERRORTYPE Excel for the web

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
532

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Spreadsheet

DERIVED FROM TWO LIBREOFFICE PAGES THAT HAVE TO BE READ TOGETHER, because neither is sufficient alone. ERRORTYPE's own entry in Spreadsheet Functions states the behaviour -- "Returns the number corresponding to an error value occurring in a different cell", "The Status Bar displays the predefined error code from LibreOffice if you click the cell containing the error" -- and gives exactly one example, "If cell A1 displays Err:518, the function =ERRORTYPE(A1) returns the number 518", which is not reproducible from a worksheet formula (518 is an internal 'variable is not available' condition). The CODES are published separately, in LibreOffice's Error Codes in LibreOffice Calc table, which lists 532 against '#DIV/0! Division by zero -- Division operator / if the denominator is 0'. This case and the three below assert that table's codes for the four error conditions a worksheet formula can raise deliberately. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 532, got '#NAME?'
ERRORTYPE Google Sheets

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
532

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Spreadsheet

DERIVED FROM TWO LIBREOFFICE PAGES THAT HAVE TO BE READ TOGETHER, because neither is sufficient alone. ERRORTYPE's own entry in Spreadsheet Functions states the behaviour -- "Returns the number corresponding to an error value occurring in a different cell", "The Status Bar displays the predefined error code from LibreOffice if you click the cell containing the error" -- and gives exactly one example, "If cell A1 displays Err:518, the function =ERRORTYPE(A1) returns the number 518", which is not reproducible from a worksheet formula (518 is an internal 'variable is not available' condition). The CODES are published separately, in LibreOffice's Error Codes in LibreOffice Calc table, which lists 532 against '#DIV/0! Division by zero -- Division operator / if the denominator is 0'. This case and the three below assert that table's codes for the four error conditions a worksheet formula can raise deliberately. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 532, got '#NAME?'
ERRORTYPE Excel for the web

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
502

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Spreadsheet

DERIVED from the published error-code table, whose entry for 502 is 'Invalid argument -- Function argument is not valid. For example, a negative number for the SQRT() function, for this please use IMSQRT().' The formula in this case is the table's own worked example, so the expected code is as directly published as this function's codes get. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 502, got '#NAME?'
ERRORTYPE Google Sheets

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
502

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Spreadsheet

DERIVED from the published error-code table, whose entry for 502 is 'Invalid argument -- Function argument is not valid. For example, a negative number for the SQRT() function, for this please use IMSQRT().' The formula in this case is the table's own worked example, so the expected code is as directly published as this function's codes get. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 502, got '#NAME?'
ERRORTYPE Excel for the web

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
525

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Spreadsheet

DERIVED from the published error-code table: 525 is '#NAME? Invalid names -- An identifier could not be evaluated, for example, no valid reference, no valid function name, no column/row label, no macro, add-in not found.' A call to a function that does not exist is the 'no valid function name' arm of that list. This case is also the one that ties ERRORTYPE to the rest of this corpus: 525 is the numeric form of the same #NAME? that every unsupported-function verdict in the dataset is built on. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 525, got '#NAME?'
ERRORTYPE Google Sheets

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
525

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Spreadsheet

DERIVED from the published error-code table: 525 is '#NAME? Invalid names -- An identifier could not be evaluated, for example, no valid reference, no valid function name, no column/row label, no macro, add-in not found.' A call to a function that does not exist is the 'no valid function name' arm of that list. This case is also the one that ties ERRORTYPE to the rest of this corpus: 525 is the numeric form of the same #NAME? that every unsupported-function verdict in the dataset is built on. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 525, got '#NAME?'
ERRORTYPE Excel for the web

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
519

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Spreadsheet

DERIVED from the published error-code table, which lists 519 against '#VALUE! No value (instead of Err:519 cell displays #VALUE!)' with the explanation 'The formula yields a value that does not correspond to the definition; or a cell that is referenced in the formula contains text instead of a number.' Adding 1 to the string "a" is exactly that second condition. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 519, got '#NAME?'
ERRORTYPE Google Sheets

=ERRORTYPE(A1)

Actual result
#NAME?

Documented / expected
519

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Spreadsheet

DERIVED from the published error-code table, which lists 519 against '#VALUE! No value (instead of Err:519 cell displays #VALUE!)' with the explanation 'The formula yields a value that does not correspond to the definition; or a cell that is referenced in the formula contains text instead of a number.' Adding 1 to the string "a" is exactly that second condition. Error-code table read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/05/02140000.html. LibreOffice's ERRORTYPE help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060109.html.; MISMATCH vs expected: expected 519, got '#NAME?'
EUROCONVERT Excel for the web

=EUROCONVERT(1.2,"DEM","EUR")

Actual result
#NAME?

Documented / expected
0.61

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A2,B2,C2)' over the data 1.20 / DEM / EUR with the result 0.61 and the note "by using a calculation and display precision of 2 decimal places". Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1.20 / 1.95583 = 0.6135502574354622, and with full_precision omitted the documented default is FALSE, which applies the currency-specific rounding from the page's own table -- EUR display precision 2 -- giving 0.61.; MISMATCH vs expected: expected 0.61, got '#NAME?'
EUROCONVERT Google Sheets

=EUROCONVERT(1.2,"DEM","EUR")

Actual result
#NAME?

Documented / expected
0.61

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A2,B2,C2)' over the data 1.20 / DEM / EUR with the result 0.61 and the note "by using a calculation and display precision of 2 decimal places". Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1.20 / 1.95583 = 0.6135502574354622, and with full_precision omitted the documented default is FALSE, which applies the currency-specific rounding from the page's own table -- EUR display precision 2 -- giving 0.61.; MISMATCH vs expected: expected 0.61, got '#NAME?'
EUROCONVERT Excel for the web

=EUROCONVERT(1,"FRF","EUR",FALSE,3)

Actual result
#NAME?

Documented / expected
0.15

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A4,B4,C4,FALSE,3)' with the result 0.15 and the note "by using a calculation and display precision of 2 decimal places". Derived: the same 0.152 intermediate as the previous case, then rounded to the EUR display precision of 2 from the page's rounding table, giving 0.15. This case and the previous one differ only in the full_precision flag, which is the whole point -- an engine that ignores that argument returns the same number for both.; MISMATCH vs expected: expected 0.15, got '#NAME?'
EUROCONVERT Google Sheets

=EUROCONVERT(1,"FRF","EUR",FALSE,3)

Actual result
#NAME?

Documented / expected
0.15

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A4,B4,C4,FALSE,3)' with the result 0.15 and the note "by using a calculation and display precision of 2 decimal places". Derived: the same 0.152 intermediate as the previous case, then rounded to the EUR display precision of 2 from the page's rounding table, giving 0.15. This case and the previous one differ only in the full_precision flag, which is the whole point -- an engine that ignores that argument returns the same number for both.; MISMATCH vs expected: expected 0.15, got '#NAME?'
EUROCONVERT Excel for the web

=EUROCONVERT(1,"FRF","EUR",TRUE,3)

Actual result
#NAME?

Documented / expected
0.152

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A3,B3,C3,TRUE,3)' with the result 0.152. Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1 / 6.55957 = 0.1524490172374104, and the documented triangulation_precision of 3 rounds the intermediate euro value to 3 significant digits, giving 0.152; full_precision TRUE then displays all significant digits of that value rather than re-rounding to the EUR display precision.; MISMATCH vs expected: expected 0.152, got '#NAME?'
EUROCONVERT Google Sheets

=EUROCONVERT(1,"FRF","EUR",TRUE,3)

Actual result
#NAME?

Documented / expected
0.152

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A3,B3,C3,TRUE,3)' with the result 0.152. Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1 / 6.55957 = 0.1524490172374104, and the documented triangulation_precision of 3 rounds the intermediate euro value to 3 significant digits, giving 0.152; full_precision TRUE then displays all significant digits of that value rather than re-rounding to the EUR display precision.; MISMATCH vs expected: expected 0.152, got '#NAME?'
EUROCONVERT Excel for the web

=EUROCONVERT(1,"XYZ","EUR")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in and Automation

Excel documents fourteen accepted ISO codes (BEF, LUF, DEM, ESP, FRF, IEP, ITL, NLG, ATS, PTE, FIM, GRD, SIT, EUR) and the blanket remark "Invalid parameters return #VALUE." XYZ is not among them.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
EUROCONVERT Google Sheets

=EUROCONVERT(1,"XYZ","EUR")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Add-in and Automation

Excel documents fourteen accepted ISO codes (BEF, LUF, DEM, ESP, FRF, IEP, ITL, NLG, ATS, PTE, FIM, GRD, SIT, EUR) and the blanket remark "Invalid parameters return #VALUE." XYZ is not among them.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
EUROCONVERT Excel for the web

=EUROCONVERT(1,"FRF","DEM",TRUE,3)

Actual result
#NAME?

Documented / expected
0.29728616

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A5,B5,C5,TRUE,3)' with the result 0.29728616 and the note "by using an intermediate calculation precision of 3 and displaying all significant digits". Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1 / 6.55957 = 0.1524490172374104, rounded to the documented 3 significant digits of triangulation precision = 0.152, then multiplied by the DEM rate 1.95583 = 0.29728616 exactly. This is the case that proves the intermediate rounding really happens: without it the answer would be 0.1524490172374104 * 1.95583 = 0.2981650... , nowhere near the published figure.; MISMATCH vs expected: expected 0.29728616, got '#NAME?'
EUROCONVERT Google Sheets

=EUROCONVERT(1,"FRF","DEM",TRUE,3)

Actual result
#NAME?

Documented / expected
0.29728616

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Add-in and Automation

Microsoft publishes '=EUROCONVERT(A5,B5,C5,TRUE,3)' with the result 0.29728616 and the note "by using an intermediate calculation precision of 3 and displaying all significant digits". Microsoft's page states the rates its examples assume: "1 euro = 6.55957 French francs and 1.95583 deutsche marks" (the irrevocable EU fixing rates), and every figure below was recomputed from them. Derived: 1 / 6.55957 = 0.1524490172374104, rounded to the documented 3 significant digits of triangulation precision = 0.152, then multiplied by the DEM rate 1.95583 = 0.29728616 exactly. This is the case that proves the intermediate rounding really happens: without it the answer would be 0.1524490172374104 * 1.95583 = 0.2981650... , nowhere near the published figure.; MISMATCH vs expected: expected 0.29728616, got '#NAME?'
EXPAND Google Sheets

=EXPAND(A1:A1,1,3,0)

Actual result
{#NAME?, , }

Documented / expected
{5, 0, 0}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 5, got '#NAME?'
EXPAND Google Sheets

=EXPAND(A1:A2,3,1,0)

Actual result
{#NAME?, , }

Documented / expected
{5, 7, 0}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 5, got '#NAME?'
EXPON.DIST LibreOffice Calc

=EXPON.DIST(0.2,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If lambda <= 0, EXPON.DIST returns the #NUM! error value." Zero is the boundary the rule excludes. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
EXPON.DIST LibreOffice Calc

=EXPON.DIST(-1,10,TRUE)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x < 0, EXPON.DIST returns the #NUM! error value." EXECUTED RESULT -- SILENT NON-ERROR. All four LibreOffice builds return the number 0 instead of the documented #NUM! for a negative x. 0 is the mathematically natural continuation of the CDF below the support, so nothing looks wrong downstream: a spreadsheet full of negative inputs silently produces zeros where Excel would produce a visible column of errors. This is a missing input guard, not a computation defect.; MISMATCH vs expected: expected '#NUM!', got 0
EXPONDIST LibreOffice Calc

=EXPONDIST(0.2,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If lambda <= 0, EXPONDIST returns the #NUM! error value." Zero is the boundary the rule excludes. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
EXPONDIST LibreOffice Calc

=EXPONDIST(-1,10,TRUE)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x < 0, EXPONDIST returns the #NUM! error value." EXECUTED RESULT -- SILENT NON-ERROR: the legacy spelling behaves exactly like the modern one, returning 0 on all four LibreOffice builds where the page documents #NUM!.; MISMATCH vs expected: expected '#NUM!', got 0
F.DIST LibreOffice Calc

=F.DIST(-1,6,4,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x is negative, F.DIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.DIST LibreOffice Calc

=F.DIST(15.2069,0,4,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom1 < 1, F.DIST returns the #NUM! error value." Zero is the first excluded value. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.DIST.RT LibreOffice Calc

=F.DIST.RT(-1,6,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x is negative, F.DIST.RT returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.DIST.RT LibreOffice Calc

=F.DIST.RT(15.2068649,6,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom2 < 1 F.DIST.RT returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.INV LibreOffice Calc

=F.INV(1.5,6,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability < 0 or probability > 1, F.INV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.INV LibreOffice Calc

=F.INV(0.01,0,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If deg_freedom1 < 1, or deg_freedom2 < 1, F.INV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.INV.RT LibreOffice Calc

=F.INV.RT(-0.5,6,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If Probability is < 0 or probability is > 1, F.INV.RT returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.INV.RT LibreOffice Calc

=F.INV.RT(0.01,6,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If Deg_freedom1 is < 1, or Deg_freedom2 is < 1, F.INV.RT returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
F.TEST LibreOffice Calc

=F.TEST(E2:E3,B2:B6)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents the same rule for size as for zero variance: "If the number of data points in array1 or array2 is less than 2 ... F.TEST returns the #DIV/0! error value." E2:E3 is a two-cell range holding the number 3 and the text "n/a", and Microsoft documents on the same page that "If an array or reference argument contains text, logical values, or empty cells, those values are ignored" -- so the range contributes exactly ONE data point, one short of the documented minimum. The two conditions the sentence joins are asserted separately (see F.TEST_zero_variance_div0) so a single #DIV/0! cannot stand in for both. EXECUTED RESULT: all four LibreOffice builds return #VALUE! where the page documents #DIV/0!, the same substitution as F.TEST_zero_variance_div0.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
F.TEST LibreOffice Calc

=F.TEST(D2:D6,B2:B6)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If the number of data points in array1 or array2 is less than 2, or if the variance of array1 or array2 is zero, F.TEST returns the #DIV/0! error value." D2:D6 holds five copies of the value 5, so its variance is exactly zero. EXECUTED RESULT: all four LibreOffice builds return #VALUE! where the page documents #DIV/0! -- the #VALUE!-substitution pattern reaching a documented #DIV/0! rather than the usual #NUM!, the same shape batch B recorded for CHISQ.TEST's documented #N/A.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
FDIST Excel for the web

=FDIST(15.20686486,10000000000,4)

Actual result
0.007926504197833037

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

Excel documents a constraint the modern F.DIST.RT page drops: "If deg_freedom1 < 1 or deg_freedom1 >= 10^10, FDIST returns the #NUM! error value." 10^10 = 10000000000 is exactly the excluded boundary. This is the one place the legacy and modern spellings are documented to differ, which is why the case is here rather than on F.DIST.RT. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Worth noting separately: LibreOffice does REJECT the 10^10 degrees of freedom the legacy page excludes -- it just reports the rejection with the wrong token.; MISMATCH vs expected: expected '#NUM!', got 0.007926504197833037
FDIST Google Sheets

=FDIST(15.20686486,10000000000,4)

Actual result
0.007926514992

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Excel documents a constraint the modern F.DIST.RT page drops: "If deg_freedom1 < 1 or deg_freedom1 >= 10^10, FDIST returns the #NUM! error value." 10^10 = 10000000000 is exactly the excluded boundary. This is the one place the legacy and modern spellings are documented to differ, which is why the case is here rather than on F.DIST.RT. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Worth noting separately: LibreOffice does REJECT the 10^10 degrees of freedom the legacy page excludes -- it just reports the rejection with the wrong token.; MISMATCH vs expected: expected '#NUM!', got 0.007926514992
FDIST LibreOffice Calc

=FDIST(15.20686486,10000000000,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents a constraint the modern F.DIST.RT page drops: "If deg_freedom1 < 1 or deg_freedom1 >= 10^10, FDIST returns the #NUM! error value." 10^10 = 10000000000 is exactly the excluded boundary. This is the one place the legacy and modern spellings are documented to differ, which is why the case is here rather than on F.DIST.RT. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Worth noting separately: LibreOffice does REJECT the 10^10 degrees of freedom the legacy page excludes -- it just reports the rejection with the wrong token.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FDIST LibreOffice Calc

=FDIST(-1,6,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x is negative, FDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FDIST LibreOffice Calc

=FDIST(15.20686486,6,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If deg_freedom2 < 1 or deg_freedom2 >= 10^10, FDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FILTER Excel for the web

=FILTER(A1:A3,B1:B3>100)

Actual result
#VALUE!

Documented / expected
#CALC!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Lookup and reference

MISMATCH vs expected: expected '#CALC!', got '#VALUE!'
FILTER Google Sheets

=FILTER(A1:A3,B1:B3>100)

Actual result
#N/A

Documented / expected
#CALC!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: expected '#CALC!', got '#N/A'
FILTER LibreOffice Calc

=FILTER(A1:A3,B1:B3>100)

Actual result
#N/A

Documented / expected
#CALC!

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

MISMATCH vs expected: expected '#CALC!', got '#N/A'
FILTER Google Sheets

=FILTER(A1:A3,B1:B3>100,"none")

Actual result
#N/A

Documented / expected
none

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: expected 'none', got '#N/A'
FILTERXML Google Sheets

=FILTERXML(A2,"//rc/@title")

Actual result
#NAME?

Documented / expected
Excel

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Web

Microsoft's page documents its live example as "Cells B3:B5 contain the formula =FILTERXML(B3,"//rc/@title")", i.e. an attribute selection on rc elements. This case keeps that exact XPath and supplies a literal <rc title="Excel" .../> element in place of the unreachable Wikipedia feed, so the documented attribute form is exercised deterministically. Re-derived with ElementTree.; MISMATCH vs expected: expected 'Excel', got '#NAME?'
FILTERXML Google Sheets

=FILTERXML(A4,"//x:t")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Web

Excel documents this as a separate failure mode from malformed XML: "If xml contains a namespace with a prefix that is not valid, FILTERXML returns the #VALUE! error value." A4 holds <r><x:t>alpha</x:t></r>, where the prefix x is bound to no namespace; ElementTree rejects it with "unbound prefix", confirming the condition the documentation describes.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
FILTERXML Google Sheets

=FILTERXML(A1,"//t[2]")

Actual result
#NAME?

Documented / expected
beta

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Web

Microsoft's page gives no self-contained worked example -- its only example pipes live output of WEBSERVICE into FILTERXML, which no offline harness can reproduce -- so this case supplies literal XML and asserts what the documented contract requires: "returns specific data from XML content by using the specified xpath", with xpath documented as "A string in standard XPath format". Against <r><t>alpha</t><t>beta</t></r> the standard XPath //t[2] selects the second t element, whose string value is "beta"; re-derived with Python's ElementTree, which is an independent XPath implementation from either spreadsheet engine's.; MISMATCH vs expected: expected 'beta', got '#NAME?'
FILTERXML Google Sheets

=FILTERXML(A3,"//t")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Web

Excel documents: "If xml is not valid, FILTERXML returns the #VALUE! error value." A3 holds <r><t>alpha</t> with no closing </r>, which is not well-formed XML; ElementTree rejects it with a ParseError, confirming the input really is invalid rather than merely unusual.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
FINDB Google Sheets

=FINDB("b",A3)

Actual result
5

Documented / expected
3

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

A3 holds the three-character string U+65E5 U+672C followed by an ASCII b. Verbatim from Microsoft's FIND, FINDB page: "FINDB counts each double-byte character as 2 when you have enabled the editing of a language that supports DBCS and then set it as the default language. Otherwise, FINDB counts each character as 1", with the DBCS languages listed as Japanese, Chinese (Simplified), Chinese (Traditional) and Korean. This harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, so the documented answer is the one-byte-per-character reading -- the same treatment the corpus's LENB cases already use, and stated here rather than assumed away. Under that non-DBCS reading the b is the third character and the documented answer is 3; under a DBCS default language the two CJK characters would count 2 bytes each and the answer would be 5. Recording which of the two each engine produces is the whole point of the case -- exactly as for the corpus's LENB_non_ascii_characters probe. EXECUTED RESULT -- SILENT WRONG VALUE. All four LibreOffice builds return 5, i.e. they apply the double-byte count (2 bytes per CJK character) even though the default language is not a DBCS one, where the documentation's "Otherwise, FINDB counts each character as 1" clause gives 3. No error is raised; a formula that slices text by this position silently cuts in a different place. This is the same shape as the divergence the corpus already records for LENB, and it is the only one of the six FINDB cases that diverges -- every ASCII case matches, so LibreOffice's FINDB is correct except for exactly this locale rule.; MISMATCH vs expected: expected 3, got 5
FINDB LibreOffice Calc

=FINDB("b",A3)

Actual result
5

Documented / expected
3

Engine
LibreOffice Calc 25.8.7.3

Category
Text

A3 holds the three-character string U+65E5 U+672C followed by an ASCII b. Verbatim from Microsoft's FIND, FINDB page: "FINDB counts each double-byte character as 2 when you have enabled the editing of a language that supports DBCS and then set it as the default language. Otherwise, FINDB counts each character as 1", with the DBCS languages listed as Japanese, Chinese (Simplified), Chinese (Traditional) and Korean. This harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, so the documented answer is the one-byte-per-character reading -- the same treatment the corpus's LENB cases already use, and stated here rather than assumed away. Under that non-DBCS reading the b is the third character and the documented answer is 3; under a DBCS default language the two CJK characters would count 2 bytes each and the answer would be 5. Recording which of the two each engine produces is the whole point of the case -- exactly as for the corpus's LENB_non_ascii_characters probe. EXECUTED RESULT -- SILENT WRONG VALUE. All four LibreOffice builds return 5, i.e. they apply the double-byte count (2 bytes per CJK character) even though the default language is not a DBCS one, where the documentation's "Otherwise, FINDB counts each character as 1" clause gives 3. No error is raised; a formula that slices text by this position silently cuts in a different place. This is the same shape as the divergence the corpus already records for LENB, and it is the only one of the six FINDB cases that diverges -- every ASCII case matches, so LibreOffice's FINDB is correct except for exactly this locale rule.; MISMATCH vs expected: expected 3, got 5
FINV Excel for the web

=FINV(0.01,10000000000,4)

Actual result
13.46305070195854

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

Excel documents: "If deg_freedom1 < 1 or deg_freedom1 >= 10^10, FINV returns the #NUM! error value." 10^10 is exactly the excluded boundary, and is a constraint the modern F.INV.RT page states only for deg_freedom2. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got 13.46305070195854
FINV LibreOffice Calc

=FINV(0.01,10000000000,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If deg_freedom1 < 1 or deg_freedom1 >= 10^10, FINV returns the #NUM! error value." 10^10 is exactly the excluded boundary, and is a constraint the modern F.INV.RT page states only for deg_freedom2. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FINV LibreOffice Calc

=FINV(1.5,6,4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability < 0 or probability > 1, FINV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FISHER LibreOffice Calc

=FISHER(-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= -1 or if x >= 1, FISHER returns the #NUM! error value." -1 is the other excluded boundary; both are asserted because an engine can easily guard one side only. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FISHER LibreOffice Calc

=FISHER(1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= -1 or if x >= 1, FISHER returns the #NUM! error value." 1 is exactly the excluded boundary, where the transformation diverges. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FLATTEN Excel for the web

=ROWS(FLATTEN(A1:B3))

Actual result
#NAME?

Documented / expected
6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

DERIVED from the second Notes bullet: "Empty values are not skipped; the FILTER function can be used to remove those." A3 IS DELIBERATELY BLANK AND UNPOPULATED -- its emptiness is the whole content of the case. Six cells go in, so six rows must come out; a function that skipped blanks would return 5. Asserted through ROWS rather than as a spilled array so that the blank does not have to be represented in the comparison. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: expected 6, got '#NAME?'
FLATTEN LibreOffice Calc

=ROWS(FLATTEN(A1:B3))

Actual result
#NAME?

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Array

DERIVED from the second Notes bullet: "Empty values are not skipped; the FILTER function can be used to remove those." A3 IS DELIBERATELY BLANK AND UNPOPULATED -- its emptiness is the whole content of the case. Six cells go in, so six rows must come out; a function that skipped blanks would return 5. Asserted through ROWS rather than as a spilled array so that the blank does not have to be represented in the comparison. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: expected 6, got '#NAME?'
FLATTEN Excel for the web

=FLATTEN(B1:B2, A1:A2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{2, 4, 1, 3}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

DERIVED from the first clause of the same Notes bullet, "ordered by argument": the second range is exhausted only after the first, so passing column B first puts 2 and 4 ahead of 1 and 3 even though they sit to the right on the sheet. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: value mismatch: expected 2, got '#NAME?'
FLATTEN LibreOffice Calc

=FLATTEN(B1:B2, A1:A2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{2, 4, 1, 3}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

DERIVED from the first clause of the same Notes bullet, "ordered by argument": the second range is exhausted only after the first, so passing column B first puts 2 and 4 ahead of 1 and 3 even though they sit to the right on the sheet. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: value mismatch: expected 2, got '#NAME?'
FLATTEN Excel for the web

=FLATTEN(A1:B2, "sample middle", B3:B4)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{1, 2, 3, 4, sample middle, 5, 6}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

GOOGLE'S OWN PUBLISHED EXAMPLE, formula and output together: with A1=1, B1=2, A2=3, B2=4, B3=5, B4=6, the page prints =FLATTEN(A1:B2, "sample middle", B3:B4) producing D1..D7 = 1, 2, 3, 4, "sample middle", 5, 6. Note that the second range is B3:B4 -- COLUMN B rows 3 and 4 -- not a continuation of column A; the page's own values were re-read on a second fetch to confirm that, because the two readings give different output. This row demonstrates every claim the Notes make at once: row-major within a range, arguments in order, and a bare literal accepted as an argument. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
FLATTEN LibreOffice Calc

=FLATTEN(A1:B2, "sample middle", B3:B4)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{1, 2, 3, 4, sample middle, 5, 6}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

GOOGLE'S OWN PUBLISHED EXAMPLE, formula and output together: with A1=1, B1=2, A2=3, B2=4, B3=5, B4=6, the page prints =FLATTEN(A1:B2, "sample middle", B3:B4) producing D1..D7 = 1, 2, 3, 4, "sample middle", 5, 6. Note that the second range is B3:B4 -- COLUMN B rows 3 and 4 -- not a continuation of column A; the page's own values were re-read on a second fetch to confirm that, because the two readings give different output. This row demonstrates every claim the Notes make at once: row-major within a range, arguments in order, and a bare literal accepted as an argument. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
FLATTEN Excel for the web

=FLATTEN(A1:B2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{1, 2, 3, 4}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Array

DERIVED from the Notes bullet, quoted in full: "Values are ordered by argument, then row, then column. So, the entire first row of an input is added before the second row (also known as row-major order)." Row-major gives 1, 2, 3, 4; column-major would give 1, 3, 2, 4, and that is the whole content of this case. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
FLATTEN LibreOffice Calc

=FLATTEN(A1:B2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{1, 2, 3, 4}

Engine
LibreOffice Calc 25.8.7.3

Category
Array

DERIVED from the Notes bullet, quoted in full: "Values are ordered by argument, then row, then column. So, the entire first row of an input is added before the second row (also known as row-major order)." Row-major gives 1, 2, 3, 4; column-major would give 1, 3, 2, 4, and that is the whole content of this case. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's FLATTEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10307761.; MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
FLOOR LibreOffice Calc

=FLOOR(2.5,-2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,1.5)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "For numbers outside of the range (0,1), FORECAST.ETS.CONFINT will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.CONFINT LibreOffice Calc

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,1.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "For numbers outside of the range (0,1), FORECAST.ETS.CONFINT will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents confidence_level as "A numerical value between 0 and 1 (exclusive) ... For numbers outside of the range (0,1), FORECAST.ETS.CONFINT will return the #NUM! error." The interval is open, so 0 is outside it. Asserted separately from the 1.5 case because a boundary and a far-out-of-range value exercise different guards. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, and a SILENT WRONG ANSWER rather than a different error code: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the number 0 for a confidence level of 0, where the page's "For numbers outside of the range (0,1) ... #NUM!" clause calls for an error. 0 is a superficially reasonable answer -- a zero-confidence interval arguably has zero width -- which is exactly what makes it dangerous: an out-of-range argument produces a clean-looking number instead of a visible error. Its sibling case one line down, a confidence level of 1.5, DOES error (with #VALUE! rather than #NUM!), so the range is guarded on the upper side only.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.CONFINT LibreOffice Calc

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents confidence_level as "A numerical value between 0 and 1 (exclusive) ... For numbers outside of the range (0,1), FORECAST.ETS.CONFINT will return the #NUM! error." The interval is open, so 0 is outside it. Asserted separately from the 1.5 case because a boundary and a far-out-of-range value exercise different guards. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, and a SILENT WRONG ANSWER rather than a different error code: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the number 0 for a confidence level of 0, where the page's "For numbers outside of the range (0,1) ... #NUM!" clause calls for an error. 0 is a superficially reasonable answer -- a zero-confidence interval arguably has zero width -- which is exactly what makes it dangerous: an out-of-range argument produces a clean-looking number instead of a visible error. Its sibling case one line down, a confidence level of 1.5, DOES error (with #VALUE! rather than #NUM!), so the range is guarded on the upper side only.; MISMATCH vs expected: expected '#NUM!', got 0
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,E1:E20)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.CONFINT will return the #VALUE! error." E1:E20 is the 1..20 timeline with its first two entries both 1. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build returns a confidence radius of roughly 3.8 to 4.1 -- and, because this is CONFINT, a DIFFERENT one on each build and on each run (24.2.0.3 3.98634886618424, 24.8.7.2 3.77969371470417, 25.2.0.3 4.11592383024156, 25.8.7.3 3.99931306698463 on the run recorded here). This is one of only two cases in the whole batch that differ across the four builds, and both are FORECAST.ETS.CONFINT. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
FORECAST.ETS.CONFINT LibreOffice Calc

=FORECAST.ETS.CONFINT(21,C1:C20,E1:E20)

Actual result
3.66439998164772

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.CONFINT will return the #VALUE! error." E1:E20 is the 1..20 timeline with its first two entries both 1. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build returns a confidence radius of roughly 3.8 to 4.1 -- and, because this is CONFINT, a DIFFERENT one on each build and on each run (24.2.0.3 3.98634886618424, 24.8.7.2 3.77969371470417, 25.2.0.3 4.11592383024156, 25.8.7.3 3.99931306698463 on the run recorded here). This is one of only two cases in the whole batch that differ across the four builds, and both are FORECAST.ETS.CONFINT. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got 3.66439998164772
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0.99)>=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0.5)

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

The one property of the interval that is fixed by the documentation rather than by the implementation. Microsoft defines confidence_level as "a numerical value between 0 and 1 (exclusive), indicating a confidence level for the calculated confidence interval ... (90% of future points are to fall within this radius from prediction)". A radius that captures 99% of future points cannot be smaller than one that captures 50% of them, whatever the fitted parameters are. 0.99 against 0.50 is used rather than 0.99 against 0.90 on purpose: LibreOffice's CONFINT is non-deterministic (see the value probe on this function), so a narrow comparison could flip on noise alone, while the 99-vs-50 gap on this data is an order of magnitude larger than the observed jitter. Confirmed stable: true on twelve identical cells x two runs x all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) (96/96). HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0.95,-3)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents seasonality as: "The default value of 1 means Excel detects seasonality automatically ... 0 indicates no seasonality ... Positive whole numbers will indicate to the algorithm to use patterns of this length as the seasonality. For any other value, FORECAST.ETS.CONFINT will return the #NUM! error." -3 is neither 0, 1, nor a positive whole number. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,H1:H20)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If a constant step can't be identified in the provided timeline, FORECAST.ETS.CONFINT will return the #NUM! error." H1:H20 is 1, 2, 4, 8, 16, 32, 33, 34, ... -- doubling, then stepping by 1, so no single step fits. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20)>=0

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Asserted structurally rather than numerically. Microsoft defines the return value as a radius -- "95% of future points are expected to fall within this radius from the result FORECAST.ETS forecasted" -- and a radius is by definition non-negative. This holds for every implementation of the algorithm regardless of how it fits its parameters, so it is assertable where the value itself is not. Confirmed stable: true on twelve identical cells x two runs x all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) (96/96). HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0.95,9000)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "Maximum supported seasonality is 8,760 (number of hours in a year). Any seasonality above that number will result in the #NUM! error." 9000 exceeds it. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.CONFINT LibreOffice Calc

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A20,0.95,9000)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "Maximum supported seasonality is 8,760 (number of hours in a year). Any seasonality above that number will result in the #NUM! error." 9000 exceeds it. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A10)

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.CONFINT will return the #N/A error." 20 values against a 10-row timeline. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
FORECAST.ETS.CONFINT LibreOffice Calc

=FORECAST.ETS.CONFINT(21,C1:C20,A1:A10)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.CONFINT will return the #N/A error." 20 values against a 10-row timeline. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
FORECAST.ETS.CONFINT Google Sheets

=FORECAST.ETS.CONFINT(5,C1:C20,A1:A20)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If the target date is chronologically before the end of the historical timeline, FORECAST.ETS.CONFINT returns the #NUM! error." The timeline here ends at 20, so a target of 5 is squarely inside it. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(B1:B20,A1:A20)

Actual result
#NAME?

Documented / expected
4

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft's page publishes no worked example (only a "Download a sample workbook" link), so this is asserted from the documented DEFINITION on a series constructed so that the definition has only one possible answer: "Returns the length of the repetitive pattern Excel detects for the specified time series." B1:B20 is 10, 20, 30, 20 repeated five times over a constant-step timeline -- a pattern of length 4 repeated exactly five times, with no other repetitive structure and no noise for a detector to trip over. Any implementation that detects a repetitive pattern at all must report 4 here; 2 does not fit (10, 20 then 30, 20 differ), and 20 is the whole series. This is the one FORECAST.ETS.* quantity in this batch that the algorithm's implementation freedom does not reach, which is exactly why it is the one asserted. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 4, got '#NAME?'
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(C1:C20,E1:E20)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.SEASONALITY will return the #VALUE! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build reports a seasonality of 4 -- the same answer it gives for the well-formed timeline, so the duplicate is simply absorbed. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
FORECAST.ETS.SEASONALITY LibreOffice Calc

=FORECAST.ETS.SEASONALITY(C1:C20,E1:E20)

Actual result
4

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.SEASONALITY will return the #VALUE! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build reports a seasonality of 4 -- the same answer it gives for the well-formed timeline, so the duplicate is simply absorbed. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got 4
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(C1:C20,H1:H20)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If a constant step can't be identified in the provided timeline, FORECAST.ETS.SEASONALITY will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.SEASONALITY LibreOffice Calc

=FORECAST.ETS.SEASONALITY(C1:C20,H1:H20)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If a constant step can't be identified in the provided timeline, FORECAST.ETS.SEASONALITY will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(C1:C20,A1:A10)

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.SEASONALITY will return the #N/A error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
FORECAST.ETS.SEASONALITY LibreOffice Calc

=FORECAST.ETS.SEASONALITY(C1:C20,A1:A10)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.SEASONALITY will return the #N/A error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(B1:B20,D1:D20)

Actual result
#NAME?

Documented / expected
4

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Seasonality is documented as "the length of the repetitive pattern" -- a count of data points, not a distance along the timeline. Rescaling the timeline from 1, 2, 3 ... to 2, 4, 6 ... leaves the pattern four points long, so the answer must still be 4. This separates an implementation that counts points from one that has confused the period with the timeline step. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 4, got '#NAME?'
FORECAST.ETS.SEASONALITY Google Sheets

=FORECAST.ETS.SEASONALITY(C1:C20,A1:A20)

Actual result
#NAME?

Documented / expected
4

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

The companion to the clean case, and the reason both exist: a detector could pass the clean series by exact-matching repeated blocks. C1:C20 is the same 10, 20, 30, 20 pattern with the fixed residual sequence 0, 1, -1, 2, 0, -2, 1, 0, ... added, so no two cycles are identical yet the period is still unambiguously 4 (the residuals are small relative to the 20-unit swing of the pattern). HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 4, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=AND(FORECAST.ETS.STAT(C1:C20,A1:A20,1)>=0,FORECAST.ETS.STAT(C1:C20,A1:A20,1)<=1)

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

What CAN be asserted about alpha. A smoothing parameter in exponential smoothing is a weight on the most recent observation, and the documentation describes it in exactly those terms ("a higher value gives more weight to recent data points"); a weight outside [0,1] is not a weight. This bounds the optimizer's output without pretending to know which value inside the interval it will pick. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,E1:E20,8)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.STAT will return the #VALUE! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build reports a detected step size of 1 -- a confident, specific answer about a timeline that has no well-defined step at all, since two of its entries are the same instant. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
FORECAST.ETS.STAT LibreOffice Calc

=FORECAST.ETS.STAT(C1:C20,E1:E20,8)

Actual result
1

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If timeline contains duplicate values, FORECAST.ETS.STAT will return the #VALUE! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT, AND THE MOST SERIOUS FINDING IN THIS BATCH: no LibreOffice build errors here at all. Instead of the documented #VALUE!, every build reports a detected step size of 1 -- a confident, specific answer about a timeline that has no well-defined step at all, since two of its entries are the same instant. A duplicate timestamp is not a cosmetic input flaw -- it means one of the observations is being silently dropped, aggregated away or double-counted, and Excel refuses the whole computation for exactly that reason. LibreOffice answers anyway, with no indication that the timeline it modelled is not the timeline it was given. All three FORECAST.ETS.* functions in this batch behave the same way on the same input.; MISMATCH vs expected: expected '#VALUE!', got 1
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,A1:A20,6)<=FORECAST.ETS.STAT(C1:C20,A1:A20,7)

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

The strongest thing assertable about the two error metrics without knowing the fitted model. Statistic types 6 and 7 are documented as the MAE and RMSE of the SAME set of residuals, and the mean of |e| never exceeds the root mean of e^2 -- that is Jensen's inequality applied to the convex square, an identity that holds for any residual vector whatsoever. So this passes for every conforming implementation and fails only if the two statistics are not computed from one set of residuals. NOTE ON THE PAGE: Microsoft's own text for type 6 is copy-pasted from type 5 -- it reads "MAE metric: Returns the symmetric mean absolute percentage error metric, an accuracy measure based on percentage errors", which is the definition of SMAPE, not of MAE. The label (MAE), not the pasted sentence, is what is relied on here. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,H1:H20,8)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If a constant step can't be identified in the provided timeline, FORECAST.ETS.STAT will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
FORECAST.ETS.STAT LibreOffice Calc

=FORECAST.ETS.STAT(C1:C20,H1:H20,8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If a constant step can't be identified in the provided timeline, FORECAST.ETS.STAT will return the #NUM! error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,A1:A20,7)>=0

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Documented as "RMSE metric -- Returns the root mean squared error metric, a measure of the differences between predicted and observed values". A root of a mean of squares is non-negative by construction, for every implementation. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,A1:A10,8)

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.STAT will return the #N/A error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
FORECAST.ETS.STAT LibreOffice Calc

=FORECAST.ETS.STAT(C1:C20,A1:A10,8)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If the ranges of the timeline and values aren't of same size, FORECAST.ETS.STAT will return the #N/A error." HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #N/A. All three FORECAST.ETS.* functions in this batch make the identical substitution on the identical input, so it is one behaviour in a shared argument-checking path rather than three separate slips.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(C1:C20,A1:A20,5)>=0

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Documented as "SMAPE metric -- Returns the symmetric mean absolute percentage error metric, an accuracy measure based on percentage errors". A mean of absolute percentage errors is non-negative by construction. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected True, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(B1:B20,A1:A20,8)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Statistic type 8 is documented as "Step size detected -- Returns the step size detected in the historical timeline", and it is the ONE of the eight statistics that is a property of the INPUT rather than of the fitted model: it owes nothing to the AAA algorithm's smoothing parameters, its optimizer or its error metrics. A1:A20 is 1, 2, 3 ... 20, so the detected step is 1 and any other answer is wrong regardless of implementation. Microsoft's page publishes no worked example, so this is asserted from the definition, not from a figure. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 1, got '#NAME?'
FORECAST.ETS.STAT Google Sheets

=FORECAST.ETS.STAT(B1:B20,D1:D20,8)

Actual result
#NAME?

Documented / expected
2

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

The companion to the step-1 case: D1:D20 is 2, 4, 6 ... 40. Asserting only the step-1 case would be passed by an implementation that returns a hard-coded 1, so both are asserted. HARNESS DATA (identical on every FORECAST.ETS.* case in this batch, and deliberately synthetic so the seasonal structure is a fact about the data rather than a guess): A1:A20 is the timeline 1..20, a constant step of 1. B1:B20 is a textbook-clean series of period 4 -- 10, 20, 30, 20 repeated five times -- so the only repetitive pattern present has length 4. C1:C20 is that same period-4 pattern plus a fixed, hard-coded residual sequence (0, 1, -1, 2, 0, -2, 1, 0, ... ), giving a series with real forecast error but an unambiguous season; nothing here is random, so the input is byte-identical on every run and every build. D1:D20 is the timeline 2, 4, ... 40, a constant step of 2. E1:E20 is the 1..20 timeline with its first two entries both set to 1, i.e. a DUPLICATE timeline value. G1:G20 is strictly linear (7, 9, ... 45) with no seasonal component. H1:H20 is 1, 2, 4, 8, 16, 32, 33, ... -- a timeline with no constant step at all. Column F is left empty throughout because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 2, got '#NAME?'
FTEST LibreOffice Calc

=FTEST(D2:D2,E2:E2)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If the number of data points in array1 or array2 is less than 2 ... FTEST returns the #DIV/0! error value." A one-point sample has no n-1 estimator. Asserted separately from the zero-variance case because they are different guards on the same documented error. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #DIV/0!, the same substitution batch C recorded for this function's modern replacement F.TEST on the identical inputs. Set up from Microsoft's own worked-example table for FTEST: the header row Data1 / Data2 in row 1 and the two five-value samples 6, 7, 9, 15, 21 and 20, 28, 31, 38, 40 in A2:A6 and B2:B6, exactly as the page pastes them at A1. Two extra columns this corpus adds for the documented error branches: C2:C6 is five copies of 7 (a sample whose variance is zero) and D2 / E2 are single-cell samples. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
FTEST LibreOffice Calc

=FTEST(C2:C6,B2:B6)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If the number of data points in array1 or array2 is less than 2, or if the variance of array1 or array2 is zero, FTEST returns the #DIV/0! error value." C2:C6 is five copies of 7, so its variance is exactly zero and the F ratio's denominator vanishes. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #DIV/0!, the same substitution batch C recorded for this function's modern replacement F.TEST on the identical inputs. Set up from Microsoft's own worked-example table for FTEST: the header row Data1 / Data2 in row 1 and the two five-value samples 6, 7, 9, 15, 21 and 20, 28, 31, 38, 40 in A2:A6 and B2:B6, exactly as the page pastes them at A1. Two extra columns this corpus adds for the documented error branches: C2:C6 is five copies of 7 (a sample whose variance is zero) and D2 / E2 are single-cell samples. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
FVSCHEDULE LibreOffice Calc

=FVSCHEDULE(1,A1:A2)

Actual result
1.09

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Verbatim from Microsoft: 'any other value produces the #VALUE! error value for FVSCHEDULE'. Note this is the opposite of most statistical functions, which ignore stray text in a reference, and it differs from an empty cell, which the same sentence documents as a zero rate; MISMATCH vs expected: expected '#VALUE!', got 1.09
GAMMA Google Sheets

=ROUND(GAMMA(-3.75),12)

Actual result
#NUM!

Documented / expected
0.267866128861

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft publishes '=GAMMA(-3.75)' with the result 0.268. Derived independently with mpmath at 50 digits: Gamma(-3.75) = 0.26786612886141660256, which rounds to the published 0.268. This case matters because the gamma function is only defined for negative arguments by analytic continuation -- an implementation that simply integrates the defining integral cannot reach it -- and because the sign is a real test: Gamma is positive on (-4,-3), and an engine using the reflection formula with a sign slip lands on -0.268.; MISMATCH vs expected: expected 0.267866128861, got '#NUM!'
GAMMA LibreOffice Calc

=GAMMA(-2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If Number is a negative integer or 0, GAMMA returns the #NUM! error value", and publishes '=GAMMA(-2)' with the result #NUM!. Gamma has poles at every non-positive integer. Asserted alongside GAMMA(-3.75), which is NOT an integer and must return a finite value -- together they check that an engine rejects the poles without rejecting the whole negative axis. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA LibreOffice Calc

=GAMMA(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If Number is a negative integer or 0, GAMMA returns the #NUM! error value", and the page's own example table lists '=GAMMA(0)' with the result #NUM!. The gamma function has a pole at 0. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.DIST LibreOffice Calc

=GAMMA.DIST(1,0,2,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMA.DIST returns the #NUM! error value." Zero is the boundary of the exclusion. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.DIST LibreOffice Calc

=GAMMA.DIST(1,9,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMA.DIST returns the #NUM! error value." Asserted separately from the alpha case because an engine can guard one parameter and not the other; beta also appears in a division (x/beta), so a missing guard here surfaces as #DIV/0! rather than a wrong number. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.DIST LibreOffice Calc

=GAMMA.DIST(-1,9,2,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x < 0, GAMMA.DIST returns the #NUM! error value." The gamma distribution has no support below zero. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. WORTH READING NEXT TO ITS LEGACY TWIN: on the identical input, LibreOffice's GAMMADIST(-1,9,2,TRUE) returns the NUMBER 0 rather than any error at all (see data/tests/GAMMADIST.json). The two names are documented as the same function with the same exclusions, but LibreOffice guards the modern spelling and not the legacy one, so which spelling a workbook happens to use decides whether an out-of-domain x is visible.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.INV LibreOffice Calc

=GAMMA.INV(0.5,0,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMA.INV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.INV LibreOffice Calc

=GAMMA.INV(2,9,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability < 0 or probability > 1, GAMMA.INV returns the #NUM! error value." Asserted separately from the negative case because they are guards on opposite ends of the same range. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMA.INV LibreOffice Calc

=GAMMA.INV(-0.1,9,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability < 0 or probability > 1, GAMMA.INV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMADIST LibreOffice Calc

=GAMMADIST(1,0,2,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMADIST returns the #NUM! error value." Zero is the boundary of the exclusion. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMADIST LibreOffice Calc

=GAMMADIST(1,9,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMADIST returns the #NUM! error value." Asserted separately from the alpha case because an engine can guard one parameter and not the other; beta also appears in a division (x/beta), so a missing guard here surfaces as #DIV/0! rather than a wrong number. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMADIST LibreOffice Calc

=GAMMADIST(-1,9,2,TRUE)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x < 0, GAMMADIST returns the #NUM! error value." The gamma distribution has no support below zero. Set up from Microsoft's own worked-example table: A2 = 10.00001131 (the value at which the distribution is evaluated), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 exactly as the page describes. Column F is untouched because this harness writes the formula under test into cell F1. EXECUTED RESULT, and a SILENT WRONG ANSWER -- the serious class: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the NUMBER 0 for a negative x, where the page documents #NUM!. No error is raised, so a column of negative inputs yields a column of zeros that looks like a legitimately tiny probability rather than a visible column of errors. This is the same shape of missing input guard batch C recorded for EXPON.DIST/EXPONDIST at negative x. The finding is sharpened by the modern spelling on the same engine: GAMMA.DIST(-1,9,2,TRUE) returns #VALUE! on all four builds (see data/tests/GAMMA.DIST.json), so LibreOffice has the guard -- it is just missing from the legacy alias, and the two names disagree about the same documented exclusion.; MISMATCH vs expected: expected '#NUM!', got 0
GAMMAINV LibreOffice Calc

=GAMMAINV(0.5,0,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If alpha <= 0 or if beta <= 0, GAMMAINV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMAINV LibreOffice Calc

=GAMMAINV(2,9,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability < 0 or probability > 1, GAMMAINV returns the #NUM! error value." Asserted separately from the negative case because they are guards on opposite ends of the same range. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMAINV LibreOffice Calc

=GAMMAINV(-0.1,9,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability < 0 or probability > 1, GAMMAINV returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 0.068094 (the probability), A3 = 9 (alpha) and A4 = 2 (beta), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMALN LibreOffice Calc

=GAMMALN(-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0, GAMMALN returns the #NUM! error value." Note this is a STRICTER domain than GAMMA's: GAMMA(-3.75) is a documented finite value, but GAMMALN(-3.75) is excluded outright, because the gamma function alternates sign on the negative axis and its real logarithm would be undefined half the time. Asserted separately from the zero case for that reason. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMALN LibreOffice Calc

=GAMMALN(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0, GAMMALN returns the #NUM! error value." Gamma has a pole at 0, so its logarithm diverges. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMALN.PRECISE LibreOffice Calc

=GAMMALN.PRECISE(-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0, GAMMALN.PRECISE returns the #NUM! error value." Note this is a STRICTER domain than GAMMA's: GAMMA(-3.75) is a documented finite value, but GAMMALN.PRECISE(-3.75) is excluded outright, because the gamma function alternates sign on the negative axis and its real logarithm would be undefined half the time. Asserted separately from the zero case for that reason. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GAMMALN.PRECISE LibreOffice Calc

=GAMMALN.PRECISE(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0, GAMMALN.PRECISE returns the #NUM! error value." Gamma has a pole at 0, so its logarithm diverges. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
GT Excel for the web

=GT("b","a")=("b">"a")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240.; MISMATCH vs expected: expected True, got '#NAME?'
GT LibreOffice Calc

=GT("b","a")=("b">"a")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240.; MISMATCH vs expected: expected True, got '#NAME?'
GT Excel for the web

=GT(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240.; MISMATCH vs expected: expected False, got '#NAME?'
GT LibreOffice Calc

=GT(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240.; MISMATCH vs expected: expected False, got '#NAME?'
GT Excel for the web

=GT(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints GT(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `>` operator" clause. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
GT LibreOffice Calc

=GT(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints GT(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `>` operator" clause. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
GT Excel for the web

=GT(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `>` equivalence. This is the case that separates GT from its neighbours, and Google publishes no example of it. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240. The definition's word is "strictly greater than", which is what makes GT(5,5) FALSE.; MISMATCH vs expected: expected False, got '#NAME?'
GT LibreOffice Calc

=GT(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `>` equivalence. This is the case that separates GT from its neighbours, and Google publishes no example of it. Google's GT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098240. The definition's word is "strictly greater than", which is what makes GT(5,5) FALSE.; MISMATCH vs expected: expected False, got '#NAME?'
GTE Excel for the web

=GTE("b","a")=("b">="a")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975.; MISMATCH vs expected: expected True, got '#NAME?'
GTE LibreOffice Calc

=GTE("b","a")=("b">="a")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975.; MISMATCH vs expected: expected True, got '#NAME?'
GTE Excel for the web

=GTE(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975.; MISMATCH vs expected: expected False, got '#NAME?'
GTE LibreOffice Calc

=GTE(A2,A3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975.; MISMATCH vs expected: expected False, got '#NAME?'
GTE Excel for the web

=GTE(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints GTE(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `>=` operator" clause. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
GTE LibreOffice Calc

=GTE(2,3)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints GTE(2,3) with no result; FALSE is DERIVED from the page's one-line definition and its "Equivalent to the `>=` operator" clause. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected False, got '#NAME?'
GTE Excel for the web

=GTE(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `>=` equivalence. This is the case that separates GTE from its neighbours, and Google publishes no example of it. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975. The definition reads "greater than or equal to", which is what makes GTE(5,5) TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
GTE LibreOffice Calc

=GTE(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `>=` equivalence. This is the case that separates GTE from its neighbours, and Google publishes no example of it. Google's GTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093975. The definition reads "greater than or equal to", which is what makes GTE(5,5) TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
HLOOKUP LibreOffice Calc

=HLOOKUP("a",A1:C2,5,FALSE)

Actual result
#VALUE!

Documented / expected
#REF!

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

MISMATCH vs expected: expected '#REF!', got '#VALUE!'
HYPGEOM.DIST LibreOffice Calc

=HYPGEOM.DIST(1,4,25,20,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If population_s <= 0 or population_s > number_population, HYPGEOM.DIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
HYPGEOM.DIST LibreOffice Calc

=HYPGEOM.DIST(1,4,8,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If number_pop <= 0, HYPGEOM.DIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
HYPGEOM.DIST LibreOffice Calc

=HYPGEOM.DIST(1,25,8,20,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If number_sample <= 0 or number_sample > number_population, HYPGEOM.DIST returns the #NUM! error value." Sampling 25 items without replacement from a population of 20 is impossible. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
HYPGEOM.DIST Excel for the web

=HYPGEOM.DIST(5,4,8,20,TRUE)

Actual result
1

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Excel documents: "If sample_s < 0 or sample_s is greater than the lesser of number_sample or population_s, HYPGEOM.DIST returns the #NUM! error value." 5 successes cannot occur in a sample of 4. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got 1
HYPGEOM.DIST LibreOffice Calc

=HYPGEOM.DIST(5,4,8,20,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If sample_s < 0 or sample_s is greater than the lesser of number_sample or population_s, HYPGEOM.DIST returns the #NUM! error value." 5 successes cannot occur in a sample of 4. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
HYPGEOMDIST Google Sheets

=ROUND(HYPGEOMDIST(1.9,4.9,8.9,20.9),12)

Actual result
0.2724458204

Documented / expected
0.363261093911

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Excel documents, as the first remark on the page: "All arguments are truncated to integers." Truncation (toward zero), not rounding: 1.9, 4.9, 8.9, 20.9 must become 1, 4, 8, 20 and reproduce the documented example's answer exactly. Chosen with fractional parts of .9 precisely so that an engine which ROUNDS instead of truncating gets 2, 5, 9, 21 and a visibly different number (0.4067...), rather than accidentally passing. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected 0.363261093911, got 0.2724458204
HYPGEOMDIST Excel for the web

=HYPGEOMDIST(1,0,8,20)

Actual result
0

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

Excel documents: "If number_sample <= 0 or number_sample > number_population, HYPGEOMDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got 0
HYPGEOMDIST LibreOffice Calc

=HYPGEOMDIST(1,0,8,20)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If number_sample <= 0 or number_sample > number_population, HYPGEOMDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
HYPGEOMDIST Excel for the web

=HYPGEOMDIST(5,4,8,20)

Actual result
0

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

Excel documents: "If sample_s < 0 or sample_s is greater than the lesser of number_sample or population_s, HYPGEOMDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got 0
HYPGEOMDIST LibreOffice Calc

=HYPGEOMDIST(5,4,8,20)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If sample_s < 0 or sample_s is greater than the lesser of number_sample or population_s, HYPGEOMDIST returns the #NUM! error value." EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #VALUE! here instead of the documented #NUM! -- the same systemic #VALUE!-substitution pattern already recorded across this corpus, an error-code difference rather than a computation one. Set up from Microsoft's own worked-example table: A2 = 1 (number of successes in the sample), A3 = 4 (sample size), A4 = 8 (number of successes in the population) and A5 = 20 (population size), pasted at A1 as the page describes. Column F is untouched because this harness writes the formula under test into cell F1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
IFERROR LibreOffice Calc

=IFERROR(INDIRECT("'Nope'!B2"),"missing")

Actual result
#REF!

Documented / expected
missing

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

Microsoft documents IFERROR as returning value_if_error for any of #N/A, #VALUE!, #REF!, #DIV/0!, #NUM!, #NAME? and #NULL! -- #REF! is explicitly in that list, so the source of the #REF! (a missing sheet name inside INDIRECT) should not matter. Excel function reference: https://support.microsoft.com/en-us/office/excel-functions-alphabetical-b3944572-255d-4efb-bb96-c6d90033e188; MISMATCH vs expected: expected 'missing', got '#REF!'
IMCOS Google Sheets

=IMCOS(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents, on this page specifically: "If inumber is a logical value, IMCOS returns the #VALUE! error value." This is a deliberate refusal to coerce, and it is the sort of guard an engine drops: TRUE coerces to 1 in almost every other numeric context, so an implementation that simply converts its argument to a number computes cos(1) = 0.54030230586814 and returns a plausible answer where Excel raises an error. EXECUTED RESULT, and a SILENT WRONG ANSWER: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the string "0.54030230586814" -- that is cos(1), i.e. TRUE was coerced to 1 and fed to the function -- where the page documents #VALUE!. The same coercion happens on this batch's IMCOSH, IMCOT, IMCSC and IMCSCH when they are called under their unprefixed names (returning cosh(1), cot(1), csc(1) and csch(1) respectively), so it is one behaviour across the complex family rather than a slip in one function.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMCOS LibreOffice Calc

=IMCOS(TRUE)

Actual result
0.54030230586814

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents, on this page specifically: "If inumber is a logical value, IMCOS returns the #VALUE! error value." This is a deliberate refusal to coerce, and it is the sort of guard an engine drops: TRUE coerces to 1 in almost every other numeric context, so an implementation that simply converts its argument to a number computes cos(1) = 0.54030230586814 and returns a plausible answer where Excel raises an error. EXECUTED RESULT, and a SILENT WRONG ANSWER: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the string "0.54030230586814" -- that is cos(1), i.e. TRUE was coerced to 1 and fed to the function -- where the page documents #VALUE!. The same coercion happens on this batch's IMCOSH, IMCOT, IMCSC and IMCSCH when they are called under their unprefixed names (returning cosh(1), cot(1), csc(1) and csch(1) respectively), so it is one behaviour across the complex family rather than a slip in one function.; MISMATCH vs expected: expected '#VALUE!', got '0.54030230586814'
IMCOSH LibreOffice Calc

=IMCOSH("4+3i")

Actual result
#NAME?

Documented / expected
-27.0349456030742+3.85115333481178i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMCOSH("4+3i")' with the result -27.0349456030742+3.85115333481178i. Derived independently with mpmath at 40 digits from cosh(x+yi) = cosh(x)cos(y) + i*sinh(x)sin(y): cosh(4)cos(3) = -27.034945603074224648 and sinh(4)sin(3) = 3.8511533348117775366, then rendered through this corpus's own implementation of Excel's complex-string format, which reproduces the published string byte for byte. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOSH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOSH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOSH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOSH, COM.MICROSOFT.IMCOSH, ORG.OPENOFFICE.IMCOSH and _xlfn.ORG.OPENOFFICE.IMCOSH are all #NAME? on every build, while the UNPREFIXED IMCOSH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOSH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOSH token Excel writes -- meaning a workbook saved by Excel that uses IMCOSH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '-27.0349456030742+3.85115333481178i', got '#NAME?'
IMCOSH Google Sheets

=IMCOSH(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMCOSH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOSH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOSH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOSH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOSH, COM.MICROSOFT.IMCOSH, ORG.OPENOFFICE.IMCOSH and _xlfn.ORG.OPENOFFICE.IMCOSH are all #NAME? on every build, while the UNPREFIXED IMCOSH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOSH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOSH token Excel writes -- meaning a workbook saved by Excel that uses IMCOSH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMCOSH LibreOffice Calc

=IMCOSH(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMCOSH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOSH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOSH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOSH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOSH, COM.MICROSOFT.IMCOSH, ORG.OPENOFFICE.IMCOSH and _xlfn.ORG.OPENOFFICE.IMCOSH are all #NAME? on every build, while the UNPREFIXED IMCOSH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOSH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOSH token Excel writes -- meaning a workbook saved by Excel that uses IMCOSH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMCOSH LibreOffice Calc

=IMCOSH("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMCOSH returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOSH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOSH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOSH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOSH, COM.MICROSOFT.IMCOSH, ORG.OPENOFFICE.IMCOSH and _xlfn.ORG.OPENOFFICE.IMCOSH are all #NAME? on every build, while the UNPREFIXED IMCOSH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOSH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOSH token Excel writes -- meaning a workbook saved by Excel that uses IMCOSH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMCOT LibreOffice Calc

=IMCOT("4+3i")

Actual result
#NAME?

Documented / expected
0.00490118239430447-0.999266927805902i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMCOT("4+3i")' with the result 0.00490118239430447-0.999266927805902i. Derived independently with mpmath at 40 digits from cot(z) = cos(z)/sin(z) evaluated on the complex plane: 0.0049011823943044733598 - 0.99926692780590154452i, then rendered through this corpus's own implementation of Excel's complex-string format, which reproduces the published string byte for byte. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOT is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOT, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOT here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOT, COM.MICROSOFT.IMCOT, ORG.OPENOFFICE.IMCOT and _xlfn.ORG.OPENOFFICE.IMCOT are all #NAME? on every build, while the UNPREFIXED IMCOT(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOT correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOT token Excel writes -- meaning a workbook saved by Excel that uses IMCOT arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '0.00490118239430447-0.999266927805902i', got '#NAME?'
IMCOT Google Sheets

=IMCOT(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMCOT returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOT is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOT, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOT here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOT, COM.MICROSOFT.IMCOT, ORG.OPENOFFICE.IMCOT and _xlfn.ORG.OPENOFFICE.IMCOT are all #NAME? on every build, while the UNPREFIXED IMCOT(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOT correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOT token Excel writes -- meaning a workbook saved by Excel that uses IMCOT arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMCOT LibreOffice Calc

=IMCOT(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMCOT returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOT is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOT, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOT here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOT, COM.MICROSOFT.IMCOT, ORG.OPENOFFICE.IMCOT and _xlfn.ORG.OPENOFFICE.IMCOT are all #NAME? on every build, while the UNPREFIXED IMCOT(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOT correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOT token Excel writes -- meaning a workbook saved by Excel that uses IMCOT arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMCOT LibreOffice Calc

=IMCOT("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMCOT returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCOT is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCOT, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCOT here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCOT, COM.MICROSOFT.IMCOT, ORG.OPENOFFICE.IMCOT and _xlfn.ORG.OPENOFFICE.IMCOT are all #NAME? on every build, while the UNPREFIXED IMCOT(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCOT correctly, and its OOXML import simply has no mapping for the _xlfn.IMCOT token Excel writes -- meaning a workbook saved by Excel that uses IMCOT arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMCOTH Excel for the web

=ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

A STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0, got '#NAME?'
IMCOTH LibreOffice Calc

=ROUND(IMABS(IMSUB(IMCOTH("3+2i"),IMDIV(1,IMTANH("3+2i")))),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

A STRUCTURAL assertion with no derived constant. The page defines the function only by name -- "returns the hyperbolic cotangent of the given complex number" -- and its sibling page defines IMTANH as the hyperbolic tangent; coth = 1/tanh is what those two names mean, so the two spellings must agree in the same engine whatever either computes. Compared through IMABS of the difference, because complex results are strings and cannot be subtracted with `-`. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0, got '#NAME?'
IMCOTH Excel for the web

=IMCOTH(COMPLEX(4,1))

Actual result
#NAME?

Documented / expected
0.999720649533931-0.000609900253822228i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '0.999720649533931-0.000609900253822228i', got '#NAME?'
IMCOTH LibreOffice Calc

=IMCOTH(COMPLEX(4,1))

Actual result
#NAME?

Documented / expected
0.999720649533931-0.000609900253822228i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table in the article body: =IMCOTH(COMPLEX(4,1)) -> 0.999720649533931-0.000609900253822228i. Derived independently as coth(4+i) = 0.999720649533930749036738985046491656585 - 0.0006099002538222275728563166231837522767836i, which rounds to the published 15 significant digits exactly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '0.999720649533931-0.000609900253822228i', got '#NAME?'
IMCOTH Excel for the web

=ROUND(IMAGINARY(IMCOTH("3+2i")),17)

Actual result
#NAME?

Documented / expected
0.00373971037633696

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

The imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.00373971037633696, got '#NAME?'
IMCOTH LibreOffice Calc

=ROUND(IMAGINARY(IMCOTH("3+2i")),17)

Actual result
#NAME?

Documented / expected
0.00373971037633696

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

The imaginary half of the same published result, 0.00373971037633696, derived independently as Im coth(3+2i) = 0.003739710376336956660117408691902576240006. Rounded at 17 decimal places, which is 15 significant digits for a number of this size. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.00373971037633696, got '#NAME?'
IMCOTH Excel for the web

=ROUND(IMCOTH(3.5),14)

Actual result
#NAME?

Documented / expected
1.00182542850644

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 1.00182542850644, got '#NAME?'
IMCOTH LibreOffice Calc

=ROUND(IMCOTH(3.5),14)

Actual result
#NAME?

Documented / expected
1.00182542850644

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH(3.5) -> 1.00182542850644. Derived independently as coth(3.5) = 1.001825428506443467329849802769891235631. ROUND-wrapped at 14 places, which is where the published figure ends. The `number` argument description is what licenses a bare real here: "a real number interpreted as a complex number with imaginary parts equal to 0". Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 1.00182542850644, got '#NAME?'
IMCOTH Excel for the web

=ROUND(IMREAL(IMCOTH("3+2i")),15)

Actual result
#NAME?

Documented / expected
0.996757796569358

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.996757796569358, got '#NAME?'
IMCOTH LibreOffice Calc

=ROUND(IMREAL(IMCOTH("3+2i")),15)

Actual result
#NAME?

Documented / expected
0.996757796569358

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMCOTH("3+2i") -> 0.996757796569358+0.00373971037633696i. This case asserts the REAL part of that value, taken through IMREAL so that a formatting difference cannot be mistaken for a numerical one. Derived independently as Re coth(3+2i) = 0.996757796569358310460968797117470718332. Google's IMCOTH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366256.; MISMATCH vs expected: expected 0.996757796569358, got '#NAME?'
IMCSC LibreOffice Calc

=IMCSC("4+3i")

Actual result
#NAME?

Documented / expected
-0.0754898329158637+0.0648774713706355i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMCSC("4+3i")' with the result -0.0754898329158637+0.0648774713706355i. Derived independently with mpmath at 40 digits from csc(z) = 1/sin(z): -0.075489832915863699572 + 0.064877471370635490483i, then rendered through this corpus's own implementation of Excel's complex-string format, which reproduces the published string byte for byte. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSC, COM.MICROSOFT.IMCSC, ORG.OPENOFFICE.IMCSC and _xlfn.ORG.OPENOFFICE.IMCSC are all #NAME? on every build, while the UNPREFIXED IMCSC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSC correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSC token Excel writes -- meaning a workbook saved by Excel that uses IMCSC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '-0.0754898329158637+0.0648774713706355i', got '#NAME?'
IMCSC Google Sheets

=IMCSC(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMCSC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSC, COM.MICROSOFT.IMCSC, ORG.OPENOFFICE.IMCSC and _xlfn.ORG.OPENOFFICE.IMCSC are all #NAME? on every build, while the UNPREFIXED IMCSC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSC correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSC token Excel writes -- meaning a workbook saved by Excel that uses IMCSC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMCSC LibreOffice Calc

=IMCSC(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMCSC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSC, COM.MICROSOFT.IMCSC, ORG.OPENOFFICE.IMCSC and _xlfn.ORG.OPENOFFICE.IMCSC are all #NAME? on every build, while the UNPREFIXED IMCSC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSC correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSC token Excel writes -- meaning a workbook saved by Excel that uses IMCSC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMCSC LibreOffice Calc

=IMCSC("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMCSC returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSC, COM.MICROSOFT.IMCSC, ORG.OPENOFFICE.IMCSC and _xlfn.ORG.OPENOFFICE.IMCSC are all #NAME? on every build, while the UNPREFIXED IMCSC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSC correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSC token Excel writes -- meaning a workbook saved by Excel that uses IMCSC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMCSCH LibreOffice Calc

=IMCSCH("4+3i")

Actual result
#NAME?

Documented / expected
-0.036275889628626-0.0051744731840194i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMCSCH("4+3i")' with the result -0.036275889628626-0.0051744731840194i. Derived independently with mpmath at 40 digits from csch(z) = 1/sinh(z): -0.036275889628626011594 - 0.0051744731840193976541i, then rendered through this corpus's own implementation of Excel's complex-string format, which reproduces the published string byte for byte. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSCH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSCH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSCH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSCH, COM.MICROSOFT.IMCSCH, ORG.OPENOFFICE.IMCSCH and _xlfn.ORG.OPENOFFICE.IMCSCH are all #NAME? on every build, while the UNPREFIXED IMCSCH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSCH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSCH token Excel writes -- meaning a workbook saved by Excel that uses IMCSCH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '-0.036275889628626-0.0051744731840194i', got '#NAME?'
IMCSCH Google Sheets

=IMCSCH(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMCSCH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSCH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSCH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSCH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSCH, COM.MICROSOFT.IMCSCH, ORG.OPENOFFICE.IMCSCH and _xlfn.ORG.OPENOFFICE.IMCSCH are all #NAME? on every build, while the UNPREFIXED IMCSCH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSCH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSCH token Excel writes -- meaning a workbook saved by Excel that uses IMCSCH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMCSCH LibreOffice Calc

=IMCSCH(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMCSCH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSCH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSCH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSCH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSCH, COM.MICROSOFT.IMCSCH, ORG.OPENOFFICE.IMCSCH and _xlfn.ORG.OPENOFFICE.IMCSCH are all #NAME? on every build, while the UNPREFIXED IMCSCH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSCH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSCH token Excel writes -- meaning a workbook saved by Excel that uses IMCSCH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMCSCH LibreOffice Calc

=IMCSCH("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMCSCH returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMCSCH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMCSCH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMCSCH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMCSCH, COM.MICROSOFT.IMCSCH, ORG.OPENOFFICE.IMCSCH and _xlfn.ORG.OPENOFFICE.IMCSCH are all #NAME? on every build, while the UNPREFIXED IMCSCH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMCSCH correctly, and its OOXML import simply has no mapping for the _xlfn.IMCSCH token Excel writes -- meaning a workbook saved by Excel that uses IMCSCH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is recorded here as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMLOG Excel for the web

=ROUND(IMABS(IMSUB(IMLOG("1+i",2),IMLOG2("1+i"))),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

A structural assertion with no derived constant, from the Notes bullet "IMLOG is equivalent to IMLOG2 given base of 2." Asserted on "1+i" rather than a real, because that is where the two implementations could differ without any published example noticing. Compared through IMABS of the difference, since complex results are strings. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 0, got '#NAME?'
IMLOG LibreOffice Calc

=ROUND(IMABS(IMSUB(IMLOG("1+i",2),IMLOG2("1+i"))),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

A structural assertion with no derived constant, from the Notes bullet "IMLOG is equivalent to IMLOG2 given base of 2." Asserted on "1+i" rather than a real, because that is where the two implementations could differ without any published example noticing. Compared through IMABS of the difference, since complex results are strings. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 0, got '#NAME?'
IMLOG Excel for the web

=ROUND(IMLOG(100,10)-LOG(100,10),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

A structural assertion with no derived constant. The Notes bullet reads: "IMLOG is equivalent to LOG for all non-complex values that are greater than zero." Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 0, got '#NAME?'
IMLOG LibreOffice Calc

=ROUND(IMLOG(100,10)-LOG(100,10),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

A structural assertion with no derived constant. The Notes bullet reads: "IMLOG is equivalent to LOG for all non-complex values that are greater than zero." Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 0, got '#NAME?'
IMLOG Excel for the web

=IMLOG("1+i", 3.5)

Actual result
#NAME?

Documented / expected
0.276647377832556+0.626932774314643i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim: =IMLOG("1+i", 3.5) -> 0.276647377832556+0.626932774314643i. Derived independently as log(1+i)/log(3.5) = 0.2766473778325561086024443610317785858615 + 0.6269327743146426385843035649172255217738i. NOTE THAT THE PAGE NEVER STATES A BRANCH: there is no sentence about the principal value or the branch cut of the complex logarithm anywhere on it, so this case asserts the published value and the corpus asserts nothing about arguments where the branch would matter. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected '0.276647377832556+0.626932774314643i', got '#NAME?'
IMLOG LibreOffice Calc

=IMLOG("1+i", 3.5)

Actual result
#NAME?

Documented / expected
0.276647377832556+0.626932774314643i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim: =IMLOG("1+i", 3.5) -> 0.276647377832556+0.626932774314643i. Derived independently as log(1+i)/log(3.5) = 0.2766473778325561086024443610317785858615 + 0.6269327743146426385843035649172255217738i. NOTE THAT THE PAGE NEVER STATES A BRANCH: there is no sentence about the principal value or the branch cut of the complex logarithm anywhere on it, so this case asserts the published value and the corpus asserts nothing about arguments where the branch would matter. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected '0.276647377832556+0.626932774314643i', got '#NAME?'
IMLOG Excel for the web

=ROUND(IMAGINARY(IMLOG(COMPLEX(25, 34), 2.3)),14)

Actual result
#NAME?

Documented / expected
1.12470086031758

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

The imaginary half of the same published result, derived independently as 1.124700860317582465513509687755013399277. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 1.12470086031758, got '#NAME?'
IMLOG LibreOffice Calc

=ROUND(IMAGINARY(IMLOG(COMPLEX(25, 34), 2.3)),14)

Actual result
#NAME?

Documented / expected
1.12470086031758

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

The imaginary half of the same published result, derived independently as 1.124700860317582465513509687755013399277. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 1.12470086031758, got '#NAME?'
IMLOG Excel for the web

=IMLOG(100,10)

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

TYPE CORRECTION (2026-09-01, post-ingest): first authored as the number 2; the executed engine returns the TEXT string '2' -- like every IM* function, IMLOG returns complex results as text, and Google's published table prints the figure typelessly. The expected is now the string, matching the engine's actual (and documented-family-consistent) return type; the printed figure itself was never in dispute. GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(100, 10) -> 2. IMLOG's page is the only one of the three complex pages in this batch whose Sample-formulas inputs and Formula/Result table rows MATCH each other, so its three published results can be paired with its three samples directly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '2', got '#NAME?'
IMLOG LibreOffice Calc

=IMLOG(100,10)

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(100, 10) -> 2. IMLOG's page is the only one of the three complex pages in this batch whose Sample-formulas inputs and Formula/Result table rows MATCH each other, so its three published results can be paired with its three samples directly. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 2, got '#NAME?'
IMLOG Excel for the web

=ROUND(IMREAL(IMLOG(COMPLEX(25, 34), 2.3)),14)

Actual result
#NAME?

Documented / expected
4.49324546771284

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(COMPLEX(25, 34), 2.3) -> 4.49324546771284+1.12470086031758i. Real part derived independently as 4.493245467712837686199121881993797704048. The base argument is the only one the page constrains: "Must be a positive real number." No default is stated and the page presents base as required. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 4.49324546771284, got '#NAME?'
IMLOG LibreOffice Calc

=ROUND(IMREAL(IMLOG(COMPLEX(25, 34), 2.3)),14)

Actual result
#NAME?

Documented / expected
4.49324546771284

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMLOG(COMPLEX(25, 34), 2.3) -> 4.49324546771284+1.12470086031758i. Real part derived independently as 4.493245467712837686199121881993797704048. The base argument is the only one the page constrains: "Must be a positive real number." No default is stated and the page presents base as required. Google's IMLOG page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366486.; MISMATCH vs expected: expected 4.49324546771284, got '#NAME?'
IMSEC Google Sheets

=IMSEC("4+3i")

Actual result
-0.065294027857947-0.0752249603027732i

Documented / expected
-0.0652940278579471-0.0752249603027732i

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Microsoft publishes '=IMSEC("4+3i")' with the result -0.0652940278579471-0.0752249603027732i. Derived independently with mpmath at 40 digits: sec(z) = 1/cos(z), with cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y). At 40 digits 1/cos(4+3i) = -0.06529402785794704644515821 - 0.07522496030277322686557715i. Cross-check on the modulus: |cos(4+3i)|^2 = 100.785068044323640479, and 1/|cos| = 0.09961..., consistent with |sec| = sqrt(0.0652940278579470^2 + 0.0752249603027732^2) = 0.0996136.... EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result. CROSS-VERSION DRIFT FOUND HERE, in the last digit. Under the unprefixed name the four builds do NOT agree: 24.2.0.3 and 24.8.7.2 return -0.0652940278579471-0.0752249603027732i, which is Microsoft's published string byte for byte, while 25.2.0.3 and 25.8.7.3 return -0.065294027857947-0.0752249603027732i -- one significant digit shorter. Neither is a wrong value: the exact real part is -0.06529402785794704644515821, the correctly-rounded double is -0.065294027857947051 (whose 15-digit rendering ends ...471, matching Excel and the older builds) and the newer builds hold the adjacent double -0.065294027857947037 (whose 15-digit rendering ends ...47). The two doubles differ by one unit in the last place, about 1.4e-17, and straddle a 15-digit rounding boundary, which is the only reason the STRINGS differ at all. Recorded as a precision/formatting difference, not as a value error -- but it is a real regression in byte-for-byte agreement with Excel, and because IM* results are strings, an exact-match comparison in a spreadsheet would flag it.; MISMATCH vs expected: expected '-0.0652940278579471-0.0752249603027732i', got '-0.065294027857947-0.0752249603027732i'
IMSEC LibreOffice Calc

=IMSEC("4+3i")

Actual result
#NAME?

Documented / expected
-0.0652940278579471-0.0752249603027732i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMSEC("4+3i")' with the result -0.0652940278579471-0.0752249603027732i. Derived independently with mpmath at 40 digits: sec(z) = 1/cos(z), with cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y). At 40 digits 1/cos(4+3i) = -0.06529402785794704644515821 - 0.07522496030277322686557715i. Cross-check on the modulus: |cos(4+3i)|^2 = 100.785068044323640479, and 1/|cos| = 0.09961..., consistent with |sec| = sqrt(0.0652940278579470^2 + 0.0752249603027732^2) = 0.0996136.... EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result. CROSS-VERSION DRIFT FOUND HERE, in the last digit. Under the unprefixed name the four builds do NOT agree: 24.2.0.3 and 24.8.7.2 return -0.0652940278579471-0.0752249603027732i, which is Microsoft's published string byte for byte, while 25.2.0.3 and 25.8.7.3 return -0.065294027857947-0.0752249603027732i -- one significant digit shorter. Neither is a wrong value: the exact real part is -0.06529402785794704644515821, the correctly-rounded double is -0.065294027857947051 (whose 15-digit rendering ends ...471, matching Excel and the older builds) and the newer builds hold the adjacent double -0.065294027857947037 (whose 15-digit rendering ends ...47). The two doubles differ by one unit in the last place, about 1.4e-17, and straddle a 15-digit rounding boundary, which is the only reason the STRINGS differ at all. Recorded as a precision/formatting difference, not as a value error -- but it is a real regression in byte-for-byte agreement with Excel, and because IM* results are strings, an exact-match comparison in a spreadsheet would flag it.; MISMATCH vs expected: expected '-0.0652940278579471-0.0752249603027732i', got '#NAME?'
IMSEC Google Sheets

=IMSEC(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMSEC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMSEC LibreOffice Calc

=IMSEC(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMSEC returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMSEC LibreOffice Calc

=IMSEC("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSEC returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSEC is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSEC, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSEC here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSEC, COM.MICROSOFT.IMSEC, ORG.OPENOFFICE.IMSEC and _xlfn.ORG.OPENOFFICE.IMSEC are all #NAME? on every build, while the UNPREFIXED IMSEC(...) evaluates on every build. So LibreOffice implements IMSEC, and its OOXML import simply has no mapping for the _xlfn.IMSEC token Excel writes -- meaning a workbook saved by Excel that uses IMSEC arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMSECH LibreOffice Calc

=IMSECH("4+3i")

Actual result
#NAME?

Documented / expected
-0.0362534969158689-0.00516434460775318i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMSECH("4+3i")' with the result -0.0362534969158689-0.00516434460775318i. Derived independently with mpmath at 40 digits: sech(z) = 1/cosh(z), with cosh(x+yi) = cosh(x)cos(y) + i*sinh(x)sin(y). At 40 digits 1/cosh(4+3i) = -0.03625349691586887189087 - 0.005164344607753179367413i. Cross-check: batch D asserts Microsoft's own IMCOSH("4+3i") = -27.0349456030742+3.85115333481178i, and the product of that number with the value asserted here is 1 to 15 digits, so the two published examples confirm each other.. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSECH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSECH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSECH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSECH, COM.MICROSOFT.IMSECH, ORG.OPENOFFICE.IMSECH and _xlfn.ORG.OPENOFFICE.IMSECH are all #NAME? on every build, while the UNPREFIXED IMSECH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSECH, and its OOXML import simply has no mapping for the _xlfn.IMSECH token Excel writes -- meaning a workbook saved by Excel that uses IMSECH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '-0.0362534969158689-0.00516434460775318i', got '#NAME?'
IMSECH Google Sheets

=IMSECH(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMSECH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSECH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSECH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSECH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSECH, COM.MICROSOFT.IMSECH, ORG.OPENOFFICE.IMSECH and _xlfn.ORG.OPENOFFICE.IMSECH are all #NAME? on every build, while the UNPREFIXED IMSECH(...) evaluates on every build. So LibreOffice implements IMSECH, and its OOXML import simply has no mapping for the _xlfn.IMSECH token Excel writes -- meaning a workbook saved by Excel that uses IMSECH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMSECH LibreOffice Calc

=IMSECH(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMSECH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSECH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSECH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSECH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSECH, COM.MICROSOFT.IMSECH, ORG.OPENOFFICE.IMSECH and _xlfn.ORG.OPENOFFICE.IMSECH are all #NAME? on every build, while the UNPREFIXED IMSECH(...) evaluates on every build. So LibreOffice implements IMSECH, and its OOXML import simply has no mapping for the _xlfn.IMSECH token Excel writes -- meaning a workbook saved by Excel that uses IMSECH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMSECH LibreOffice Calc

=IMSECH("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSECH returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSECH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSECH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSECH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSECH, COM.MICROSOFT.IMSECH, ORG.OPENOFFICE.IMSECH and _xlfn.ORG.OPENOFFICE.IMSECH are all #NAME? on every build, while the UNPREFIXED IMSECH(...) evaluates on every build. So LibreOffice implements IMSECH, and its OOXML import simply has no mapping for the _xlfn.IMSECH token Excel writes -- meaning a workbook saved by Excel that uses IMSECH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMSINH LibreOffice Calc

=IMSINH("4+3i")

Actual result
#NAME?

Documented / expected
-27.0168132580039+3.85373803791938i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMSINH("4+3i")' with the result -27.0168132580039+3.85373803791938i. Derived independently with mpmath at 40 digits: sinh(x+yi) = sinh(x)cos(y) + i*cosh(x)sin(y). At 40 digits sinh(4)cos(3) = -27.01681325800393448814 and cosh(4)sin(3) = 3.853738037919377321623. Cross-check against the sibling published example: batch D asserts IMCOSH("4+3i") = -27.0349456030742+3.85115333481178i, and cosh^2 - sinh^2 = 1 holds for these two complex values to 15 digits.. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSINH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSINH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSINH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSINH, COM.MICROSOFT.IMSINH, ORG.OPENOFFICE.IMSINH and _xlfn.ORG.OPENOFFICE.IMSINH are all #NAME? on every build, while the UNPREFIXED IMSINH(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMSINH, and its OOXML import simply has no mapping for the _xlfn.IMSINH token Excel writes -- meaning a workbook saved by Excel that uses IMSINH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '-27.0168132580039+3.85373803791938i', got '#NAME?'
IMSINH Google Sheets

=IMSINH(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMSINH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSINH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSINH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSINH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSINH, COM.MICROSOFT.IMSINH, ORG.OPENOFFICE.IMSINH and _xlfn.ORG.OPENOFFICE.IMSINH are all #NAME? on every build, while the UNPREFIXED IMSINH(...) evaluates on every build. So LibreOffice implements IMSINH, and its OOXML import simply has no mapping for the _xlfn.IMSINH token Excel writes -- meaning a workbook saved by Excel that uses IMSINH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMSINH LibreOffice Calc

=IMSINH(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMSINH returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSINH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSINH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSINH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSINH, COM.MICROSOFT.IMSINH, ORG.OPENOFFICE.IMSINH and _xlfn.ORG.OPENOFFICE.IMSINH are all #NAME? on every build, while the UNPREFIXED IMSINH(...) evaluates on every build. So LibreOffice implements IMSINH, and its OOXML import simply has no mapping for the _xlfn.IMSINH token Excel writes -- meaning a workbook saved by Excel that uses IMSINH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMSINH LibreOffice Calc

=IMSINH("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMSINH returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMSINH is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMSINH, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMSINH here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMSINH, COM.MICROSOFT.IMSINH, ORG.OPENOFFICE.IMSINH and _xlfn.ORG.OPENOFFICE.IMSINH are all #NAME? on every build, while the UNPREFIXED IMSINH(...) evaluates on every build. So LibreOffice implements IMSINH, and its OOXML import simply has no mapping for the _xlfn.IMSINH token Excel writes -- meaning a workbook saved by Excel that uses IMSINH arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMSQRT Excel for the web

=IMSQRT("i")

Actual result
0.707106781186548+0.707106781186547i

Documented / expected
0.707106781186548+0.707106781186548i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

Exact: r = 1 and theta = pi/2, so the answer is cos(pi/4) + i*sin(pi/4), and cos(pi/4) = sin(pi/4) = sqrt(2)/2 = 0.707106781186547524401 EXACTLY -- the two parts are the same number. That is why this case is worth asserting: the two coefficients must be printed identically, and any engine whose polar route computes them along different paths will show it here in the last digit. (Python's own cmath.sqrt does exactly that, returning 0.7071067811865476 for the real part and 0.7071067811865475 for the imaginary one; all four LibreOffice builds print both as 0.707106781186548, which is the correctly-rounded value.) EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.; MISMATCH vs expected: expected '0.707106781186548+0.707106781186548i', got '0.707106781186548+0.707106781186547i'
IMSQRT Excel for the web

=IMSQRT("-4")

Actual result
1.22514845490862E-16+2i

Documented / expected
2i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

Exact: r = 4, theta = pi, so the answer is 2(cos(pi/2) + i*sin(pi/2)) = 0 + 2i. The real part is exactly zero and is dropped, but the coefficient is 2, so it IS printed. This case is the control for the IMSQRT("-1") case above: it exercises the same "omit the zero real part" rule on the same axis, and all four LibreOffice builds agree on it -- which is what isolates the 24.8-to-25.2 change to the coefficient-of-one rule specifically, rather than to the handling of negative reals in general. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.; MISMATCH vs expected: expected '2i', got '1.22514845490862E-16+2i'
IMSQRT Google Sheets

=IMSQRT("-4")

Actual result
1.22464679914735E-16+2i

Documented / expected
2i

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Exact: r = 4, theta = pi, so the answer is 2(cos(pi/2) + i*sin(pi/2)) = 0 + 2i. The real part is exactly zero and is dropped, but the coefficient is 2, so it IS printed. This case is the control for the IMSQRT("-1") case above: it exercises the same "omit the zero real part" rule on the same axis, and all four LibreOffice builds agree on it -- which is what isolates the 24.8-to-25.2 change to the coefficient-of-one rule specifically, rather than to the handling of negative reals in general. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.; MISMATCH vs expected: expected '2i', got '1.22464679914735E-16+2i'
IMSQRT Excel for the web

=IMSQRT("-1")

Actual result
6.1257422745431E-17+i

Documented / expected
i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

Exact and definitional: the principal square root of -1 is i. In the documented polar form r = 1 and theta = pi, so the answer is cos(pi/2) + i*sin(pi/2) = 0 + 1i, with a real part of exactly zero and an imaginary coefficient of exactly 1. Excel's format therefore drops the real term entirely AND drops the digit 1, printing "i". EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. CROSS-VERSION DRIFT: THIS IS THE CASE THAT MOVES. The four pinned builds do not agree on this formula. 24.2.0.3 and 24.8.7.2 return "1i"; 25.2.0.3 and 25.8.7.3 return "i". Excel's documented format prints a coefficient of exactly 1 as "i" with no digit -- the rule this corpus validated against twenty published Microsoft strings, among them IMSUB("13+4i","5+3i") = "8+i" on Microsoft's own IMSUB page, where the imaginary coefficient is likewise exactly 1 and is likewise printed with no digit. So the newer builds are right and the older ones are wrong, and the change landed somewhere between 24.8.7.2 and 25.2.0.3. The NUMBER is identical on all four builds; only its rendering changed, so this is recorded as a formatting-only difference and not as a value error. It matters anyway: IM* functions return TEXT, so =IMSQRT("-1")="i" is FALSE on 24.2/24.8 and TRUE on 25.2/25.8, and any formula that compares, matches or joins these strings changes its answer when the workbook moves between releases.; MISMATCH vs expected: expected 'i', got '6.1257422745431E-17+i'
IMSQRT Google Sheets

=IMSQRT("-1")

Actual result
6.12323399573677E-17+i

Documented / expected
i

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Exact and definitional: the principal square root of -1 is i. In the documented polar form r = 1 and theta = pi, so the answer is cos(pi/2) + i*sin(pi/2) = 0 + 1i, with a real part of exactly zero and an imaginary coefficient of exactly 1. Excel's format therefore drops the real term entirely AND drops the digit 1, printing "i". EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. CROSS-VERSION DRIFT: THIS IS THE CASE THAT MOVES. The four pinned builds do not agree on this formula. 24.2.0.3 and 24.8.7.2 return "1i"; 25.2.0.3 and 25.8.7.3 return "i". Excel's documented format prints a coefficient of exactly 1 as "i" with no digit -- the rule this corpus validated against twenty published Microsoft strings, among them IMSUB("13+4i","5+3i") = "8+i" on Microsoft's own IMSUB page, where the imaginary coefficient is likewise exactly 1 and is likewise printed with no digit. So the newer builds are right and the older ones are wrong, and the change landed somewhere between 24.8.7.2 and 25.2.0.3. The NUMBER is identical on all four builds; only its rendering changed, so this is recorded as a formatting-only difference and not as a value error. It matters anyway: IM* functions return TEXT, so =IMSQRT("-1")="i" is FALSE on 24.2/24.8 and TRUE on 25.2/25.8, and any formula that compares, matches or joins these strings changes its answer when the workbook moves between releases.; MISMATCH vs expected: expected 'i', got '6.12323399573677E-17+i'
IMTAN LibreOffice Calc

=IMTAN("4+3i")

Actual result
#NAME?

Documented / expected
0.00490825806749606+1.00070953606723i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Microsoft publishes '=IMTAN("4+3i")' with the result 0.00490825806749606+1.00070953606723i. Derived independently with mpmath at 40 digits: tan(z) = sin(z)/cos(z). At 40 digits tan(4+3i) = 0.004908258067496060259082 + 1.000709536067232939326i. Cross-check against the sibling published example: batch D asserts Microsoft's IMCOT("4+3i") = 0.00490118239430447-0.999266927805902i, and the product of that cotangent with the tangent asserted here is 1 to 15 digits, since cot = 1/tan.. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMTAN is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMTAN, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMTAN here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMTAN, COM.MICROSOFT.IMTAN, ORG.OPENOFFICE.IMTAN and _xlfn.ORG.OPENOFFICE.IMTAN are all #NAME? on every build, while the UNPREFIXED IMTAN(...) evaluates on every build and returns exactly the string asserted here, byte for byte. So LibreOffice implements IMTAN, and its OOXML import simply has no mapping for the _xlfn.IMTAN token Excel writes -- meaning a workbook saved by Excel that uses IMTAN arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '0.00490825806749606+1.00070953606723i', got '#NAME?'
IMTAN Google Sheets

=IMTAN(TRUE)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Engineering

Excel documents: "If inumber is a logical value, IMTAN returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMTAN is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMTAN, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMTAN here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMTAN, COM.MICROSOFT.IMTAN, ORG.OPENOFFICE.IMTAN and _xlfn.ORG.OPENOFFICE.IMTAN are all #NAME? on every build, while the UNPREFIXED IMTAN(...) evaluates on every build. So LibreOffice implements IMTAN, and its OOXML import simply has no mapping for the _xlfn.IMTAN token Excel writes -- meaning a workbook saved by Excel that uses IMTAN arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
IMTAN LibreOffice Calc

=IMTAN(TRUE)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a logical value, IMTAN returns the #VALUE! error value." A deliberate refusal to coerce -- TRUE becomes 1 in nearly every other numeric context. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMTAN is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMTAN, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMTAN here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMTAN, COM.MICROSOFT.IMTAN, ORG.OPENOFFICE.IMTAN and _xlfn.ORG.OPENOFFICE.IMTAN are all #NAME? on every build, while the UNPREFIXED IMTAN(...) evaluates on every build. So LibreOffice implements IMTAN, and its OOXML import simply has no mapping for the _xlfn.IMTAN token Excel writes -- meaning a workbook saved by Excel that uses IMTAN arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
IMTAN LibreOffice Calc

=IMTAN("abc")

Actual result
#NAME?

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

Excel documents: "If inumber is a value that is not in the x+yi or x+yj text format, IMTAN returns the #NUM! error value." Note this is #NUM!, not the #VALUE! that the logical-value clause on the same page specifies -- the two malformed-input branches are documented as returning DIFFERENT errors, which is why both are asserted. STORAGE-FORM GAP, and NOT a missing capability -- the distinction is the whole point of this case. IMTAN is an Excel 2013 addition, so real Excel does not store it in a .xlsx under its plain name: Microsoft's XLSX-extensions future-function list (the reference this harness has used since batch A, mirrored in XlsxWriter's "Formulas added in Excel 2010 and later" table) gives the storage token as _xlfn.IMTAN, alongside _xlfn.IMCOSH, _xlfn.IMCOT, _xlfn.IMCSC, _xlfn.IMCSCH, _xlfn.IMSEC, _xlfn.IMSECH, _xlfn.IMSINH and _xlfn.IMTAN. harness/xlfn_map.py therefore writes _xlfn.IMTAN here, exactly as Excel would. EXECUTED RESULT: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return #NAME? for that token. A five-spelling probe pins down what this is: _xlfn.IMTAN, COM.MICROSOFT.IMTAN, ORG.OPENOFFICE.IMTAN and _xlfn.ORG.OPENOFFICE.IMTAN are all #NAME? on every build, while the UNPREFIXED IMTAN(...) evaluates on every build. So LibreOffice implements IMTAN, and its OOXML import simply has no mapping for the _xlfn.IMTAN token Excel writes -- meaning a workbook saved by Excel that uses IMTAN arrives in LibreOffice as #NAME? even though LibreOffice could compute it. This is the exact mirror image of batch B's COT/COTH/CSC/CSCH finding, where the _xlfn. token was the ONLY spelling LibreOffice accepted, and it is the same class batch D recorded for IMCOSH, IMCOT, IMCSC and IMCSCH. It is recorded as its own divergence class rather than as an ordinary unsupported-function result.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
IMTANH Excel for the web

=IMTANH(COMPLEX(4,1))

Actual result
#NAME?

Documented / expected
1.00027905623447+0.00061024092137626i

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table: =IMTANH(COMPLEX(4,1)) -> 1.00027905623447+0.00061024092137626i. Derived independently as tanh(4+i) = 1.000279056234465568359093202101514584404 + 0.000610240921376259785352673334029321933866i. NOTE THAT THE PAGE'S TWO LISTS DISAGREE ON THEIR INPUTS: the 'Sample formulas' block uses COMPLEX(4,6), 4 and "2+3i", while the Formula/Result table uses COMPLEX(4,1), 3.5 and "3+2i". Only the table's rows carry results, and only those are asserted here. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '1.00027905623447+0.00061024092137626i', got '#NAME?'
IMTANH LibreOffice Calc

=IMTANH(COMPLEX(4,1))

Actual result
#NAME?

Documented / expected
1.00027905623447+0.00061024092137626i

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT, quoted verbatim from the Formula/Result table: =IMTANH(COMPLEX(4,1)) -> 1.00027905623447+0.00061024092137626i. Derived independently as tanh(4+i) = 1.000279056234465568359093202101514584404 + 0.000610240921376259785352673334029321933866i. NOTE THAT THE PAGE'S TWO LISTS DISAGREE ON THEIR INPUTS: the 'Sample formulas' block uses COMPLEX(4,6), 4 and "2+3i", while the Formula/Result table uses COMPLEX(4,1), 3.5 and "3+2i". Only the table's rows carry results, and only those are asserted here. INDEPENDENT DERIVATION. Every figure quoted from these three pages was recomputed here at 40 decimal digits with mpmath before it was written down -- coth/tanh/log evaluated directly on the complex argument -- and all nine of Google's published results reproduce EXACTLY at the 15 significant digits the pages print, correctly rounded. Nothing on these pages needed correcting. NOTE ON THE RESULT FORMAT, WHICH THE PAGE NEVER STATES. None of the three pages contains a sentence describing the shape of the returned complex value -- no "a+bi" rule, no i-versus-j statement, no precision or rounding rule. The format is visible ONLY in the literal result strings the pages print. That is why this file asserts the string form in exactly one case per function and asserts the numeric components through IMREAL/IMAGINARY everywhere else: a difference in formatting and a difference in the mathematics are different findings and should not be able to masquerade as each other. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '1.00027905623447+0.00061024092137626i', got '#NAME?'
IMTANH Excel for the web

=ROUND(IMAGINARY(IMTANH("3+2i")),17)

Actual result
#NAME?

Documented / expected
-0.00376402564150425

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

The imaginary half of the same published result, derived independently as -0.003764025641504248292751221130322690839631. The sign is the point: IMCOTH on the same argument has a POSITIVE imaginary part, so this pair also checks that the two functions are not the same code. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected -0.00376402564150425, got '#NAME?'
IMTANH LibreOffice Calc

=ROUND(IMAGINARY(IMTANH("3+2i")),17)

Actual result
#NAME?

Documented / expected
-0.00376402564150425

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

The imaginary half of the same published result, derived independently as -0.003764025641504248292751221130322690839631. The sign is the point: IMCOTH on the same argument has a POSITIVE imaginary part, so this pair also checks that the two functions are not the same code. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected -0.00376402564150425, got '#NAME?'
IMTANH Excel for the web

=ROUND(IMTANH(3.5),15)

Actual result
#NAME?

Documented / expected
0.998177897611199

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH(3.5) -> 0.998177897611199. Derived independently as tanh(3.5) = 0.9981778976111987092842733524506117173517. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0.998177897611199, got '#NAME?'
IMTANH LibreOffice Calc

=ROUND(IMTANH(3.5),15)

Actual result
#NAME?

Documented / expected
0.998177897611199

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH(3.5) -> 0.998177897611199. Derived independently as tanh(3.5) = 0.9981778976111987092842733524506117173517. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 0.998177897611199, got '#NAME?'
IMTANH Excel for the web

=ROUND(IMREAL(IMTANH("3+2i")),14)

Actual result
#NAME?

Documented / expected
1.00323862735361

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH("3+2i") -> 1.00323862735361-0.00376402564150425i. Real part derived independently as 1.003238627353609801446358597821927259808. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 1.00323862735361, got '#NAME?'
IMTANH LibreOffice Calc

=ROUND(IMREAL(IMTANH("3+2i")),14)

Actual result
#NAME?

Documented / expected
1.00323862735361

Engine
LibreOffice Calc 25.8.7.3

Category
Engineering

GOOGLE'S OWN PUBLISHED RESULT: =IMTANH("3+2i") -> 1.00323862735361-0.00376402564150425i. Real part derived independently as 1.003238627353609801446358597821927259808. Google's IMTANH page, read live on 2026-08-31 at https://support.google.com/docs/answer/9366655.; MISMATCH vs expected: expected 1.00323862735361, got '#NAME?'
INDEX Google Sheets

=INDEX(A1:A3,10)

Actual result
#NUM!

Documented / expected
#REF!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: expected '#REF!', got '#NUM!'
INFO Excel for the web

=ISTEXT(INFO("directory"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "directory" as "Path of the current directory or folder specified in the Excel option, At startup, open all files in". A path is text, so ISTEXT is the documented promise. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures. EXECUTED RESULT: FALSE on all four LibreOffice builds -- INFO("directory") returns #N/A there, and because the IS functions inspect rather than propagate, ISTEXT reports a clean FALSE instead of surfacing the error. So a workbook asking LibreOffice where it is gets no answer and no complaint.; MISMATCH vs expected: expected True, got False
INFO Google Sheets

=ISTEXT(INFO("directory"))

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "directory" as "Path of the current directory or folder specified in the Excel option, At startup, open all files in". A path is text, so ISTEXT is the documented promise. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures. EXECUTED RESULT: FALSE on all four LibreOffice builds -- INFO("directory") returns #N/A there, and because the IS functions inspect rather than propagate, ISTEXT reports a clean FALSE instead of surfacing the error. So a workbook asking LibreOffice where it is gets no answer and no complaint.; MISMATCH vs expected: expected True, got False
INFO LibreOffice Calc

=ISTEXT(INFO("directory"))

Actual result
False

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Information

Excel's type_text table documents "directory" as "Path of the current directory or folder specified in the Excel option, At startup, open all files in". A path is text, so ISTEXT is the documented promise. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Excel for the web

=INFO("memavail")

Actual result
#VALUE!

Documented / expected
#N/A

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel documents, in an Important box: "In previous versions of Microsoft Excel, the \"memavail\", \"memused\", and \"totmem\" type_text values, returned memory information. These type_text values are no longer supported and now return a #N/A error value." That makes #N/A the documented CORRECT answer here, not a failure -- one of the few places in this corpus where an error value is the specification. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
INFO Google Sheets

=INFO("memavail")

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel documents, in an Important box: "In previous versions of Microsoft Excel, the \"memavail\", \"memused\", and \"totmem\" type_text values, returned memory information. These type_text values are no longer supported and now return a #N/A error value." That makes #N/A the documented CORRECT answer here, not a failure -- one of the few places in this corpus where an error value is the specification. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
INFO Excel for the web

=INFO("memused")

Actual result
#VALUE!

Documented / expected
#N/A

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Same documented Important box as INFO("memavail"): "memavail", "memused" and "totmem" "are no longer supported and now return a #N/A error value". All three are asserted separately because the documentation names all three separately, and an engine could easily retire one spelling and not the others. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
INFO Google Sheets

=INFO("memused")

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Same documented Important box as INFO("memavail"): "memavail", "memused" and "totmem" "are no longer supported and now return a #N/A error value". All three are asserted separately because the documentation names all three separately, and an engine could easily retire one spelling and not the others. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
INFO Excel for the web

=ISNUMBER(INFO("numfile"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "numfile" as "Number of worksheets in the open workbooks", and the page's Result column for =INFO("numfile") reads 'a number indicating how many sheets are in the currently open workbooks' -- Microsoft publishes that sentence INSTEAD of a figure, because the figure depends on what is open. So the documented promise is "a number", and ISNUMBER is the exact assertion of it. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Google Sheets

=ISNUMBER(INFO("numfile"))

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "numfile" as "Number of worksheets in the open workbooks", and the page's Result column for =INFO("numfile") reads 'a number indicating how many sheets are in the currently open workbooks' -- Microsoft publishes that sentence INSTEAD of a figure, because the figure depends on what is open. So the documented promise is "a number", and ISNUMBER is the exact assertion of it. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Excel for the web

=LEFT(INFO("origin"),3)="$A:"

Actual result
#VALUE!

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "origin" as returning "the absolute cell reference of the top and leftmost cell visible in the window ... as text prepended with \"$A:\"", and gives worked forms for both reference styles ("$A:$D$9" in A1 style, "$A:R9C4" in R1C1 style). The scroll position is not fixed, but the "$A:" prefix is documented for BOTH styles, so the prefix is what is asserted. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures. EXECUTED RESULT: #N/A on all four LibreOffice builds, propagated from INFO("origin") itself. "directory" and "origin" are the two documented type_text codes LibreOffice does not implement; every other code in this file it answers.; MISMATCH vs expected: expected True, got '#VALUE!'
INFO Google Sheets

=LEFT(INFO("origin"),3)="$A:"

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "origin" as returning "the absolute cell reference of the top and leftmost cell visible in the window ... as text prepended with \"$A:\"", and gives worked forms for both reference styles ("$A:$D$9" in A1 style, "$A:R9C4" in R1C1 style). The scroll position is not fixed, but the "$A:" prefix is documented for BOTH styles, so the prefix is what is asserted. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures. EXECUTED RESULT: #N/A on all four LibreOffice builds, propagated from INFO("origin") itself. "directory" and "origin" are the two documented type_text codes LibreOffice does not implement; every other code in this file it answers.; MISMATCH vs expected: expected True, got '#NAME?'
INFO LibreOffice Calc

=LEFT(INFO("origin"),3)="$A:"

Actual result
#N/A

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Information

Excel's type_text table documents "origin" as returning "the absolute cell reference of the top and leftmost cell visible in the window ... as text prepended with \"$A:\"", and gives worked forms for both reference styles ("$A:$D$9" in A1 style, "$A:R9C4" in R1C1 style). The scroll position is not fixed, but the "$A:" prefix is documented for BOTH styles, so the prefix is what is asserted. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got '#N/A'
INFO Excel for the web

=ISTEXT(INFO("osversion"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "osversion" as "Current operating system version, as text". The words "as text" are the documented guarantee, and ISTEXT asserts precisely that. The string itself is machine-specific (all four builds here return "Linux 7.0"). WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Google Sheets

=ISTEXT(INFO("osversion"))

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "osversion" as "Current operating system version, as text". The words "as text" are the documented guarantee, and ISTEXT asserts precisely that. The string itself is machine-specific (all four builds here return "Linux 7.0"). WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Excel for the web

=OR(INFO("recalc")="Automatic",INFO("recalc")="Manual")

Actual result
#VALUE!

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "recalc" as "Current recalculation mode; returns \"Automatic\" or \"Manual\"", and the page's own Result column for =INFO("recalc") reads '\"Automatic\" or \"Manual\" depending on the current state of your calculation options'. The documentation therefore fixes a two-value enumeration, not a value, so the enumeration is what is asserted. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got '#VALUE!'
INFO Google Sheets

=OR(INFO("recalc")="Automatic",INFO("recalc")="Manual")

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "recalc" as "Current recalculation mode; returns \"Automatic\" or \"Manual\"", and the page's own Result column for =INFO("recalc") reads '\"Automatic\" or \"Manual\" depending on the current state of your calculation options'. The documentation therefore fixes a two-value enumeration, not a value, so the enumeration is what is asserted. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got '#NAME?'
INFO Excel for the web

=ISTEXT(INFO("release"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Excel's type_text table documents "release" as "Version of Microsoft Excel, as text". Again "as text" is the documented guarantee. The string is emphatically build-specific and is NOT assertable: the four pinned LibreOffice builds return four different strings here, and three of them are not version numbers at all but 40-character git commit hashes (24.2.0.3 -> da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1, 24.8.7.2 -> e07d0a63a46349d29051da79b1fde8160bab2a89, 25.2.0.3 -> e1cf4a87eb02d755bce1a01209907ea5ddc8f069), while 25.8.7.3 returns "580(Build:3)". A workbook that parses INFO("release") to branch on version -- the obvious reason to call it -- gets nothing parseable from three of these four releases. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Google Sheets

=ISTEXT(INFO("release"))

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Excel's type_text table documents "release" as "Version of Microsoft Excel, as text". Again "as text" is the documented guarantee. The string is emphatically build-specific and is NOT assertable: the four pinned LibreOffice builds return four different strings here, and three of them are not version numbers at all but 40-character git commit hashes (24.2.0.3 -> da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1, 24.8.7.2 -> e07d0a63a46349d29051da79b1fde8160bab2a89, 25.2.0.3 -> e1cf4a87eb02d755bce1a01209907ea5ddc8f069), while 25.8.7.3 returns "580(Build:3)". A workbook that parses INFO("release") to branch on version -- the obvious reason to call it -- gets nothing parseable from three of these four releases. WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected True, got False
INFO Excel for the web

=INFO("totmem")

Actual result
#VALUE!

Documented / expected
#N/A

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

Same documented Important box: "totmem" is one of the three type_text values that "are no longer supported and now return a #N/A error value". WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
INFO Google Sheets

=INFO("totmem")

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Same documented Important box: "totmem" is one of the three type_text values that "are no longer supported and now return a #N/A error value". WHY THIS FUNCTION IS ASSERTED STRUCTURALLY. INFO returns facts about the machine the workbook is open on, so no fixed value can be asserted for most type_text codes without pinning the assertion to this VM instead of to the function. What the documentation DOES fix is the TYPE and the ENUMERATION of each answer, and that is what is asserted here: a wrapper such as ISTEXT() or OR() turns the documented promise into something a run can check on any machine. Codes whose documented answer this environment cannot produce at all are carried as probes with expected: null rather than as invented figures.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
INTRATE LibreOffice Calc

=ROUND(INTRATE(A2,A3,A4,A5),10)

Actual result
0.0583280899

Documented / expected
0.05768

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The basis table's first row reads "0 or omitted | US (NASD) 30/360", so omitting the argument must give exactly the same answer as passing 0 -- and, as derived in the basis-0 case above, that answer is 0.05768, the same figure Microsoft publishes for basis 2. This is the form most real formulas take, since basis is the argument users leave off.; MISMATCH vs expected: expected 0.05768, got 0.0583280899
INTRATE LibreOffice Calc

=INTRATE(A2,A3,A4,A5,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, INTRATE returns the #NUM! error value." The basis table stops at 4 (European 30/360), so 5 is the first invalid value.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
INTRATE LibreOffice Calc

=ROUND(INTRATE(A2,A3,A4,A5,0),10)

Actual result
0.0583280899

Documented / expected
0.05768

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The basis table documents 0 as "US (NASD) 30/360", and this is the basis a user gets by omitting the argument. Derived exactly: under 30/360 the days from 2008-02-15 to 2008-05-15 are (5-2) x 30 + (15-15) = 90 -- the same 90 as the actual count, because the two dates share a day-of-month and neither is the 31st -- and B = 360. So the rate is again 0.01442 x 360/90 = 0.05768, identical to Microsoft's published basis-2 figure. The case exists precisely because the answer is forced to agree with the published one: an engine that gets basis 2 right and basis 0 wrong has a day-count bug and nothing else can explain it. LibreOffice's own DAYS360 agrees, returning 90 for these two dates on all four builds, and its YEARFRAC(...,0) returns 0.25.; MISMATCH vs expected: expected 0.05768, got 0.0583280899
INTRATE LibreOffice Calc

=INTRATE(A3,A3,A4,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, INTRATE returns the #NUM! error value." Equality is the boundary the >= sign includes, and it is also the case that would make DIM zero in the documented formula.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
INTRATE LibreOffice Calc

=INTRATE(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If investment <= 0 or if redemption <= 0, INTRATE returns the #NUM! error value." Zero investment is also the denominator of the documented formula, so the exclusion is not arbitrary.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ISBETWEEN Excel for the web

=ISBETWEEN(7.9, 1.2, 12.45, FALSE, FALSE)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The row that shows the flags govern the endpoints only. THE PAGE SAYS NOTHING ABOUT TEXT OR DATES: all six published rows use plain numbers and no sentence on the page mentions comparing text or date values, so this corpus asserts nothing about them. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(7.9, 1.2, 12.45, FALSE, FALSE)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The row that shows the flags govern the endpoints only. THE PAGE SAYS NOTHING ABOUT TEXT OR DATES: all six published rows use plain numbers and no sentence on the page mentions comparing text or date values, so this corpus asserts nothing about them. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN Excel for the web

=ISBETWEEN(1.2, 1.2, 12.45, FALSE)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Rows 2 and 3 differ only in that flag, which is what makes the pair worth executing. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected False, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(1.2, 1.2, 12.45, FALSE)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Rows 2 and 3 differ only in that flag, which is what makes the pair worth executing. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected False, got '#NAME?'
ISBETWEEN Excel for the web

=ISBETWEEN(1.2, 1.2, 12.45, TRUE)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The argument description reads: "Whether the range of values includes the `lower_value`. By default this is TRUE". Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(1.2, 1.2, 12.45, TRUE)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The argument description reads: "Whether the range of values includes the `lower_value`. By default this is TRUE". Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN Excel for the web

=ISBETWEEN(7.9, 1.2, 12.45)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. ISBETWEEN is one of the few pages in this batch that publishes a complete Formula/Output table in the article body, so every case in this file is Google's own printed result rather than a derivation. The six rows below are the whole table. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(7.9, 1.2, 12.45)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. ISBETWEEN is one of the few pages in this batch that publishes a complete Formula/Output table in the article body, so every case in this file is Google's own printed result rather than a derivation. The six rows below are the whole table. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN Excel for the web

=ISBETWEEN(12.45, 1.2, 12.45, TRUE, FALSE)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected False, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(12.45, 1.2, 12.45, TRUE, FALSE)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected False, got '#NAME?'
ISBETWEEN Excel for the web

=ISBETWEEN(12.45, 1.2, 12.45, TRUE, TRUE)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISBETWEEN LibreOffice Calc

=ISBETWEEN(12.45, 1.2, 12.45, TRUE, TRUE)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISBETWEEN page, read live on 2026-08-31 at https://support.google.com/docs/answer/10538337.; MISMATCH vs expected: expected True, got '#NAME?'
ISDATE Excel for the web

=ISDATE("July 20 1969")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The page's Examples table has four rows and this file asserts all four. Note that they are NOT the same strings as the page's separate 'Sample formulas' line (ISDATE("7/20/1969"), ISDATE("July 20"), ISDATE(A1)), which prints no results at all -- the two sets must not be conflated. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISDATE LibreOffice Calc

=ISDATE("July 20 1969")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The page's Examples table has four rows and this file asserts all four. Note that they are NOT the same strings as the page's separate 'Sample formulas' line (ISDATE("7/20/1969"), ISDATE("July 20"), ISDATE(A1)), which prints no results at all -- the two sets must not be conflated. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISDATE Excel for the web

=ISDATE("Feb 30")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The pair with row 3 shows the page treating an INCOMPLETE date and an IMPOSSIBLE date the same way. The page's only Note is unrelated to either: "Ensure your date has quotation marks around it, unless it's a reference to a cell." Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected False, got '#NAME?'
ISDATE LibreOffice Calc

=ISDATE("Feb 30")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. The pair with row 3 shows the page treating an INCOMPLETE date and an IMPOSSIBLE date the same way. The page's only Note is unrelated to either: "Ensure your date has quotation marks around it, unless it's a reference to a cell." Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected False, got '#NAME?'
ISDATE Excel for the web

=ISDATE("1969-20-07")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. THIS IS THE ROW WORTH WATCHING, AND IT IS GOOGLE'S OWN. Read as ISO year-month-day, "1969-20-07" has month 20 and cannot be a date; the page nonetheless prints TRUE, which is only consistent with a year-day-month reading. The page says nothing about locale anywhere, and the corpus asserts the published value rather than the value the reading suggests. If the executed engine returns FALSE, that divergence is the finding and the page is what will be wrong. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected True, got '#NAME?'
ISDATE Google Sheets

=ISDATE("1969-20-07")

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. THIS IS THE ROW WORTH WATCHING, AND IT IS GOOGLE'S OWN. Read as ISO year-month-day, "1969-20-07" has month 20 and cannot be a date; the page nonetheless prints TRUE, which is only consistent with a year-day-month reading. The page says nothing about locale anywhere, and the corpus asserts the published value rather than the value the reading suggests. If the executed engine returns FALSE, that divergence is the finding and the page is what will be wrong. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected True, got False
ISDATE LibreOffice Calc

=ISDATE("1969-20-07")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. THIS IS THE ROW WORTH WATCHING, AND IT IS GOOGLE'S OWN. Read as ISO year-month-day, "1969-20-07" has month 20 and cannot be a date; the page nonetheless prints TRUE, which is only consistent with a year-day-month reading. The page says nothing about locale anywhere, and the corpus asserts the published value rather than the value the reading suggests. If the executed engine returns FALSE, that divergence is the finding and the page is what will be wrong. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected True, got '#NAME?'
ISDATE Excel for the web

=ISDATE("July")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected False, got '#NAME?'
ISDATE LibreOffice Calc

=ISDATE("July")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Info

This IS one of Google's own published results: the page carries a real Formula/Result table in the article body (not an embedded live sheet), and this row is quoted from it verbatim. Google's ISDATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/9061381.; MISMATCH vs expected: expected False, got '#NAME?'
ISEMAIL Excel for the web

=ISEMAIL("johndoe@yourname.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL LibreOffice Calc

=ISEMAIL("johndoe@yourname.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL Excel for the web

=ISEMAIL("noreply@google.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL LibreOffice Calc

=ISEMAIL("noreply@google.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL Excel for the web

=ISEMAIL("janesmith@yourname.xyz")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503. The .xyz sample is the page's own and is the only hint it gives that the check is not restricted to familiar top-level domains -- it never says so in words.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL LibreOffice Calc

=ISEMAIL("janesmith@yourname.xyz")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Info

NOTHING ON THIS PAGE IS A PUBLISHED RESULT. ISEMAIL's page prints three Sample Usage formulas and no results, and it defines validity only as: "This checks if the value follows a commonly accepted format for email addresses but doesn't verify its existence." There is no regex, no character rule and no statement about top-level domains. The three TRUE cases below are the page's OWN sample inputs, on the reading that Google would not print an address as a sample of an email-validity function if it were not one; that reading is stated here rather than dressed up as a Google claim. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503. The .xyz sample is the page's own and is the only hint it gives that the check is not restricted to familiar top-level domains -- it never says so in words.; MISMATCH vs expected: expected True, got '#NAME?'
ISEMAIL Excel for the web

=ISEMAIL("not an email")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Info

DERIVED, and deliberately far from the boundary. The page defines validity only as a "commonly accepted format", so this corpus asserts FALSE only for an input no format could accept, and asserts nothing about the interesting near-misses (missing top-level domain, trailing dot, quoted local part) that the page never discusses. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503.; MISMATCH vs expected: expected False, got '#NAME?'
ISEMAIL LibreOffice Calc

=ISEMAIL("not an email")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Info

DERIVED, and deliberately far from the boundary. The page defines validity only as a "commonly accepted format", so this corpus asserts FALSE only for an input no format could accept, and asserts nothing about the interesting near-misses (missing top-level domain, trailing dot, quoted local part) that the page never discusses. Google's ISEMAIL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256503.; MISMATCH vs expected: expected False, got '#NAME?'
ISLEAPYEAR Excel for the web

=ISLEAPYEAR(DATE(2100,1,1))

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the Gregorian rule: 2100 is divisible by 100 but not by 400, so it is not a leap year. Together with the case above this pins the century rules in both directions -- the only place a naive 'divisible by 4' implementation goes wrong. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
ISLEAPYEAR Google Sheets

=ISLEAPYEAR(DATE(2100,1,1))

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the Gregorian rule: 2100 is divisible by 100 but not by 400, so it is not a leap year. Together with the case above this pins the century rules in both directions -- the only place a naive 'divisible by 4' implementation goes wrong. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
ISLEAPYEAR Excel for the web

=ISLEAPYEAR(DATE(2000,1,1))

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the Gregorian rule the function implements: 2000 is divisible by 400 and so IS a leap year. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
ISLEAPYEAR Google Sheets

=ISLEAPYEAR(DATE(2000,1,1))

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the Gregorian rule the function implements: 2000 is divisible by 400 and so IS a leap year. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
ISLEAPYEAR Excel for the web

=ISLEAPYEAR(DATE(2026,6,1))

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the published return-value sentence above. 2026 is not divisible by 4. The page publishes only the true case, so this is the case that checks the function returns the documented 0 rather than FALSE, an error, or nothing. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
ISLEAPYEAR Google Sheets

=ISLEAPYEAR(DATE(2026,6,1))

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the published return-value sentence above. 2026 is not divisible by 4. The page publishes only the true case, so this is the case that checks the function returns the documented 0 rather than FALSE, an error, or nothing. LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
ISLEAPYEAR Excel for the web

=ISLEAPYEAR(DATE(1968,2,29))

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, and the page publishes the exact formula used here: after "=ISLEAPYEAR(A1) returns 1, if A1 contains 1968-02-29" it goes on to say "You may also use =ISLEAPYEAR(DATE(1968;2;29))", which is this case with the corpus's comma argument separator. The page is unusually explicit about why the form matters: "Never use =ISLEAPYEAR(2/29/68), because this would first evaluate 2 divided by 29 divided by 68, and then calculate the ISLEAPYEAR function from this small number as a serial date number." The return type is published too: "Determines whether a year is a leap year. If yes, the function will return the value 1 (TRUE); if not, it will return 0 (FALSE)." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
ISLEAPYEAR Google Sheets

=ISLEAPYEAR(DATE(1968,2,29))

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, and the page publishes the exact formula used here: after "=ISLEAPYEAR(A1) returns 1, if A1 contains 1968-02-29" it goes on to say "You may also use =ISLEAPYEAR(DATE(1968;2;29))", which is this case with the corpus's comma argument separator. The page is unusually explicit about why the form matters: "Never use =ISLEAPYEAR(2/29/68), because this would first evaluate 2 divided by 29 divided by 68, and then calculate the ISLEAPYEAR function from this small number as a serial date number." The return type is published too: "Determines whether a year is a leap year. If yes, the function will return the value 1 (TRUE); if not, it will return 0 (FALSE)." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ISLEAPYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
ISNUMBER LibreOffice Calc

=ISNUMBER(TRUE)

Actual result
True

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Information

ISNUMBER(TRUE) = FALSE; use ISLOGICAL to detect booleans instead.; MISMATCH vs expected: expected False, got True
ISOMITTED Google Sheets

=LAMBDA(x,y,IF(ISOMITTED(y),"Missing second argument",x+y))(1,2)

Actual result
#NAME?

Documented / expected
3

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

The control for Microsoft's own example: with y = 2 present, ISOMITTED(y) must be FALSE and the IF must fall through to x+y = 1+2 = 3. Without this case a function that returned TRUE unconditionally would pass the documented example. ISOMITTED EXISTS ONLY INSIDE A LAMBDA. Its whole documented purpose is "Checks whether the value in a LAMBDA is missing and returns TRUE or FALSE", and its argument is documented as "The value you want to test, such as a LAMBDA parameter". So it cannot be exercised on its own: both asserted cases here are the LAMBDA call Microsoft itself publishes. It is an Excel for Microsoft 365 / Excel 2024 function only -- the page's Applies To line lists no perpetual release before 2024 -- and it is stored as _xlfn.ISOMITTED, which [MS-XLSX] section 2.2.3 lists prefixed. EXECUTED RESULT: LibreOffice has no LAMBDA at all, so these formulas cannot work there and do not: a five-spelling probe on all four builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) returns #NAME? for =ISOMITTED(A1) under the plain name, the _xlfn. form, the COM.MICROSOFT. form, the ORG.OPENOFFICE. form and the _xlfn.ORG.OPENOFFICE. form alike, and =LAMBDA(x,x+1)(2) is itself an error on every build. This is a genuine missing function, not the storage-form gap this batch records for IMSEC/IMSECH/IMSINH/IMTAN -- there is no spelling under which LibreOffice computes it.; MISMATCH vs expected: expected 3, got '#NAME?'
ISOMITTED LibreOffice Calc

=LAMBDA(x,y,IF(ISOMITTED(y),"Missing second argument",x+y))(1,2)

Actual result
#VALUE!

Documented / expected
3

Engine
LibreOffice Calc 25.8.7.3

Category
Information

The control for Microsoft's own example: with y = 2 present, ISOMITTED(y) must be FALSE and the IF must fall through to x+y = 1+2 = 3. Without this case a function that returned TRUE unconditionally would pass the documented example. ISOMITTED EXISTS ONLY INSIDE A LAMBDA. Its whole documented purpose is "Checks whether the value in a LAMBDA is missing and returns TRUE or FALSE", and its argument is documented as "The value you want to test, such as a LAMBDA parameter". So it cannot be exercised on its own: both asserted cases here are the LAMBDA call Microsoft itself publishes. It is an Excel for Microsoft 365 / Excel 2024 function only -- the page's Applies To line lists no perpetual release before 2024 -- and it is stored as _xlfn.ISOMITTED, which [MS-XLSX] section 2.2.3 lists prefixed. EXECUTED RESULT: LibreOffice has no LAMBDA at all, so these formulas cannot work there and do not: a five-spelling probe on all four builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) returns #NAME? for =ISOMITTED(A1) under the plain name, the _xlfn. form, the COM.MICROSOFT. form, the ORG.OPENOFFICE. form and the _xlfn.ORG.OPENOFFICE. form alike, and =LAMBDA(x,x+1)(2) is itself an error on every build. This is a genuine missing function, not the storage-form gap this batch records for IMSEC/IMSECH/IMSINH/IMTAN -- there is no spelling under which LibreOffice computes it.; MISMATCH vs expected: expected 3, got '#VALUE!'
ISOMITTED Google Sheets

=LAMBDA(x,y,IF(ISOMITTED(y),"Missing second argument",x+y))(1,)

Actual result
#NAME?

Documented / expected
Missing second argument

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Information

Microsoft's page publishes exactly this formula -- "Example 1: Check for a missing parameter and return a friendly string ... =LAMBDA(x,y, IF(ISOMITTED(y),\"Missing second argument\",x+y))(1,)" -- and the trailing comma with nothing after it is the point: y is supplied as omitted. ISOMITTED(y) is therefore TRUE and the IF returns the friendly string. The result string is fixed by the formula itself, so nothing here is derived or guessed. ISOMITTED EXISTS ONLY INSIDE A LAMBDA. Its whole documented purpose is "Checks whether the value in a LAMBDA is missing and returns TRUE or FALSE", and its argument is documented as "The value you want to test, such as a LAMBDA parameter". So it cannot be exercised on its own: both asserted cases here are the LAMBDA call Microsoft itself publishes. It is an Excel for Microsoft 365 / Excel 2024 function only -- the page's Applies To line lists no perpetual release before 2024 -- and it is stored as _xlfn.ISOMITTED, which [MS-XLSX] section 2.2.3 lists prefixed. EXECUTED RESULT: LibreOffice has no LAMBDA at all, so these formulas cannot work there and do not: a five-spelling probe on all four builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) returns #NAME? for =ISOMITTED(A1) under the plain name, the _xlfn. form, the COM.MICROSOFT. form, the ORG.OPENOFFICE. form and the _xlfn.ORG.OPENOFFICE. form alike, and =LAMBDA(x,x+1)(2) is itself an error on every build. This is a genuine missing function, not the storage-form gap this batch records for IMSEC/IMSECH/IMSINH/IMTAN -- there is no spelling under which LibreOffice computes it.; MISMATCH vs expected: expected 'Missing second argument', got '#NAME?'
ISOMITTED LibreOffice Calc

=LAMBDA(x,y,IF(ISOMITTED(y),"Missing second argument",x+y))(1,)

Actual result
#VALUE!

Documented / expected
Missing second argument

Engine
LibreOffice Calc 25.8.7.3

Category
Information

Microsoft's page publishes exactly this formula -- "Example 1: Check for a missing parameter and return a friendly string ... =LAMBDA(x,y, IF(ISOMITTED(y),\"Missing second argument\",x+y))(1,)" -- and the trailing comma with nothing after it is the point: y is supplied as omitted. ISOMITTED(y) is therefore TRUE and the IF returns the friendly string. The result string is fixed by the formula itself, so nothing here is derived or guessed. ISOMITTED EXISTS ONLY INSIDE A LAMBDA. Its whole documented purpose is "Checks whether the value in a LAMBDA is missing and returns TRUE or FALSE", and its argument is documented as "The value you want to test, such as a LAMBDA parameter". So it cannot be exercised on its own: both asserted cases here are the LAMBDA call Microsoft itself publishes. It is an Excel for Microsoft 365 / Excel 2024 function only -- the page's Applies To line lists no perpetual release before 2024 -- and it is stored as _xlfn.ISOMITTED, which [MS-XLSX] section 2.2.3 lists prefixed. EXECUTED RESULT: LibreOffice has no LAMBDA at all, so these formulas cannot work there and do not: a five-spelling probe on all four builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) returns #NAME? for =ISOMITTED(A1) under the plain name, the _xlfn. form, the COM.MICROSOFT. form, the ORG.OPENOFFICE. form and the _xlfn.ORG.OPENOFFICE. form alike, and =LAMBDA(x,x+1)(2) is itself an error on every build. This is a genuine missing function, not the storage-form gap this batch records for IMSEC/IMSECH/IMSINH/IMTAN -- there is no spelling under which LibreOffice computes it.; MISMATCH vs expected: expected 'Missing second argument', got '#VALUE!'
ISPMT LibreOffice Calc

=ISPMT(0.1,1,0,8000000)

Actual result
#NUM!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

DERIVED, not quoted: Microsoft's ISPMT page documents no error conditions at all. The formula confirmed by both vendors' worked examples divides per by nper, so nper = 0 is a division by zero and #DIV/0! is the consistent result; MISMATCH vs expected: expected '#DIV/0!', got '#NUM!'
ISURL Excel for the web

=ISURL("mailto:someone@example.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

DERIVED from the Notes bullet "Valid protocols include ftp, http, https, gopher, mailto, news, telnet, and aim." mailto is on that list and is the least URL-looking member of it, which is what makes it worth executing. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("mailto:someone@example.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Web

DERIVED from the Notes bullet "Valid protocols include ftp, http, https, gopher, mailto, news, telnet, and aim." mailto is on that list and is the least URL-looking member of it, which is what makes it worth executing. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL Excel for the web

=ISURL("google.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

The same Notes bullet at its limit -- this is the sample that makes the bullet mean something, since it has neither of the two things the bullet says are not needed. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("google.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Web

The same Notes bullet at its limit -- this is the sample that makes the bullet mean something, since it has neither of the two things the bullet says are not needed. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL Excel for the web

=ISURL("http://www.google.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

ISURL's page prints four Sample Usage formulas and NO results, but unlike ISEMAIL it does carry a real Notes section, and the Notes are the authority for this file: "A fully qualified URL is not required. In other words, 'http' and 'www' are not needed in all cases."; "Valid protocols include ftp, http, https, gopher, mailto, news, telnet, and aim."; "If a URL is flagged as 'False', it may use a top-level domain that isn't on our list." That last bullet means the page itself declines to define the boundary, so this corpus asserts only inputs the Notes settle. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("http://www.google.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Web

ISURL's page prints four Sample Usage formulas and NO results, but unlike ISEMAIL it does carry a real Notes section, and the Notes are the authority for this file: "A fully qualified URL is not required. In other words, 'http' and 'www' are not needed in all cases."; "Valid protocols include ftp, http, https, gopher, mailto, news, telnet, and aim."; "If a URL is flagged as 'False', it may use a top-level domain that isn't on our list." That last bullet means the page itself declines to define the boundary, so this corpus asserts only inputs the Notes settle. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL Excel for the web

=ISURL("www.google.com")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

DERIVED from the Notes bullet "A fully qualified URL is not required. In other words, 'http' and 'www' are not needed in all cases", applied to the page's own second sample input. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("www.google.com")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Web

DERIVED from the Notes bullet "A fully qualified URL is not required. In other words, 'http' and 'www' are not needed in all cases", applied to the page's own second sample input. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL Excel for the web

=ISURL("www.abc.xyz")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

The page's fourth sample input. It pairs with the Notes bullet about an unlisted top-level domain: Google never publishes the list, so .xyz is asserted TRUE only because the page prints it as a sample of the function. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("www.abc.xyz")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Web

The page's fourth sample input. It pairs with the Notes bullet about an unlisted top-level domain: Google never publishes the list, so .xyz is asserted TRUE only because the page prints it as a sample of the function. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected True, got '#NAME?'
ISURL Excel for the web

=ISURL("not a url")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Web

DERIVED, and deliberately far from the boundary: the Notes make clear the page will not say where the boundary is, so the only FALSE this corpus asserts is one no protocol or top-level-domain list could rescue. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected False, got '#NAME?'
ISURL LibreOffice Calc

=ISURL("not a url")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Web

DERIVED, and deliberately far from the boundary: the Notes make clear the page will not say where the boundary is, so the only FALSE this corpus asserts is one no protocol or top-level-domain list could rescue. Google's ISURL page, read live on 2026-08-31 at https://support.google.com/docs/answer/3256501.; MISMATCH vs expected: expected False, got '#NAME?'
JIS Excel for the web

=JIS("ＥＸＣＥＬ")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The Text argument description ends: "If text does not contain any half-width English letters or katakana, text is not changed." Full-width input contains no half-width letters, so the documented answer is the argument itself -- which also makes JIS idempotent, since this string is the output of the previous case. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
JIS Google Sheets

=JIS("ＥＸＣＥＬ")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

The Text argument description ends: "If text does not contain any half-width English letters or katakana, text is not changed." Full-width input contains no half-width letters, so the documented answer is the argument itself -- which also makes JIS idempotent, since this string is the output of the previous case. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
JIS Excel for the web

=JIS("ｶﾅ")

Actual result
#NAME?

Documented / expected
カナ

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page names two classes of convertible characters: "half-width (single-byte) English letters or katakana". This case covers the second. U+FF76 HALFWIDTH KATAKANA LETTER KA and U+FF85 HALFWIDTH KATAKANA LETTER NA map to U+30AB KATAKANA LETTER KA and U+30CA KATAKANA LETTER NA. Latin-only tests would never exercise this branch, and it is the branch the function is actually named after. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'カナ', got '#NAME?'
JIS Google Sheets

=JIS("ｶﾅ")

Actual result
#NAME?

Documented / expected
カナ

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

The page names two classes of convertible characters: "half-width (single-byte) English letters or katakana". This case covers the second. U+FF76 HALFWIDTH KATAKANA LETTER KA and U+FF85 HALFWIDTH KATAKANA LETTER NA map to U+30AB KATAKANA LETTER KA and U+30CA KATAKANA LETTER NA. Latin-only tests would never exercise this branch, and it is the branch the function is actually named after. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'カナ', got '#NAME?'
JIS Excel for the web

=JIS("EXCEL")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

Derived from the documented rule rather than from the broken example: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E, X, C, E, L). That is exactly the mapping batch A's ASC cases assert in the opposite direction, and exactly the value batch C asserted for DBCS("EXCEL") on the other Windows-named half of this pair. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
JIS Google Sheets

=JIS("EXCEL")

Actual result
#NAME?

Documented / expected
ＥＸＣＥＬ

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Derived from the documented rule rather than from the broken example: E X C E L map to U+FF25 U+FF38 U+FF23 U+FF25 U+FF2C (FULLWIDTH LATIN CAPITAL E, X, C, E, L). That is exactly the mapping batch A's ASC cases assert in the opposite direction, and exactly the value batch C asserted for DBCS("EXCEL") on the other Windows-named half of this pair. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'ＥＸＣＥＬ', got '#NAME?'
JIS Excel for the web

=LEN(JIS("EXCEL"))

Actual result
#NAME?

Documented / expected
5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

"Half-width" and "full-width" describe how many BYTES a character occupied in a legacy double-byte encoding, not how many characters there are: the conversion replaces each character with one other character. So LEN is invariant under JIS even though LENB is not -- on all four builds LENB of the full-width result is 10 against LENB 5 for the argument. Asserting LEN here separates "converted the characters" from "inserted padding". Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 5, got '#NAME?'
JIS Google Sheets

=LEN(JIS("EXCEL"))

Actual result
#NAME?

Documented / expected
5

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

"Half-width" and "full-width" describe how many BYTES a character occupied in a legacy double-byte encoding, not how many characters there are: the conversion replaces each character with one other character. So LEN is invariant under JIS even though LENB is not -- on all four builds LENB of the full-width result is 10 against LENB 5 for the argument. Asserting LEN here separates "converted the characters" from "inserted padding". Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 5, got '#NAME?'
JIS Excel for the web

=ASC(JIS("EXCEL"))

Actual result
#NAME?

Documented / expected
EXCEL

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

ASC is documented as the inverse operation ("changes full-width (double-byte) English letters or katakana within a character string to half-width (single-byte) characters"), and batch A already executed ASC's own cases. Composing the two must return the original string. This is the strongest single check in the file: it depends on nothing but the two documented rules being inverses, and it would fail if JIS converted the wrong character class, converted only some characters, or changed the length. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
JIS Google Sheets

=ASC(JIS("EXCEL"))

Actual result
#NAME?

Documented / expected
EXCEL

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

ASC is documented as the inverse operation ("changes full-width (double-byte) English letters or katakana within a character string to half-width (single-byte) characters"), and batch A already executed ASC's own cases. Composing the two must return the original string. This is the strongest single check in the file: it depends on nothing but the two documented rules being inverses, and it would fail if JIS converted the wrong character class, converted only some characters, or changed the length. Microsoft's JIS page states the rule twice: "converts half-width (single-byte) letters within a character string to full-width (double-byte) characters", and "For Japanese, this function changes half-width (single-byte) English letters or katakana within a character string to full-width (double-byte) characters". It also warns that "The name of the function (and the characters that it converts) depends upon your language settings"; this harness runs under LC_ALL=en_US.UTF-8, a non-DBCS default language, which is stated here rather than assumed away. THE PAGE'S PUBLISHED EXAMPLES ARE UNUSABLE AS WRITTEN, so no figure is copied from them. The first reads, in the raw page source, '=JIS("EXCEL") equals "EXCEL"' -- both sides identical ASCII, i.e. the argument coming back unchanged, which directly contradicts the page's own rule since "EXCEL" is five half-width English letters. (The full-width result appears to have been flattened to ASCII somewhere in publishing; the identical defect sits on the DBCS page, which batch C recorded, and the ASC page carries the same line as its CORRECT behaviour.) The second example is rendered entirely as inline GIF images (media/fe337.gif and siblings), so no literal argument or result can be read out of it at all. Every value in this file is therefore derived from the stated rule and from the Unicode halfwidth/fullwidth block, not copied from the page.; MISMATCH vs expected: expected 'EXCEL', got '#NAME?'
JOIN Excel for the web

=JOIN(,{1,2,3})

Actual result
#NAME?

Documented / expected
123

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The `delimiter` argument description carries this example verbatim: "delimiter may be specified as blank, e.g. JOIN(,{1,2,3})". DERIVED: with nothing between them the three elements concatenate. The Note adds "When delimiter is omitted, the result of JOIN is similar to that of CONCATENATE" -- "similar" is the page's word and is too weak to assert an identity from, so this case asserts the concatenation itself rather than an equivalence. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '123', got '#NAME?'
JOIN LibreOffice Calc

=JOIN(,{1,2,3})

Actual result
#NAME?

Documented / expected
123

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The `delimiter` argument description carries this example verbatim: "delimiter may be specified as blank, e.g. JOIN(,{1,2,3})". DERIVED: with nothing between them the three elements concatenate. The Note adds "When delimiter is omitted, the result of JOIN is similar to that of CONCATENATE" -- "similar" is the page's word and is too weak to assert an identity from, so this case asserts the concatenation itself rather than an equivalence. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '123', got '#NAME?'
JOIN Excel for the web

=JOIN(" and-a ",{1,2,"1 2 3 4"})

Actual result
#NAME?

Documented / expected
1 and-a 2 and-a 1 2 3 4

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page's own sample formula. DERIVED: three elements joined by " and-a " give two separators, and the third element already contains spaces, which is what makes it a useful sample -- the delimiter is inserted BETWEEN elements and never inside one. JOIN's page publishes NO results -- three Sample Usage formulas and one Note. Every value below is DERIVED from the definition "Concatenates the elements of one or more one-dimensional arrays using a specified delimiter" and from the argument order the syntax line fixes, JOIN(delimiter, value_or_array1, [value_or_array2, ...]), with the delimiter FIRST. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '1 and-a 2 and-a 1 2 3 4', got '#NAME?'
JOIN LibreOffice Calc

=JOIN(" and-a ",{1,2,"1 2 3 4"})

Actual result
#NAME?

Documented / expected
1 and-a 2 and-a 1 2 3 4

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page's own sample formula. DERIVED: three elements joined by " and-a " give two separators, and the third element already contains spaces, which is what makes it a useful sample -- the delimiter is inserted BETWEEN elements and never inside one. JOIN's page publishes NO results -- three Sample Usage formulas and one Note. Every value below is DERIVED from the definition "Concatenates the elements of one or more one-dimensional arrays using a specified delimiter" and from the argument order the syntax line fixes, JOIN(delimiter, value_or_array1, [value_or_array2, ...]), with the delimiter FIRST. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected '1 and-a 2 and-a 1 2 3 4', got '#NAME?'
JOIN Excel for the web

=JOIN(",",{1,2,3},{4;5;6})

Actual result
#NAME?

Documented / expected
1,2,3,4,5,6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page's own sample formula, which is also the only evidence it offers that JOIN takes more than one array: the syntax line's [value_or_array2, ...] and this line. DERIVED. The second literal uses semicolons, making it a COLUMN; the page says nothing about orientation, and this case records that both orientations flatten into one delimited string in argument order. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '1,2,3,4,5,6', got '#NAME?'
JOIN LibreOffice Calc

=JOIN(",",{1,2,3},{4;5;6})

Actual result
#NAME?

Documented / expected
1,2,3,4,5,6

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page's own sample formula, which is also the only evidence it offers that JOIN takes more than one array: the syntax line's [value_or_array2, ...] and this line. DERIVED. The second literal uses semicolons, making it a COLUMN; the page says nothing about orientation, and this case records that both orientations flatten into one delimited string in argument order. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '1,2,3,4,5,6', got '#NAME?'
JOIN Excel for the web

=JOIN("-",A1:A5)

Actual result
#NAME?

Documented / expected
10-20-30-40-50

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page's third sample, JOIN("-",A1:A100), scaled to five populated cells -- Google names A1:A100 without populating any of it. DERIVED. THE PAGE SAYS NOTHING ABOUT EMPTY CELLS INSIDE THE RANGE, so this case uses a fully populated one and the corpus asserts nothing about blanks. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '10-20-30-40-50', got '#NAME?'
JOIN LibreOffice Calc

=JOIN("-",A1:A5)

Actual result
#NAME?

Documented / expected
10-20-30-40-50

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page's third sample, JOIN("-",A1:A100), scaled to five populated cells -- Google names A1:A100 without populating any of it. DERIVED. THE PAGE SAYS NOTHING ABOUT EMPTY CELLS INSIDE THE RANGE, so this case uses a fully populated one and the corpus asserts nothing about blanks. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '10-20-30-40-50', got '#NAME?'
JOIN Excel for the web

=JOIN("|",A1:A2,B1:B2)

Actual result
#NAME?

Documented / expected
1|2|3|4

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED from the syntax line's argument order. The first range is exhausted before the second begins, exactly as with two array literals. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '1|2|3|4', got '#NAME?'
JOIN LibreOffice Calc

=JOIN("|",A1:A2,B1:B2)

Actual result
#NAME?

Documented / expected
1|2|3|4

Engine
LibreOffice Calc 25.8.7.3

Category
Text

DERIVED from the syntax line's argument order. The first range is exhausted before the second begins, exactly as with two array literals. Google's JOIN page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094077.; MISMATCH vs expected: expected '1|2|3|4', got '#NAME?'
LAMBDA LibreOffice Calc

=LAMBDA(x,x*2)(5)

Actual result
#VALUE!

Documented / expected
10

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: expected 10, got '#VALUE!'
LAMBDA LibreOffice Calc

=LAMBDA(x,y,x+y)(3,4)

Actual result
#VALUE!

Documented / expected
7

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: expected 7, got '#VALUE!'
LAMBDA LibreOffice Calc

=LET(f,LAMBDA(x,x^2),f(4))

Actual result
#VALUE!

Documented / expected
16

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: expected 16, got '#VALUE!'
LAMBDA Google Sheets

=LAMBDA(x,y,x+y)(3)

Actual result
#N/A

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Logical

MISMATCH vs expected: expected '#VALUE!', got '#N/A'
LARGE LibreOffice Calc

=LARGE(A1:A5,6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Only 5 values exist; requesting the 6th-largest is out of range; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LARGE LibreOffice Calc

=LARGE(A1:A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LENB Google Sheets

=LENB("日本")

Actual result
4

Documented / expected
2

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Verbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case; MISMATCH vs expected: expected 2, got 4
LENB LibreOffice Calc

=LENB("日本")

Actual result
4

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Verbatim from Microsoft's archived LEN/LENB page: 'LENB counts 2 bytes per character only when a DBCS language is set as the default language. Otherwise LENB behaves the same as LEN, counting 1 byte per character', with DBCS listed as Japanese, Chinese (Simplified/Traditional) and Korean. The harness runs under a non-DBCS default locale, so the documented answer is 2 (LEN semantics). An engine that always counts raw UTF-8 or UTF-16 bytes returns 6 or 4 instead -- recording which one each engine does is the point of this case; MISMATCH vs expected: expected 2, got 4
LET Google Sheets

=LET(x,5,y,x*2)

Actual result
#N/A

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Logical

LET requires pairs plus a trailing calculation; here the last pair has no calc term following it in this deliberately malformed call; MISMATCH vs expected: expected '#VALUE!', got '#N/A'
LN LibreOffice Calc

=LN(-5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LN LibreOffice Calc

=LN(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Microsoft's LN docs specify the Number argument must be 'the positive real number for which you want the natural logarithm' -- https://support.microsoft.com/en-us/office/ln-function-81fe1ed7-dac9-4acd-ba1d-07a142c6118f -- 0 and negative numbers are outside that domain and both are well-established to raise #NUM!, matching every other Excel logarithm function; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOG LibreOffice Calc

=LOG(-10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOG LibreOffice Calc

=LOG(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOG10 LibreOffice Calc

=LOG10(-5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOG10 LibreOffice Calc

=LOG10(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGINV Google Sheets

=ROUND(LOGINV(A2,A3,A4),10)

Actual result
4.00002521

Documented / expected
4.0000252187

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

4.0000252186806350759 at ten places. Asserted at the same precision as LOGNORM.INV so the legacy alias and its replacement can be compared directly.; MISMATCH vs expected: expected 4.0000252187, got 4.00002521
LOGINV LibreOffice Calc

=LOGINV(1,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The same documented sentence at the upper endpoint.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGINV LibreOffice Calc

=LOGINV(0,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If probability <= 0 or probability >= 1, LOGINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGINV Google Sheets

=ROUND(LOGINV(LOGNORMDIST(4,3.5,1.2),3.5,1.2),10)

Actual result
3.999999991

Documented / expected
4.0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

The page's Description states "If p = LOGNORMDIST(x,...) then LOGINV(p,...) = x". Feeding the legacy CDF's full-precision output back into the legacy inverse must return 4 to ten places, using only the two legacy spellings.; MISMATCH vs expected: expected 4.0, got 3.999999991
LOGINV LibreOffice Calc

=LOGINV(0.5,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If standard_dev <= 0, LOGINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORM.DIST LibreOffice Calc

=LOGNORM.DIST(A2,A3,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0 or if standard_dev <= 0, LOGNORM.DIST returns the #NUM! error value." Zero standard deviation is also the denominator of the documented standardisation (ln(x)-mu)/sigma.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORM.DIST LibreOffice Calc

=LOGNORM.DIST(-1,A3,A4,TRUE)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The same documented sentence, asserted a second time strictly inside the excluded range rather than on its boundary. An engine that guards only the exact value 0 -- or that guards nothing and lets the underlying maths return something -- is distinguished from a conforming one here.; MISMATCH vs expected: expected '#NUM!', got 0
LOGNORM.DIST LibreOffice Calc

=LOGNORM.DIST(0,A3,A4,TRUE)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If x <= 0 or if standard_dev <= 0, LOGNORM.DIST returns the #NUM! error value." The exclusion is not cosmetic -- ln(x) is undefined at and below zero, so there is no value to return. Zero is the boundary the <= sign includes.; MISMATCH vs expected: expected '#NUM!', got 0
LOGNORM.INV Google Sheets

=ROUND(LOGNORM.INV(A2,A3,A4),10)

Actual result
4.00002521

Documented / expected
4.0000252187

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

4.0000252186806350759 at ten places, from the root-finding derivation described on the previous case. Microsoft's seven-place figure cannot distinguish an accurate inverse from a crude one; this can.; MISMATCH vs expected: expected 4.0000252187, got 4.00002521
LOGNORM.INV LibreOffice Calc

=LOGNORM.INV(1,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The same documented sentence, asserted at the upper endpoint. Batch D found FORECAST.ETS.CONFINT guarding one end of a documented open interval and not the other, so both ends are always asserted separately in this corpus.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORM.INV LibreOffice Calc

=LOGNORM.INV(0,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If probability <= 0 or probability >= 1, LOGNORM.INV returns the #NUM! error value." The interval is open at both ends, which matters: the lognormal has no finite quantile at 0 or 1.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORM.INV Google Sheets

=ROUND(LOGNORM.INV(LOGNORM.DIST(4,3.5,1.2,TRUE),3.5,1.2),10)

Actual result
3.999999991

Documented / expected
4.0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

The page's Description states "If p = LOGNORM.DIST(x,...) then LOGNORM.INV(p,...) = x". Feeding the CDF's own FULL-PRECISION output straight back in -- rather than the six-place 0.039084 the example table uses -- must therefore return 4 exactly, to ten places. This is the strongest assertion in the file because it depends on no derived constant at all: any inaccuracy in either direction shows up as a departure from 4.; MISMATCH vs expected: expected 4.0, got 3.999999991
LOGNORM.INV LibreOffice Calc

=LOGNORM.INV(0.5,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents: "If standard_dev <= 0, LOGNORM.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORMDIST LibreOffice Calc

=LOGNORMDIST(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x <= 0 or if Standard_dev <= 0, LOGNORMDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
LOGNORMDIST LibreOffice Calc

=LOGNORMDIST(-1,A3,A4)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The same documented sentence, asserted away from the boundary so that an engine guarding only the exact value zero is caught.; MISMATCH vs expected: expected '#NUM!', got 0
LOGNORMDIST LibreOffice Calc

=LOGNORMDIST(0,A3,A4)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents: "If x <= 0 or if Standard_dev <= 0, LOGNORMDIST returns the #NUM! error value." Word for word the same exclusion its replacement LOGNORM.DIST documents, so the two spellings are required to behave identically here.; MISMATCH vs expected: expected '#NUM!', got 0
LT Excel for the web

=LT("a","b")=("a"<"b")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596.; MISMATCH vs expected: expected True, got '#NAME?'
LT LibreOffice Calc

=LT("a","b")=("a"<"b")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596.; MISMATCH vs expected: expected True, got '#NAME?'
LT Excel for the web

=LT(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596.; MISMATCH vs expected: expected True, got '#NAME?'
LT LibreOffice Calc

=LT(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596.; MISMATCH vs expected: expected True, got '#NAME?'
LT Excel for the web

=LT(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints LT(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<` operator" clause. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
LT LibreOffice Calc

=LT(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints LT(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<` operator" clause. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
LT Excel for the web

=LT(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `<` equivalence. This is the case that separates LT from its neighbours, and Google publishes no example of it. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596. The definition's word is "strictly less than", which is what makes LT(5,5) FALSE.; MISMATCH vs expected: expected False, got '#NAME?'
LT LibreOffice Calc

=LT(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `<` equivalence. This is the case that separates LT from its neighbours, and Google publishes no example of it. Google's LT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093596. The definition's word is "strictly less than", which is what makes LT(5,5) FALSE.; MISMATCH vs expected: expected False, got '#NAME?'
LTE Excel for the web

=LTE("a","b")=("a"<="b")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976.; MISMATCH vs expected: expected True, got '#NAME?'
LTE LibreOffice Calc

=LTE("a","b")=("a"<="b")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976.; MISMATCH vs expected: expected True, got '#NAME?'
LTE Excel for the web

=LTE(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976.; MISMATCH vs expected: expected True, got '#NAME?'
LTE LibreOffice Calc

=LTE(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976.; MISMATCH vs expected: expected True, got '#NAME?'
LTE Excel for the web

=LTE(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints LTE(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<=` operator" clause. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
LTE LibreOffice Calc

=LTE(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints LTE(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<=` operator" clause. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
LTE Excel for the web

=LTE(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `<=` equivalence. This is the case that separates LTE from its neighbours, and Google publishes no example of it. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976. The definition reads "less than or equal to", which is what makes LTE(5,5) TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
LTE LibreOffice Calc

=LTE(5,5)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `<=` equivalence. This is the case that separates LTE from its neighbours, and Google publishes no example of it. Google's LTE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093976. The definition reads "less than or equal to", which is what makes LTE(5,5) TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
MAKEARRAY LibreOffice Calc

=MAKEARRAY(2,2,LAMBDA(r,c,r*c))

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{1, 2}, {2, 4}}

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
MAP LibreOffice Calc

=MAP(A1:A3,LAMBDA(x,x*2))

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{2, 4, 6}

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: value mismatch: expected 2, got '#NAME?'
MARGINOFERROR Excel for the web

=ROUND(MARGINOFERROR(A1:A4, 0.99),6)

Actual result
#NAME?

Documented / expected
6.475687

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

DERIVED, not published. The page's second Sample Usage line is MARGINOFERROR(A1:C3, 0.99) with no result and no data, so this case applies its confidence level to the data the page DOES publish. t(0.005, 3) = 5.8409093097333573 and the margin is 6.4756870168140886, derived twice as above. It checks that the confidence argument actually reaches the quantile: a hard-coded 95% level would return 3.528308 here. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 6.475687, got '#NAME?'
MARGINOFERROR LibreOffice Calc

=ROUND(MARGINOFERROR(A1:A4, 0.99),6)

Actual result
#NAME?

Documented / expected
6.475687

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

DERIVED, not published. The page's second Sample Usage line is MARGINOFERROR(A1:C3, 0.99) with no result and no data, so this case applies its confidence level to the data the page DOES publish. t(0.005, 3) = 5.8409093097333573 and the margin is 6.4756870168140886, derived twice as above. It checks that the confidence argument actually reaches the quantile: a hard-coded 95% level would return 3.528308 here. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 6.475687, got '#NAME?'
MARGINOFERROR Excel for the web

=ROUND(MARGINOFERROR(A1:A4, 0.95)-CONFIDENCE.T(1-0.95, STDEV(A1:A4), COUNT(A1:A4)),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

A structural assertion with no derived constant, taken verbatim from the page's definition bullet. It is the strongest single check available here: it holds whatever the engine's t quantiles are, and it fails if MARGINOFERROR quietly uses the population standard deviation or the normal quantile. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 0, got '#NAME?'
MARGINOFERROR LibreOffice Calc

=ROUND(MARGINOFERROR(A1:A4, 0.95)-CONFIDENCE.T(1-0.95, STDEV(A1:A4), COUNT(A1:A4)),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

A structural assertion with no derived constant, taken verbatim from the page's definition bullet. It is the strongest single check available here: it holds whatever the engine's t quantiles are, and it fails if MARGINOFERROR quietly uses the population standard deviation or the normal quantile. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 0, got '#NAME?'
MARGINOFERROR Excel for the web

=ROUND(MARGINOFERROR(A1:A4, 0.95),6)

Actual result
#NAME?

Documented / expected
3.528308

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

DERIVED, not published: the page rounds to three decimals and stops. Asserted at six places from the independent derivation, 3.5283078589306981. This is the case that would catch a normal-distribution implementation masquerading as a t one -- the z form gives 2.1727 here, which the page's own three-decimal figure already rules out. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 3.528308, got '#NAME?'
MARGINOFERROR LibreOffice Calc

=ROUND(MARGINOFERROR(A1:A4, 0.95),6)

Actual result
#NAME?

Documented / expected
3.528308

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

DERIVED, not published: the page rounds to three decimals and stops. Asserted at six places from the independent derivation, 3.5283078589306981. This is the case that would catch a normal-distribution implementation masquerading as a t one -- the z form gives 2.1727 here, which the page's own three-decimal figure already rules out. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 3.528308, got '#NAME?'
MARGINOFERROR Excel for the web

=ROUND(MARGINOFERROR(A1:A4, 0.95),3)

Actual result
#NAME?

Documented / expected
3.528

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT, from the Examples table in the article body: over A1:A4 = 8, 4, 3, 6 with mean 5.25, =MARGINOFERROR(A1:A4, 0.95) -> 3.528, with the confidence interval printed as [1.722, 8.778]. DERIVATION. Google's page gives the definition in TEXT, not as an image: "MARGINOFERROR(range, confidence) is equal to CONFIDENCE.T(1 - confidence, STDEV(range), COUNT(range))." STDEV is the SAMPLE standard deviation, and CONFIDENCE.T is the Student-t form, not the normal one -- the page names CONFIDENCE.NORM only as a related link. The figures below were derived TWICE along paths sharing no code: the t density integrated by numerical quadrature to 40 digits with the critical value obtained by root-finding on that CDF, and scipy's inverse t as an independent check. The two agree to 15 significant digits. For the page's data {8, 4, 3, 6}: n = 4, mean 5.25, sample standard deviation 2.2173557826083451, t(0.025, 3) = 3.1824463052837096, margin = 3.5283078589306981. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 3.528, got '#NAME?'
MARGINOFERROR LibreOffice Calc

=ROUND(MARGINOFERROR(A1:A4, 0.95),3)

Actual result
#NAME?

Documented / expected
3.528

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

GOOGLE'S OWN PUBLISHED RESULT, from the Examples table in the article body: over A1:A4 = 8, 4, 3, 6 with mean 5.25, =MARGINOFERROR(A1:A4, 0.95) -> 3.528, with the confidence interval printed as [1.722, 8.778]. DERIVATION. Google's page gives the definition in TEXT, not as an image: "MARGINOFERROR(range, confidence) is equal to CONFIDENCE.T(1 - confidence, STDEV(range), COUNT(range))." STDEV is the SAMPLE standard deviation, and CONFIDENCE.T is the Student-t form, not the normal one -- the page names CONFIDENCE.NORM only as a related link. The figures below were derived TWICE along paths sharing no code: the t density integrated by numerical quadrature to 40 digits with the critical value obtained by root-finding on that CDF, and scipy's inverse t as an independent check. The two agree to 15 significant digits. For the page's data {8, 4, 3, 6}: n = 4, mean 5.25, sample standard deviation 2.2173557826083451, t(0.025, 3) = 3.1824463052837096, margin = 3.5283078589306981. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 3.528, got '#NAME?'
MARGINOFERROR Excel for the web

=ROUND(AVERAGE(A1:A4)-MARGINOFERROR(A1:A4, 0.95),3)

Actual result
#NAME?

Documented / expected
1.722

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

GOOGLE'S OWN PUBLISHED FIGURE: the Examples table prints "Lower Bound (Mean - MARGINOFERROR)" as 1.722 and the upper bound as 8.778, over mean 5.25. 5.25 - 3.5283079 = 1.7216921, which rounds to 1.722. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 1.722, got '#NAME?'
MARGINOFERROR LibreOffice Calc

=ROUND(AVERAGE(A1:A4)-MARGINOFERROR(A1:A4, 0.95),3)

Actual result
#NAME?

Documented / expected
1.722

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

GOOGLE'S OWN PUBLISHED FIGURE: the Examples table prints "Lower Bound (Mean - MARGINOFERROR)" as 1.722 and the upper bound as 8.778, over mean 5.25. 5.25 - 3.5283079 = 1.7216921, which rounds to 1.722. Google's MARGINOFERROR page, read live on 2026-08-31 at https://support.google.com/docs/answer/12487850.; MISMATCH vs expected: expected 1.722, got '#NAME?'
MAXA Excel for the web

=MAXA("abc",-5)

Actual result
#VALUE!

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Verbatim from Microsoft's MAXA page: 'Arguments that contain text or FALSE evaluate as 0 (zero)'. Under that rule the literal "abc" becomes 0, which is larger than -5. (MAX's page carries the opposite rule -- text that cannot be translated into numbers causes an error -- so this case checks that an engine applies the A-variant rule and not MAX's); MISMATCH vs expected: expected 0, got '#VALUE!'
MAXA Google Sheets

=MAXA("abc",-5)

Actual result
#VALUE!

Documented / expected
0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Verbatim from Microsoft's MAXA page: 'Arguments that contain text or FALSE evaluate as 0 (zero)'. Under that rule the literal "abc" becomes 0, which is larger than -5. (MAX's page carries the opposite rule -- text that cannot be translated into numbers causes an error -- so this case checks that an engine applies the A-variant rule and not MAX's); MISMATCH vs expected: expected 0, got '#VALUE!'
MDURATION LibreOffice Calc

=MDURATION(A2,A3,A4,A5,A6,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If basis < 0 or if basis > 4, MDURATION returns the #NUM! error value." The basis table stops at 4 (European 30/360).; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MDURATION LibreOffice Calc

=ROUND(MDURATION(A2,A3,A4,A5,A6,A7),10)

Actual result
5.7339235771

Documented / expected
5.7356698139

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Three published decimals cannot distinguish a correct duration from one that is off in the third significant figure, so the same computation is asserted at ten places: 5.7356698139, from the derivation on the previous case. This is the assertion that actually constrains the coupon-schedule and day-count handling.; MISMATCH vs expected: expected 5.7356698139, got 5.7339235771
MDURATION LibreOffice Calc

=ROUND(MDURATION(A2,A3,A4,A5,A6,A7),3)

Actual result
5.734

Documented / expected
5.736

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft publishes '=MDURATION(A2,A3,A4,A5,A6,A7)' with the result 5.736 for a bond settled 2008-01-01, maturing 2016-01-01, 8% coupon, 9% yield, semiannual, actual/actual basis. DERIVATION, done from the definition rather than from any finance library. Modified duration is Macaulay duration divided by (1 + yld/frequency), and Macaulay duration is the cash-flow-weighted average time to payment, discounted at the yield. Serial 39448 = 2008-01-01 (settlement) and 42370 = 2016-01-01 (maturity), 8 years at frequency 2, so there are exactly 16 semiannual coupon dates, 2008-07-01 through 2016-01-01. THE SETTLEMENT DATE FALLS EXACTLY ON A COUPON DATE, which is what makes this example computable in closed form: the days from settlement to the next coupon equal the days in that coupon period, so their ratio is 1 on every documented day-count basis that measures both with the same ruler, and the k-th cash flow sits at exactly k/2 years. With a coupon of 100 x 0.08/2 = 4 per period, 100 returned at the end, and a per-period yield of 0.09/2 = 0.045, the price per 100 face is 94.382992475446753, the Macaulay duration is 5.9937749555451836 years, and the modified duration is 5.9937749555451836 / 1.045 = 5.7356698139188359. Computed with mpmath at 50 digits, from the sixteen individual discounted cash flows, not from a closed-form annuity shortcut -- and cross-checked against LibreOffice's own PRICE and DURATION on the same bond, which return 94.3829924754 and 5.9937749555. Rounded to three places, 5.7356698139188359 is 5.736 -- Microsoft's published figure, reproduced exactly.; MISMATCH vs expected: expected 5.736, got 5.734
MDURATION LibreOffice Calc

=MDURATION(A2,A3,A4,A5,3,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If frequency is any number other than 1, 2, or 4, MDURATION returns the #NUM! error value." Three coupons a year is not one of the three permitted values.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MDURATION LibreOffice Calc

=MDURATION(A2,A3,-0.08,A5,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If yld < 0 or if coupon < 0, MDURATION returns the #NUM! error value." Asserted separately from the negative-yield case because the sentence names two arguments and an engine can guard one and not the other.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MDURATION LibreOffice Calc

=MDURATION(A2,A3,A4,-0.09,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If yld < 0 or if coupon < 0, MDURATION returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MDURATION LibreOffice Calc

=MDURATION(A3,A3,A4,A5,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents: "If settlement >= maturity, MDURATION returns the #NUM! error value." Equality is the boundary the >= sign includes.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MIDB Google Sheets

=MIDB(A2,0,5)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

The MID page documents: "If start_num is less than 1, MID returns the #VALUE! error value." Positions are 1-based -- "The first character in text has start_num 1" -- so 0 is outside the range rather than a synonym for the beginning. MIDB HAS NO PAGE OF ITS OWN ANY MORE. Microsoft's MID page -- the page that historically documented MID and MIDB together -- now carries only an Important box reading "The MIDB function is deprecated", and every worked example and argument rule on it is written for MID. MIDB is still listed as an Excel function, so it is in scope for this corpus, but the only documented behaviour available to assert is the behaviour it shares with MID: for text in which every character occupies one byte, a byte count and a character count are the same number, so MIDB must return what MID returns. Those are the cases asserted here, each traced to a specific sentence on the MID page. The genuinely byte-specific behaviour -- what happens to double-byte characters, which historically depended on whether the default language was a DBCS language -- is carried as a probe below rather than asserted, because Microsoft no longer publishes a rule for it.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
MINA Excel for the web

=MINA("abc",5)

Actual result
#VALUE!

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Verbatim from Microsoft's MINA page: 'Arguments that contain text or FALSE evaluate as 0 (zero)'. Under that rule the literal "abc" becomes 0, which is smaller than 5. MIN's page carries the opposite rule, so this case checks the A-variant rule is applied; MISMATCH vs expected: expected 0, got '#VALUE!'
MINA Google Sheets

=MINA("abc",5)

Actual result
#VALUE!

Documented / expected
0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Verbatim from Microsoft's MINA page: 'Arguments that contain text or FALSE evaluate as 0 (zero)'. Under that rule the literal "abc" becomes 0, which is smaller than 5. MIN's page carries the opposite rule, so this case checks the A-variant rule is applied; MISMATCH vs expected: expected 0, got '#VALUE!'
MINUS Excel for the web

=MINUS(3,4)+MINUS(4,3)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural consequence of the minuend/subtrahend argument descriptions: if the order of the two arguments decides the sign, the two orderings must sum to zero. No constant is derived. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 0, got '#NAME?'
MINUS LibreOffice Calc

=MINUS(3,4)+MINUS(4,3)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural consequence of the minuend/subtrahend argument descriptions: if the order of the two arguments decides the sign, the two orderings must sum to zero. No constant is derived. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 0, got '#NAME?'
MINUS Excel for the web

=MINUS(A2,A3)

Actual result
#NAME?

Documented / expected
7.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the same definition; the page publishes no results. Its Examples section is an embedded live spreadsheet whose cells are not part of the article text. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 7.5, got '#NAME?'
MINUS LibreOffice Calc

=MINUS(A2,A3)

Actual result
#NAME?

Documented / expected
7.5

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the same definition; the page publishes no results. Its Examples section is an embedded live spreadsheet whose cells are not part of the article text. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 7.5, got '#NAME?'
MINUS Excel for the web

=MINUS(3,4)

Actual result
#NAME?

Documented / expected
-1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints MINUS(3,4) with no result; -1 is DERIVED from the page's definition, "Returns the difference of two numbers. Equivalent to the `-` operator", together with its argument descriptions ("value1 - The minuend, or number to be subtracted from", "value2 - The subtrahend"), which fix the direction of the subtraction. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected -1, got '#NAME?'
MINUS LibreOffice Calc

=MINUS(3,4)

Actual result
#NAME?

Documented / expected
-1

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints MINUS(3,4) with no result; -1 is DERIVED from the page's definition, "Returns the difference of two numbers. Equivalent to the `-` operator", together with its argument descriptions ("value1 - The minuend, or number to be subtracted from", "value2 - The subtrahend"), which fix the direction of the subtraction. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected -1, got '#NAME?'
MINUS Excel for the web

=MINUS(A2,A3)-(A2-A3)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from the `-` operator equivalence. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 0, got '#NAME?'
MINUS LibreOffice Calc

=MINUS(A2,A3)-(A2-A3)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from the `-` operator equivalence. Google's MINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093977.; MISMATCH vs expected: expected 0, got '#NAME?'
MINVERSE LibreOffice Calc

=INDEX(MINVERSE({1,2;2,4}),1,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Excel documents: "Some square matrices cannot be inverted and will return the #NUM! error value with MINVERSE. The determinant for a noninvertable matrix is 0." The matrix {1,2;2,4} has determinant exactly zero (the second row is twice the first), so it is precisely the case the page describes. Note the documented code here is #NUM!, while the empty/text/non-square conditions on the same page are documented as #VALUE! -- the page distinguishes "this matrix has no inverse" from "this is not a matrix", so both codes are asserted.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
MIRR LibreOffice Calc

=MIRR(A1:A3,0.1,0.12)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

With no negative cash flow the denominator NPV of the outflows is zero, and Excel documents that MIRR requires at least one positive and one negative value or it returns #DIV/0!; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
MODE LibreOffice Calc

=MODE(A1:A4)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft's MODE docs state verbatim: 'If the data set contains no duplicate data points, MODE returns the #N/A error value' -- https://support.microsoft.com/en-us/office/mode-function-e45192ce-9122-4980-82ed-4bdc34973120; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
MODE.SNGL LibreOffice Calc

=MODE.SNGL(1,2,3)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected #N/A, got #VALUE!
MONTH Google Sheets

=MONTH(1)

Actual result
12

Documented / expected
1

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1, got 12
MONTH LibreOffice Calc

=MONTH(1)

Actual result
12

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1, got 12
MONTHS Excel for the web

=MONTHS(DATE(2020,1,31),DATE(2020,3,1),1)

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

THIS PAGE PUBLISHES NO EXAMPLES AND ALMOST NO SEMANTICS, AND THIS FILE SAYS SO RATHER THAN INVENTING THEM. MONTHS's entire entry is: "Calculates the difference in months between two dates", a Syntax block, "StartDate is the first date", "EndDate is the second date", and "Type calculates the type of difference. Possible values include 0 (interval) and 1 (in calendar months)." There is no Example section, no statement of sign convention for reversed dates, and no statement of what happens for any Type other than 0 or 1 -- note the page's own hedge, 'possible values INCLUDE'. Nothing is asserted about any of those. What IS asserted is the two parenthetical glosses, on a date pair chosen so that the two readings give DIFFERENT answers and the case can therefore tell them apart. Under 'in calendar months' the difference is between the months themselves, January to March = 2, regardless of the day-of-month. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 2, got '#NAME?'
MONTHS Google Sheets

=MONTHS(DATE(2020,1,31),DATE(2020,3,1),1)

Actual result
#NAME?

Documented / expected
2

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

THIS PAGE PUBLISHES NO EXAMPLES AND ALMOST NO SEMANTICS, AND THIS FILE SAYS SO RATHER THAN INVENTING THEM. MONTHS's entire entry is: "Calculates the difference in months between two dates", a Syntax block, "StartDate is the first date", "EndDate is the second date", and "Type calculates the type of difference. Possible values include 0 (interval) and 1 (in calendar months)." There is no Example section, no statement of sign convention for reversed dates, and no statement of what happens for any Type other than 0 or 1 -- note the page's own hedge, 'possible values INCLUDE'. Nothing is asserted about any of those. What IS asserted is the two parenthetical glosses, on a date pair chosen so that the two readings give DIFFERENT answers and the case can therefore tell them apart. Under 'in calendar months' the difference is between the months themselves, January to March = 2, regardless of the day-of-month. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 2, got '#NAME?'
MONTHS Excel for the web

=MONTHS(DATE(2020,1,31),DATE(2020,3,1),0)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the other gloss, 'interval', on the identical arguments: an interval counts whole elapsed months, and from 31 January only one whole month has elapsed by 1 March (the second would complete on 31 March). This is the case that separates the two Types; if both returned 2 the Type argument would be doing nothing. LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
MONTHS Google Sheets

=MONTHS(DATE(2020,1,31),DATE(2020,3,1),0)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the other gloss, 'interval', on the identical arguments: an interval counts whole elapsed months, and from 31 January only one whole month has elapsed by 1 March (the second would complete on 31 March). This is the case that separates the two Types; if both returned 2 the Type argument would be doing nothing. LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
MONTHS Excel for the web

=MONTHS(DATE(2020,1,15),DATE(2021,1,15),0)

Actual result
#NAME?

Documented / expected
12

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from either gloss: a full year from the 15th to the 15th is twelve whole elapsed months and also twelve calendar months. A case where the two readings coincide is the control for the pair above -- it fixes the SCALE of the answer (months, not days or years) independently of the Type semantics. LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 12, got '#NAME?'
MONTHS Google Sheets

=MONTHS(DATE(2020,1,15),DATE(2021,1,15),0)

Actual result
#NAME?

Documented / expected
12

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from either gloss: a full year from the 15th to the 15th is twelve whole elapsed months and also twelve calendar months. A case where the two readings coincide is the control for the pair above -- it fixes the SCALE of the answer (months, not days or years) independently of the Type semantics. LibreOffice's MONTHS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 12, got '#NAME?'
MROUND LibreOffice Calc

=MROUND(5,-2)

Actual result
6

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

MISMATCH vs expected: expected '#NUM!', got 6
MULTIPLY Excel for the web

=MULTIPLY(2,3)-PRODUCT(2,3)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The Notes bullet reads: "Unlike PRODUCT, MULTIPLY only supports the multiplication of two scalar values and takes neither ranges nor more than two arguments." As with ADD/SUM the distinction is about what each ACCEPTS, so on two scalars they must agree. The page names no error value for the range/three-argument cases it excludes, so nothing is asserted about them. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected 0, got '#NAME?'
MULTIPLY LibreOffice Calc

=MULTIPLY(2,3)-PRODUCT(2,3)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The Notes bullet reads: "Unlike PRODUCT, MULTIPLY only supports the multiplication of two scalar values and takes neither ranges nor more than two arguments." As with ADD/SUM the distinction is about what each ACCEPTS, so on two scalars they must agree. The page names no error value for the range/three-argument cases it excludes, so nothing is asserted about them. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected 0, got '#NAME?'
MULTIPLY Excel for the web

=MULTIPLY(A2,B2)

Actual result
#NAME?

Documented / expected
-6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the same definition; the page publishes no results. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected -6, got '#NAME?'
MULTIPLY LibreOffice Calc

=MULTIPLY(A2,B2)

Actual result
#NAME?

Documented / expected
-6

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the same definition; the page publishes no results. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected -6, got '#NAME?'
MULTIPLY Excel for the web

=MULTIPLY(2,3)

Actual result
#NAME?

Documented / expected
6

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints MULTIPLY(2,3) with no result; 6 is DERIVED from the page's definition, "Returns the product of two numbers. Equivalent to the `*` operator." Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 6, got '#NAME?'
MULTIPLY LibreOffice Calc

=MULTIPLY(2,3)

Actual result
#NAME?

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints MULTIPLY(2,3) with no result; 6 is DERIVED from the page's definition, "Returns the product of two numbers. Equivalent to the `*` operator." Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 6, got '#NAME?'
MULTIPLY Excel for the web

=MULTIPLY(A2,B2)-(A2*B2)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from the `*` operator equivalence. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected 0, got '#NAME?'
MULTIPLY LibreOffice Calc

=MULTIPLY(A2,B2)-(A2*B2)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from the `*` operator equivalence. Google's MULTIPLY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093978.; MISMATCH vs expected: expected 0, got '#NAME?'
MUNIT Google Sheets

=MUNIT(-1)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

The same documented clause -- "equal to or smaller than zero (0)" -- exercised below the boundary rather than on it. Asserted separately because an engine can guard the equality and not the inequality.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
MUNIT Google Sheets

=MUNIT(0)

Actual result
#NUM!

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

Microsoft documents: "If dimension is a value that's equal to or smaller than zero (0), MUNIT returns the #VALUE! error value", and separately "The dimension has to be greater than zero." OpenFormula 1.3 section 6.5.5 states the same constraint ("The dimension has to be greater than zero"). Zero is the boundary the words "equal to" include. Note this family uses #VALUE! rather than the #NUM! that most out-of-range numeric arguments produce elsewhere in Excel, which is exactly why it is worth asserting.; MISMATCH vs expected: expected '#VALUE!', got '#NUM!'
NE Excel for the web

=NE("a","A")=("a"<>"A")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected True, got '#NAME?'
NE LibreOffice Calc

=NE("a","A")=("a"<>"A")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A STRUCTURAL assertion with no derived constant, and deliberately so: the page never says how text compares, or whether the comparison is case sensitive, so the only thing it licenses is that the function and the operator must return the SAME answer. This case asserts that agreement and nothing about the answer itself. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected True, got '#NAME?'
NE Excel for the web

=NE(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected True, got '#NAME?'
NE LibreOffice Calc

=NE(A2,A3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The same comparison through cell references. The page names A2 and A3 without populating them, so this corpus chose 2 and 3 to match the literal sample. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected True, got '#NAME?'
NE Excel for the web

=NE(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints NE(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<>` operator" clause. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
NE LibreOffice Calc

=NE(2,3)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints NE(2,3) with no result; TRUE is DERIVED from the page's one-line definition and its "Equivalent to the `<>` operator" clause. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence. THE PAGE SAYS NOTHING ABOUT TEXT. None of the six comparison-operator pages (EQ, NE, GT, GTE, LT, LTE) makes any statement about comparing text to text, text to numbers, mixed types, or case sensitivity, and none of them prints a single result value; their Examples sections are embedded live spreadsheets whose cells are not part of the article text. So this file asserts text behaviour only STRUCTURALLY -- the function must agree with the operator it is documented to be equivalent to, whatever that operator does -- and never asserts what the comparison itself yields on text.; MISMATCH vs expected: expected True, got '#NAME?'
NE Excel for the web

=NE(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the exact wording of the definition and the `<>` equivalence. This is the case that separates NE from its neighbours, and Google publishes no example of it. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected False, got '#NAME?'
NE LibreOffice Calc

=NE(5,5)

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the exact wording of the definition and the `<>` equivalence. This is the case that separates NE from its neighbours, and Google publishes no example of it. Google's NE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093981.; MISMATCH vs expected: expected False, got '#NAME?'
NEGBINOM.DIST LibreOffice Calc

=NEGBINOM.DIST(A2,A3,1.5,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If probability_s < 0 or if probability > 1, NEGBINOM.DIST returns the #NUM! error value." (The sentence is quoted as printed: Microsoft's own text drops the _s in its second clause.) OpenFormula 1.3 section 6.18.51 imposes the same constraint on its NEGBINOMDIST.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NEGBINOM.DIST LibreOffice Calc

=NEGBINOM.DIST(A2,0,A4,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If number_f < 0 or number_s < 1, NEGBINOM.DIST returns the #NUM! error value." Zero successes is below the documented floor of one. Asserted separately from the probability case because the sentence names two different arguments and an engine can guard one and not the other.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NEGBINOMDIST LibreOffice Calc

=NEGBINOMDIST(-1,A3,A4)

Actual result
0.0009765625

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If number_f < 0 or number_s < 1, NEGBINOMDIST returns the #NUM! error value." EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 0.0009765625 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM!. That number is (1/4)^5, the mass at ZERO failures: the engine has taken a documented-invalid -1 and evaluated the distribution as though 0 had been passed. A user who lands a negative value in this argument gets a plausible probability back instead of an error. NEGBINOM.DIST, the modern spelling of the same function, rejects the same input on the same builds (with #VALUE! rather than the documented #NUM!), so the two spellings do not even agree with each other about whether the input is legal.; MISMATCH vs expected: expected '#NUM!', got 0.0009765625
NEGBINOMDIST LibreOffice Calc

=NEGBINOMDIST(A2,A3,1.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If probability_s < 0 or if probability > 1, NEGBINOMDIST returns the #NUM! error value." (Quoted as printed, including the dropped _s.); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORM.DIST LibreOffice Calc

=NORM.DIST(42,40,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents #NUM! when standard_dev is less than or equal to 0; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORM.INV LibreOffice Calc

=NORM.INV(0.5,40,-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents #NUM! when standard_dev <= 0; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORM.INV LibreOffice Calc

=NORM.INV(0,40,1.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Excel documents #NUM! if probability <= 0 or probability >= 1 (the normal quantile is unbounded at the endpoints); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORM.S.INV LibreOffice Calc

=NORM.S.INV(-0.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents #NUM! if probability <= 0 or probability >= 1; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORM.S.INV LibreOffice Calc

=NORM.S.INV(1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents #NUM! if probability <= 0 or probability >= 1; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMDIST LibreOffice Calc

=NORMDIST(A2,A3,0,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If standard_dev <= 0, NORMDIST returns the #NUM! error value." Zero is the boundary the <= includes. OpenFormula 1.3 section 6.18.52 states the same constraint ("StandardDeviation > 0").; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMINV LibreOffice Calc

=NORMINV(1,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The upper half of "If probability <= 0 or if probability >= 1, NORMINV returns the #NUM! error value", asserted separately because an engine can guard one end and not the other.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMINV LibreOffice Calc

=NORMINV(0,A3,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If probability <= 0 or if probability >= 1, NORMINV returns the #NUM! error value." Zero is the boundary the <= includes -- the normal distribution has unbounded support, so there is no finite x with Phi(x) = 0.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMINV LibreOffice Calc

=NORMINV(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If standard_dev <= 0, NORMINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMSINV Google Sheets

=ROUND(NORMSINV(0.9088),8)

Actual result
1.33340174

Documented / expected
1.33340175

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Compatibility

Four published decimals cannot tell a well-converged inverse from a rough one, so the root-found value is asserted at eight places: 1.33340175. Microsoft documents the iteration -- "NORMSINV uses an iterative search technique. If the search has not converged after 100 iterations, the function returns the #N/A error value" -- which is exactly the behaviour this precision is aimed at.; MISMATCH vs expected: expected 1.33340175, got 1.33340174
NORMSINV LibreOffice Calc

=NORMSINV(1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The upper half of the same documented sentence, asserted separately because an engine can guard one end and not the other.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NORMSINV LibreOffice Calc

=NORMSINV(0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If Probability <= 0 or if Probability >= 1, NORMSINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
NUMBERVALUE Google Sheets

=NUMBERVALUE("1234.56",".",",")

Actual result
#NAME?

Documented / expected
1234.56

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 1234.56, got '#NAME?'
NUMBERVALUE Google Sheets

=NUMBERVALUE("12.34.56",".",",")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Source: https://support.microsoft.com/en-us/office/numbervalue-function-1b05c8cf-2bfa-4437-af70-596c7ea7d879 - decimal separator used multiple times is explicitly called out as an error condition; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
NUMBERVALUE Google Sheets

=NUMBERVALUE("2.500,27",",",".")

Actual result
#NAME?

Documented / expected
2500.27

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Matches Microsoft's own documented example. Source: https://support.microsoft.com/en-us/office/numbervalue-function-1b05c8cf-2bfa-4437-af70-596c7ea7d879; MISMATCH vs expected: expected 2500.27, got '#NAME?'
NUMBERVALUE Google Sheets

=NUMBERVALUE("abc",".",",")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Source: https://support.microsoft.com/en-us/office/numbervalue-function-1b05c8cf-2bfa-4437-af70-596c7ea7d879 - 'If any of the arguments are not valid, NUMBERVALUE returns the #VALUE! error value'; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
ODDFPRICE Google Sheets

=ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,5)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDFPRICE returns the #NUM! error value." The basis table stops at 4 (European 30/360).; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFPRICE LibreOffice Calc

=ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDFPRICE returns the #NUM! error value." The basis table stops at 4 (European 30/360).; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDFPRICE Google Sheets

=ODDFPRICE(A5,A3,A4,A2,A6,A7,A8,A9,A10)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDFPRICE returns the #NUM! error value: maturity > first_coupon > settlement > issue." Swapping the settlement and first-coupon arguments puts settlement (2009-03-01) after first_coupon (2008-11-11) and also before issue, breaking the chain in two places at once.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFPRICE LibreOffice Calc

=ODDFPRICE(A5,A3,A4,A2,A6,A7,A8,A9,A10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDFPRICE returns the #NUM! error value: maturity > first_coupon > settlement > issue." Swapping the settlement and first-coupon arguments puts settlement (2009-03-01) after first_coupon (2008-11-11) and also before issue, breaking the chain in two places at once.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDFPRICE Google Sheets

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,A10),8)

Actual result
#NAME?

Documented / expected
113.59771747

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Two published decimals cannot distinguish a correct odd-period price from one whose quasi-coupon schedule is off by a day, so the derived value is asserted at eight places: 113.59771747. This is the assertion that actually constrains the day counts.; MISMATCH vs expected: expected 113.59771747, got '#NAME?'
ODDFPRICE LibreOffice Calc

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,A10),8)

Actual result
#VALUE!

Documented / expected
113.59771747

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Two published decimals cannot distinguish a correct odd-period price from one whose quasi-coupon schedule is off by a day, so the derived value is asserted at eight places: 113.59771747. This is the assertion that actually constrains the day counts.; MISMATCH vs expected: expected 113.59771747, got '#VALUE!'
ODDFPRICE Google Sheets

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,A10),2)

Actual result
#NAME?

Documented / expected
113.6

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft publishes =ODDFPRICE(A2, A3, A4, A5, A6, A7, A8, A9, A10) = $ 113.60 for a bond settled 2008-11-11, maturing 2021-03-01, issued 2008-10-15, first coupon 2009-03-01, 7.85% coupon, 6.25% yield, redemption 100, semiannual, actual/actual basis. DERIVATION, clean-room, from the odd-short-first-coupon formula Microsoft prints as an image on the page: price = redemption/(1+yld/f)^(N-1+DSC/E) + 100*(rate/f)*(DFC/E)/(1+yld/f)^(DSC/E) + sum over k = 2..N of 100*(rate/f)/(1+yld/f)^(k-1+DSC/E) - 100*(rate/f)*(A/E), with A = days from the start of the coupon period to settlement, DSC = days from settlement to the next coupon, DFC = days from the start of the odd first coupon to the first coupon date, E = days in the coupon period, and N = coupons payable between settlement and redemption. The quasi-coupon period is generated by walking BACK from first_coupon on the frequency grid, which puts the period at 2008-09-01 to 2009-03-01. On basis 1 (actual/actual) that is E = 181 actual days, with A = 27 (2008-10-15 to 2008-11-11), DSC = 110 (2008-11-11 to 2009-03-01), DFC = 137 (2008-10-15 to 2009-03-01) and N = 25 semiannual coupons from 2009-03-01 through 2021-03-01. The odd first period is SHORT -- 137 days against a 181-day quasi-period -- which is what selects this branch of the formula over the odd-long-first-coupon branch. The day counts come from a clean-room implementation of OpenFormula 1.3 section 4.11.7 -- Procedure A for US (NASD) 30/360 with its four order-dependent endpoint adjustments, Procedure B for actual days, Procedure C for European 30/360, and Procedures D/E/F for days-in-year -- written for this batch and used by no engine; the arithmetic is mpmath at 50 digits over exact rational day-count ratios. The independent computation gives 113.5977174740789..., which is 113.60 at the two decimals Microsoft prints -- the published figure, reproduced from the formula rather than copied. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddfprice-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- NOT IMPLEMENTED, AND NOT SIGNALLED AS SUCH: LibreOffice returns #VALUE! on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case -- for this case, for every other case in this file, and for every argument combination probed while preparing the batch (five bases, three frequencies, settlement before and after the first coupon, dates as serials, as DATE() calls and as text, and a bond whose first period is deliberately regular). Not one input produced a number. The name is RECOGNISED -- the plain spelling parses, while _xlfn.ODDFPRICE, COM.MICROSOFT.ODDFPRICE and ORG.OPENOFFICE.ODDFPRICE are all #NAME? -- so this is not a storage-form artefact, and it is not an .xlsx import artefact either: the same #VALUE! comes back when the formula is parsed natively by LibreOffice's own parser rather than read from OOXML, on a run where ODDLPRICE and PRICE in the same file computed correctly. LibreOffice's source says why, in as many words: scaddins/source/analysis/analysishelper.cxx defines GetOddfprice() and GetOddfyield() as bodies that do nothing but `throw uno::RuntimeException()`, and financial.cxx wraps both call sites in SAL_WNOUNREACHABLE_CODE_PUSH under the comment "Encapsulation violation: We *know* that GetOddfprice() always throws." The argument validation in front of them is real (rate < 0, frequency, date ordering are all checked) but every path that survives it ends in the same exception, which is why the error cases in this file also come back #VALUE! instead of the documented #NUM!. So: the function is listed, documented in LibreOffice's own help, and computes nothing. Its ODDL* siblings, by contrast, compute the documented values exactly.; MISMATCH vs expected: expected 113.6, got '#NAME?'
ODDFPRICE LibreOffice Calc

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,A10),2)

Actual result
#VALUE!

Documented / expected
113.6

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft publishes =ODDFPRICE(A2, A3, A4, A5, A6, A7, A8, A9, A10) = $ 113.60 for a bond settled 2008-11-11, maturing 2021-03-01, issued 2008-10-15, first coupon 2009-03-01, 7.85% coupon, 6.25% yield, redemption 100, semiannual, actual/actual basis. DERIVATION, clean-room, from the odd-short-first-coupon formula Microsoft prints as an image on the page: price = redemption/(1+yld/f)^(N-1+DSC/E) + 100*(rate/f)*(DFC/E)/(1+yld/f)^(DSC/E) + sum over k = 2..N of 100*(rate/f)/(1+yld/f)^(k-1+DSC/E) - 100*(rate/f)*(A/E), with A = days from the start of the coupon period to settlement, DSC = days from settlement to the next coupon, DFC = days from the start of the odd first coupon to the first coupon date, E = days in the coupon period, and N = coupons payable between settlement and redemption. The quasi-coupon period is generated by walking BACK from first_coupon on the frequency grid, which puts the period at 2008-09-01 to 2009-03-01. On basis 1 (actual/actual) that is E = 181 actual days, with A = 27 (2008-10-15 to 2008-11-11), DSC = 110 (2008-11-11 to 2009-03-01), DFC = 137 (2008-10-15 to 2009-03-01) and N = 25 semiannual coupons from 2009-03-01 through 2021-03-01. The odd first period is SHORT -- 137 days against a 181-day quasi-period -- which is what selects this branch of the formula over the odd-long-first-coupon branch. The day counts come from a clean-room implementation of OpenFormula 1.3 section 4.11.7 -- Procedure A for US (NASD) 30/360 with its four order-dependent endpoint adjustments, Procedure B for actual days, Procedure C for European 30/360, and Procedures D/E/F for days-in-year -- written for this batch and used by no engine; the arithmetic is mpmath at 50 digits over exact rational day-count ratios. The independent computation gives 113.5977174740789..., which is 113.60 at the two decimals Microsoft prints -- the published figure, reproduced from the formula rather than copied. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddfprice-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- NOT IMPLEMENTED, AND NOT SIGNALLED AS SUCH: LibreOffice returns #VALUE! on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case -- for this case, for every other case in this file, and for every argument combination probed while preparing the batch (five bases, three frequencies, settlement before and after the first coupon, dates as serials, as DATE() calls and as text, and a bond whose first period is deliberately regular). Not one input produced a number. The name is RECOGNISED -- the plain spelling parses, while _xlfn.ODDFPRICE, COM.MICROSOFT.ODDFPRICE and ORG.OPENOFFICE.ODDFPRICE are all #NAME? -- so this is not a storage-form artefact, and it is not an .xlsx import artefact either: the same #VALUE! comes back when the formula is parsed natively by LibreOffice's own parser rather than read from OOXML, on a run where ODDLPRICE and PRICE in the same file computed correctly. LibreOffice's source says why, in as many words: scaddins/source/analysis/analysishelper.cxx defines GetOddfprice() and GetOddfyield() as bodies that do nothing but `throw uno::RuntimeException()`, and financial.cxx wraps both call sites in SAL_WNOUNREACHABLE_CODE_PUSH under the comment "Encapsulation violation: We *know* that GetOddfprice() always throws." The argument validation in front of them is real (rate < 0, frequency, date ordering are all checked) but every path that survives it ends in the same exception, which is why the error cases in this file also come back #VALUE! instead of the documented #NUM!. So: the function is listed, documented in LibreOffice's own help, and computes nothing. Its ODDL* siblings, by contrast, compute the documented values exactly.; MISMATCH vs expected: expected 113.6, got '#VALUE!'
ODDFPRICE Google Sheets

=ODDFPRICE("not a date",A3,A4,A5,A6,A7,A8,A9,A10)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If settlement, maturity, issue, or first_coupon is not a valid date, ODDFPRICE returns the #VALUE! error value." The page uses #VALUE! for a malformed date and #NUM! for every out-of-range or mis-ordered argument, so the two codes are asserted separately.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
ODDFPRICE Google Sheets

=ODDFPRICE(A2,A3,A4,A5,-0.0785,A7,A8,A9,A10)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If rate < 0 or if yld < 0, ODDFPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFPRICE LibreOffice Calc

=ODDFPRICE(A2,A3,A4,A5,-0.0785,A7,A8,A9,A10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If rate < 0 or if yld < 0, ODDFPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDFPRICE Google Sheets

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,0),8)

Actual result
#NAME?

Documented / expected
113.59920583

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

The same bond on basis 0, where every day count is taken under Procedure A instead of actual days: E = 180, A = 26, DSC = 106, DFC = 136. The derived price is 113.5992058282384..., asserted at eight places. The two bases MUST differ here -- unlike the MDURATION case in batch E, settlement does not fall on a coupon date, so the ratios genuinely change -- and the pair of cases pins which basis the engine applied. A basis argument that is silently ignored produces the basis-0 number for the basis-1 case, and this file catches that.; MISMATCH vs expected: expected 113.59920583, got '#NAME?'
ODDFPRICE LibreOffice Calc

=ROUND(ODDFPRICE(A2,A3,A4,A5,A6,A7,A8,A9,0),8)

Actual result
#VALUE!

Documented / expected
113.59920583

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The same bond on basis 0, where every day count is taken under Procedure A instead of actual days: E = 180, A = 26, DSC = 106, DFC = 136. The derived price is 113.5992058282384..., asserted at eight places. The two bases MUST differ here -- unlike the MDURATION case in batch E, settlement does not fall on a coupon date, so the ratios genuinely change -- and the pair of cases pins which basis the engine applied. A basis argument that is silently ignored produces the basis-0 number for the basis-1 case, and this file catches that.; MISMATCH vs expected: expected 113.59920583, got '#VALUE!'
ODDFYIELD Google Sheets

=ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,5)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDFYIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFYIELD LibreOffice Calc

=ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDFYIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDFYIELD Google Sheets

=ODDFYIELD(A5,A3,A4,A2,A6,A7,A8,A9,A10)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDFYIELD returns the #NUM! error value: maturity > first_coupon > settlement > issue."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFYIELD LibreOffice Calc

=ODDFYIELD(A5,A3,A4,A2,A6,A7,A8,A9,A10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDFYIELD returns the #NUM! error value: maturity > first_coupon > settlement > issue."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDFYIELD Google Sheets

=ROUND(ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,A10),8)

Actual result
#NAME?

Documented / expected
0.07724554

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Four published decimals leave the iteration untested, so the root is asserted at eight places: 0.07724554. Microsoft states the convergence rule loosely -- "The yield is changed through 100 iterations until the estimated price with the given yield is close to the price" -- without defining "close", so this is exactly the kind of case where two conforming implementations can legitimately differ in the last digit or two; eight places is deliberately short of the fifteen a double carries.; MISMATCH vs expected: expected 0.07724554, got '#NAME?'
ODDFYIELD LibreOffice Calc

=ROUND(ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,A10),8)

Actual result
#VALUE!

Documented / expected
0.07724554

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Four published decimals leave the iteration untested, so the root is asserted at eight places: 0.07724554. Microsoft states the convergence rule loosely -- "The yield is changed through 100 iterations until the estimated price with the given yield is close to the price" -- without defining "close", so this is exactly the kind of case where two conforming implementations can legitimately differ in the last digit or two; eight places is deliberately short of the fifteen a double carries.; MISMATCH vs expected: expected 0.07724554, got '#VALUE!'
ODDFYIELD Google Sheets

=ROUND(ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,A10),4)

Actual result
#NAME?

Documented / expected
0.0772

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft publishes =ODDFYIELD(A2, A3, A4, A5, A6, A7, A8, A9, A10) = 7.72% for a bond settled 2008-11-11, maturing 2021-03-01, issued 2008-10-15, first coupon 2009-03-01, 5.75% coupon, price 84.50, redemption 100, semiannual, 30/360 basis, and the page's own description spells the same figure as "(0.0772, or 7.72%)". DERIVATION: Microsoft publishes no closed form -- "Excel uses an iterative technique to calculate ODDFYIELD. This function uses the Newton method based on the formula used for the function ODDFPRICE" -- so the value here is obtained by root-finding on this batch's own clean-room ODDFPRICE implementation (see data/tests/ODDFPRICE.json for its derivation), solving price(yield) = 84.5 with mpmath at 50 digits. The root is 0.07724554159781..., which is 0.0772 at four places -- Microsoft's published figure. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddfyield-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- NOT IMPLEMENTED, AND NOT SIGNALLED AS SUCH: LibreOffice returns #VALUE! on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case -- for this case, for every other case in this file, and for every argument combination probed while preparing the batch (five bases, three frequencies, settlement before and after the first coupon, dates as serials, as DATE() calls and as text, and a bond whose first period is deliberately regular). Not one input produced a number. The name is RECOGNISED -- the plain spelling parses, while _xlfn.ODDFPRICE, COM.MICROSOFT.ODDFPRICE and ORG.OPENOFFICE.ODDFPRICE are all #NAME? -- so this is not a storage-form artefact, and it is not an .xlsx import artefact either: the same #VALUE! comes back when the formula is parsed natively by LibreOffice's own parser rather than read from OOXML, on a run where ODDLPRICE and PRICE in the same file computed correctly. LibreOffice's source says why, in as many words: scaddins/source/analysis/analysishelper.cxx defines GetOddfyield() and GetOddfprice() as bodies that do nothing but `throw uno::RuntimeException()`, and financial.cxx wraps both call sites in SAL_WNOUNREACHABLE_CODE_PUSH under the comment "Encapsulation violation: We *know* that GetOddfprice() always throws." The argument validation in front of them is real (rate < 0, frequency, date ordering are all checked) but every path that survives it ends in the same exception, which is why the error cases in this file also come back #VALUE! instead of the documented #NUM!. So: the function is listed, documented in LibreOffice's own help, and computes nothing. Its ODDL* siblings, by contrast, compute the documented values exactly.; MISMATCH vs expected: expected 0.0772, got '#NAME?'
ODDFYIELD LibreOffice Calc

=ROUND(ODDFYIELD(A2,A3,A4,A5,A6,A7,A8,A9,A10),4)

Actual result
#VALUE!

Documented / expected
0.0772

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft publishes =ODDFYIELD(A2, A3, A4, A5, A6, A7, A8, A9, A10) = 7.72% for a bond settled 2008-11-11, maturing 2021-03-01, issued 2008-10-15, first coupon 2009-03-01, 5.75% coupon, price 84.50, redemption 100, semiannual, 30/360 basis, and the page's own description spells the same figure as "(0.0772, or 7.72%)". DERIVATION: Microsoft publishes no closed form -- "Excel uses an iterative technique to calculate ODDFYIELD. This function uses the Newton method based on the formula used for the function ODDFPRICE" -- so the value here is obtained by root-finding on this batch's own clean-room ODDFPRICE implementation (see data/tests/ODDFPRICE.json for its derivation), solving price(yield) = 84.5 with mpmath at 50 digits. The root is 0.07724554159781..., which is 0.0772 at four places -- Microsoft's published figure. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddfyield-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- NOT IMPLEMENTED, AND NOT SIGNALLED AS SUCH: LibreOffice returns #VALUE! on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case -- for this case, for every other case in this file, and for every argument combination probed while preparing the batch (five bases, three frequencies, settlement before and after the first coupon, dates as serials, as DATE() calls and as text, and a bond whose first period is deliberately regular). Not one input produced a number. The name is RECOGNISED -- the plain spelling parses, while _xlfn.ODDFPRICE, COM.MICROSOFT.ODDFPRICE and ORG.OPENOFFICE.ODDFPRICE are all #NAME? -- so this is not a storage-form artefact, and it is not an .xlsx import artefact either: the same #VALUE! comes back when the formula is parsed natively by LibreOffice's own parser rather than read from OOXML, on a run where ODDLPRICE and PRICE in the same file computed correctly. LibreOffice's source says why, in as many words: scaddins/source/analysis/analysishelper.cxx defines GetOddfyield() and GetOddfprice() as bodies that do nothing but `throw uno::RuntimeException()`, and financial.cxx wraps both call sites in SAL_WNOUNREACHABLE_CODE_PUSH under the comment "Encapsulation violation: We *know* that GetOddfprice() always throws." The argument validation in front of them is real (rate < 0, frequency, date ordering are all checked) but every path that survives it ends in the same exception, which is why the error cases in this file also come back #VALUE! instead of the documented #NUM!. So: the function is listed, documented in LibreOffice's own help, and computes nothing. Its ODDL* siblings, by contrast, compute the documented values exactly.; MISMATCH vs expected: expected 0.0772, got '#VALUE!'
ODDFYIELD Google Sheets

=ROUND(ODDFYIELD(A2,A3,A4,A5,0.0785,ODDFPRICE(A2,A3,A4,A5,0.0785,0.0625,100,2,1),100,2,1),8)

Actual result
#NAME?

Documented / expected
0.0625

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft's page says outright that ODDFYIELD inverts ODDFPRICE ("See ODDFPRICE for the formula that ODDFYIELD uses"), so composing the two on one bond must return the yield it started from. This assertion contains NO derived constant -- 0.0625 is an input -- which makes it immune to any disagreement about day counts or quasi-coupon schedules: an engine with an unusual but self-consistent odd-period model still passes, and one whose yield solver does not invert its own price function fails. The bond is ODDFPRICE's documented example (7.85% coupon, basis 1), evaluated entirely inside the engine.; MISMATCH vs expected: expected 0.0625, got '#NAME?'
ODDFYIELD LibreOffice Calc

=ROUND(ODDFYIELD(A2,A3,A4,A5,0.0785,ODDFPRICE(A2,A3,A4,A5,0.0785,0.0625,100,2,1),100,2,1),8)

Actual result
#VALUE!

Documented / expected
0.0625

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft's page says outright that ODDFYIELD inverts ODDFPRICE ("See ODDFPRICE for the formula that ODDFYIELD uses"), so composing the two on one bond must return the yield it started from. This assertion contains NO derived constant -- 0.0625 is an input -- which makes it immune to any disagreement about day counts or quasi-coupon schedules: an engine with an unusual but self-consistent odd-period model still passes, and one whose yield solver does not invert its own price function fails. The bond is ODDFPRICE's documented example (7.85% coupon, basis 1), evaluated entirely inside the engine.; MISMATCH vs expected: expected 0.0625, got '#VALUE!'
ODDFYIELD Google Sheets

=ODDFYIELD(A2,A3,A4,A5,A6,0,A8,A9,A10)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If rate < 0 or if pr <= 0, ODDFYIELD returns the #NUM! error value." Note the asymmetry with ODDFPRICE, whose corresponding clause reads "rate < 0 or yld < 0": the price argument is excluded AT zero, the yield argument only BELOW it. Zero is the boundary the <= includes.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDFYIELD LibreOffice Calc

=ODDFYIELD(A2,A3,A4,A5,A6,0,A8,A9,A10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If rate < 0 or if pr <= 0, ODDFYIELD returns the #NUM! error value." Note the asymmetry with ODDFPRICE, whose corresponding clause reads "rate < 0 or yld < 0": the price argument is excluded AT zero, the yield argument only BELOW it. Zero is the boundary the <= includes.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLPRICE Google Sheets

=ODDLPRICE(A2,A3,A4,A5,A6,A7,A8,5)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDLPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLPRICE LibreOffice Calc

=ODDLPRICE(A2,A3,A4,A5,A6,A7,A8,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDLPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLPRICE Google Sheets

=ODDLPRICE(A4,A3,A2,A5,A6,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDLPRICE returns the #NUM! error value: maturity > settlement > last_interest." Swapping the two puts settlement (2007-10-15) before the last interest date (2008-02-07).; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLPRICE LibreOffice Calc

=ODDLPRICE(A4,A3,A2,A5,A6,A7,A8,A9)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDLPRICE returns the #NUM! error value: maturity > settlement > last_interest." Swapping the two puts settlement (2007-10-15) before the last interest date (2008-02-07).; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLPRICE Google Sheets

=ROUND(ODDLPRICE(A2,A3,A4,A5,A6,A7,A8,A9),10)

Actual result
#NAME?

Documented / expected
99.8782860147

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Two published decimals cannot see a day-count error of a day or two, so the inverted-formula value is asserted at ten places: 99.8782860147.; MISMATCH vs expected: expected 99.8782860147, got '#NAME?'
ODDLPRICE Google Sheets

=ROUND(ODDLPRICE(A2,A3,A4,A5,A6,A7,A8,A9),2)

Actual result
#NAME?

Documented / expected
99.88

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft publishes =ODDLPRICE(A2, A3, A4, A5, A6, A7, A8, A9) = $99.88 for a bond settled 2008-02-07, maturing 2008-06-15, last interest 2007-10-15, 3.75% coupon, 4.05% yield, redemption 100, semiannual, 30/360 basis. DERIVATION, clean-room. Microsoft publishes NO formula for ODDLPRICE -- the page has no 'calculated as follows' section and no equation image at all, which is the single biggest documentation gap in this batch -- and OpenFormula 1.3 section 6.12.33 gives only a parameter glossary. So the price here is obtained by ALGEBRAICALLY INVERTING the closed form Microsoft DOES publish, on the ODDLYIELD page, solving that equation for the price: pr = (redemption + (sum DCi/NLi)*100*rate/f) / (1 + (sum DSCi/NLi)*yld/f) - (sum Ai/NLi)*100*rate/f. For this bond the odd last period runs from the last interest date 2007-10-15 to maturity 2008-06-15 and spans two quasi-coupon periods on the semiannual grid, so on basis 0 the ratios are sum DCi/NLi = 240/180, sum Ai/NLi = 112/180 (2007-10-15 to settlement 2008-02-07) and sum DSCi/NLi = 128/180 (settlement to maturity). With a coupon of 100*0.0375/2 = 1.875 that gives (100 + 2.5)/(1 + (128/180)*0.02025) - 1.1666... = 99.87828601472134... The day counts come from a clean-room implementation of OpenFormula 1.3 section 4.11.7 -- Procedure A for US (NASD) 30/360 with its four order-dependent endpoint adjustments, Procedure B for actual days, Procedure C for European 30/360, and Procedures D/E/F for days-in-year -- written for this batch and used by no engine; the arithmetic is mpmath at 50 digits over exact rational day-count ratios. At two decimals that is 99.88 -- the published figure, reproduced from an inverted formula rather than copied. (Microsoft's own prose on this page says the arguments come from "cells A2:A10" while the formula it prints takes eight arguments from A2:A9; the same off-by-one appears on the ODDLYIELD page. It is a typo in the prose, not in the figure.) Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddlprice-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB).; MISMATCH vs expected: expected 99.88, got '#NAME?'
ODDLPRICE Google Sheets

=ODDLPRICE("not a date",A3,A4,A5,A6,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If settlement, maturity, or last_interest is not a valid date, ODDLPRICE returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
ODDLPRICE Google Sheets

=ROUND(ODDLPRICE(A2,A3,A4,A5,A6,A7,A8,A9),5)

Actual result
#NAME?

Documented / expected
99.87829

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

A SECOND VENDOR'S PUBLISHED FIGURE, on a second set of dates. LibreOffice's help (help.libreoffice.org/latest/en-US/text/scalc/01/04060118.html) prints '=ODDLPRICE("1999-02-07";"1999-06-15";"1998-10-15"; 0.0375; 0.0405;100;2;0) returns 99.87829' -- Microsoft's example shifted back exactly nine years, same month-and-day, same rates. Running the clean-room derivation on the 1999 dates gives 99.87828601472134..., identical to the 2008 answer, because every 30/360 day count in the calculation depends only on the month-and-day differences: 99.87829 at five places. Two independent vendors' documentation and one independent derivation agreeing on the same number is stronger evidence than any of the three alone, and this case is here to make that agreement executable.; MISMATCH vs expected: expected 99.87829, got '#NAME?'
ODDLPRICE Google Sheets

=ODDLPRICE(A2,A3,A4,A5,-0.0405,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If rate < 0 or if yld < 0, ODDLPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLPRICE LibreOffice Calc

=ODDLPRICE(A2,A3,A4,A5,-0.0405,A7,A8,A9)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If rate < 0 or if yld < 0, ODDLPRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLYIELD Google Sheets

=ODDLYIELD(A2,A3,A4,A5,A6,A7,A8,5)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDLYIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLYIELD LibreOffice Calc

=ODDLYIELD(A2,A3,A4,A5,A6,A7,A8,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, ODDLYIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLYIELD Google Sheets

=ODDLYIELD(A4,A3,A2,A5,A6,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDLYIELD returns the #NUM! error value: maturity > settlement > last_interest."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLYIELD LibreOffice Calc

=ODDLYIELD(A4,A3,A2,A5,A6,A7,A8,A9)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "The following date condition must be satisfied; otherwise, ODDLYIELD returns the #NUM! error value: maturity > settlement > last_interest."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
ODDLYIELD Google Sheets

=ROUND(ODDLYIELD(A2,A3,A4,A5,A6,A7,A8,A9),10)

Actual result
#NAME?

Documented / expected
0.0451922356

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Five published decimals are asserted again at ten: 0.0451922356. Unlike ODDFYIELD, this function has a closed form and no iteration, so there is no convergence tolerance to excuse a difference -- two conforming engines should agree to the last bit.; MISMATCH vs expected: expected 0.0451922356, got '#NAME?'
ODDLYIELD Google Sheets

=ROUND(ODDLYIELD(A2,A3,A4,A5,A6,A7,A8,A9),5)

Actual result
#NAME?

Documented / expected
0.04519

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft publishes =ODDLYIELD(A2, A3, A4, A5, A6, A7, A8, A9) = 4.52% for a bond settled 2008-04-20, maturing 2008-06-15, last interest 2007-12-24, 3.75% coupon, price 99.875, redemption 100, semiannual, 30/360 basis, and the page's description gives the same figure at five places as "0.04519". DERIVATION, clean-room, from the closed form Microsoft prints as an image on the page: yield = ((redemption + (sum DCi/NLi)*100*rate/f) - (pr + (sum Ai/NLi)*100*rate/f)) / (pr + (sum Ai/NLi)*100*rate/f) * f / (sum DSCi/NLi), where Ai is the accrued days in the ith quasi-coupon period counting forward from the last interest date, DCi the days counted in that period, and NLi its normal length. (Two symbols in Microsoft's artwork are never defined in the page's own symbol list: 'par', which the algebra forces to be the pr price argument under a third name, and DSCi, which must be the settlement-to-maturity day counts per quasi-period. Both readings are confirmed by the fact that they reproduce Microsoft's own published figure below.) For this bond the odd last period runs 2007-12-24 to 2008-06-15 and fits inside a single semiannual quasi-period, so on basis 0 the ratios are DC/NL = 171/180, A/NL = 116/180 and DSC/NL = 55/180; with a coupon of 1.875 that gives ((100 + 1.78125) - (99.875 + 1.20833...))/(99.875 + 1.20833...) * 2/(55/180) = 0.045192235629168917... The day counts come from a clean-room implementation of OpenFormula 1.3 section 4.11.7 -- Procedure A for US (NASD) 30/360 with its four order-dependent endpoint adjustments, Procedure B for actual days, Procedure C for European 30/360, and Procedures D/E/F for days-in-year -- written for this batch and used by no engine; the arithmetic is mpmath at 50 digits over exact rational day-count ratios. At five places that is 0.04519 -- the published figure, reproduced from the formula. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/oddlyield-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB).; MISMATCH vs expected: expected 0.04519, got '#NAME?'
ODDLYIELD Google Sheets

=ODDLYIELD("not a date",A3,A4,A5,A6,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If settlement, maturity, or last_interest is not a valid date, ODDLYIELD returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
ODDLYIELD Google Sheets

=ROUND(ODDLYIELD(A2,A3,A4,A5,ODDLPRICE(A2,A3,A4,A5,0.0405,A7,A8,A9),A7,A8,A9),10)

Actual result
#NAME?

Documented / expected
0.0405

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

The two functions are algebraic inverses of one another -- ODDLPRICE has no published formula precisely because it IS the ODDLYIELD equation solved for price -- so composing them on one bond must return the yield it started from, 0.0405. No derived constant appears in this assertion at all, so it holds for any engine whose two odd-last-period routines agree with each other, whatever day-count reading they share. The bond is ODDLPRICE's documented example.; MISMATCH vs expected: expected 0.0405, got '#NAME?'
ODDLYIELD Google Sheets

=ROUND(ODDLYIELD(A2,A3,A4,A5,A6,A7,A8,A9),6)

Actual result
#NAME?

Documented / expected
0.044873

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

A SECOND VENDOR'S PUBLISHED FIGURE ON A GENUINELY DIFFERENT BOND. LibreOffice's help prints '=ODDLYIELD("1999-04-20";"1999-06-15"; "1998-10-15"; 0.0375; 99.875; 100;2;0) returns 0.044873 or 4.4873%'. This is NOT Microsoft's example shifted nine years: the last interest date is 1998-10-15, where Microsoft's is 2007-12-24, so the odd last period spans TWO quasi-coupon periods instead of one and the answer is a different number. That makes it a second, independent test vector -- and the more demanding one, because the multi-period sums are exactly where a hand-rolled odd-period implementation goes wrong. The clean-room derivation on these dates gives 0.04487316633024..., which is 0.044873 at six places, matching LibreOffice's published figure exactly.; MISMATCH vs expected: expected 0.044873, got '#NAME?'
ODDLYIELD Google Sheets

=ODDLYIELD(A2,A3,A4,A5,0,A7,A8,A9)

Actual result
#NAME?

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Microsoft documents: "If rate < 0 or if pr <= 0, ODDLYIELD returns the #NUM! error value." Zero is the boundary the <= includes.; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
ODDLYIELD LibreOffice Calc

=ODDLYIELD(A2,A3,A4,A5,0,A7,A8,A9)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If rate < 0 or if pr <= 0, ODDLYIELD returns the #NUM! error value." Zero is the boundary the <= includes.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
OFFSET LibreOffice Calc

=OFFSET(A1,-1,0)

Actual result
#VALUE!

Documented / expected
#REF!

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

https://support.microsoft.com/en-us/office/offset-function-c8de19ae-dd79-4b9b-a14e-b4d906d11b66 -- 'If rows and cols offset reference over the edge of the worksheet, OFFSET returns the #REF! error value.'; MISMATCH vs expected: expected '#REF!', got '#VALUE!'
PDURATION LibreOffice Calc

=PDURATION(0.025,2000,-2200)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if pv or fv is less than or equal to 0, since the formula takes their natural logarithms; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PDURATION LibreOffice Calc

=PDURATION(0,2000,2200)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if rate is less than or equal to 0 (with no growth the target is never reached); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTILE.EXC LibreOffice Calc

=PERCENTILE.EXC(A1:A10,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTILE.EXC LibreOffice Calc

=PERCENTILE.EXC(A1:A10,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTILE.INC LibreOffice Calc

=PERCENTILE.INC(A1:A3,1.5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTOF Google Sheets

=ROUND(PERCENTOF(A2:A3,A2:A5)-SUM(A2:A3)/SUM(A2:A5),12)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

Microsoft's own equivalence claim made checkable: the difference between PERCENTOF and the SUM(subset)/SUM(all) it is "logically equivalent to" must be exactly zero. This needs no derived constant, and it catches an implementation that, say, averages instead of summing, or that divides by the count.; MISMATCH vs expected: expected 0, got '#NAME?'
PERCENTOF LibreOffice Calc

=ROUND(PERCENTOF(A2:A3,A2:A5)-SUM(A2:A3)/SUM(A2:A5),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Microsoft's own equivalence claim made checkable: the difference between PERCENTOF and the SUM(subset)/SUM(all) it is "logically equivalent to" must be exactly zero. This needs no derived constant, and it catches an implementation that, say, averages instead of summing, or that divides by the count.; MISMATCH vs expected: expected 0, got '#NAME?'
PERCENTOF Google Sheets

=ROUND(PERCENTOF(A2,A2:A5),12)

Actual result
#NAME?

Documented / expected
0.1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

1/10 = 0.1 exactly. A single cell is a legitimate data_subset -- Microsoft's argument table asks only for "The values that in the data subset" (the page's own wording, printed with that grammatical slip) -- so this case checks that a scalar reference is accepted where a range is expected.; MISMATCH vs expected: expected 0.1, got '#NAME?'
PERCENTOF LibreOffice Calc

=ROUND(PERCENTOF(A2,A2:A5),12)

Actual result
#NAME?

Documented / expected
0.1

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

1/10 = 0.1 exactly. A single cell is a legitimate data_subset -- Microsoft's argument table asks only for "The values that in the data subset" (the page's own wording, printed with that grammatical slip) -- so this case checks that a scalar reference is accepted where a range is expected.; MISMATCH vs expected: expected 0.1, got '#NAME?'
PERCENTOF Google Sheets

=ROUND(PERCENTOF(A2:A3,A2:A5),12)

Actual result
#NAME?

Documented / expected
0.3

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

Microsoft's page states the definition outright: "PERCENTOF is logically equivalent to =SUM(data_subset)/SUM(data_all)" and "The PERCENTOF function sums the values in the subset and divides it by all the values." DERIVATION in exact arithmetic: (1 + 2)/(1 + 2 + 3 + 4) = 3/10 = 0.3 exactly. The data is chosen so the answer is a terminating decimal, so no rounding question arises; the ROUND wrapper only pins the comparison. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/percentof-function (the /en-us/office/<name>-function-<guid> path was serving Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path returns an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all FOUR spellings probed before the run -- the plain name PERCENTOF, the storage form _xlfn.PERCENTOF, the add-in form COM.MICROSOFT.PERCENTOF and ORG.OPENOFFICE.PERCENTOF. No LibreOffice release tested here has this function under any name, so the gap is real and not a prefix artefact of the kind that batch E's ISO.CEILING episode was.; MISMATCH vs expected: expected 0.3, got '#NAME?'
PERCENTOF LibreOffice Calc

=ROUND(PERCENTOF(A2:A3,A2:A5),12)

Actual result
#NAME?

Documented / expected
0.3

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Microsoft's page states the definition outright: "PERCENTOF is logically equivalent to =SUM(data_subset)/SUM(data_all)" and "The PERCENTOF function sums the values in the subset and divides it by all the values." DERIVATION in exact arithmetic: (1 + 2)/(1 + 2 + 3 + 4) = 3/10 = 0.3 exactly. The data is chosen so the answer is a terminating decimal, so no rounding question arises; the ROUND wrapper only pins the comparison. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/percentof-function (the /en-us/office/<name>-function-<guid> path was serving Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path returns an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all FOUR spellings probed before the run -- the plain name PERCENTOF, the storage form _xlfn.PERCENTOF, the add-in form COM.MICROSOFT.PERCENTOF and ORG.OPENOFFICE.PERCENTOF. No LibreOffice release tested here has this function under any name, so the gap is real and not a prefix artefact of the kind that batch E's ISO.CEILING episode was.; MISMATCH vs expected: expected 0.3, got '#NAME?'
PERCENTOF Google Sheets

=ROUND(PERCENTOF(A2:A5,A2:A5),12)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Math and trigonometry

When the subset IS the set, the documented definition gives SUM(x)/SUM(x) = 1 exactly, for any data. Structural rather than derived, and it pins the argument order: an engine that divided all-by-subset would also return 1 here, which is why the 0.3 case above is asserted as well.; MISMATCH vs expected: expected 1, got '#NAME?'
PERCENTOF LibreOffice Calc

=ROUND(PERCENTOF(A2:A5,A2:A5),12)

Actual result
#NAME?

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

When the subset IS the set, the documented definition gives SUM(x)/SUM(x) = 1 exactly, for any data. Structural rather than derived, and it pins the argument order: an engine that divided all-by-subset would also return 1 here, which is why the 0.3 case above is asserted as well.; MISMATCH vs expected: expected 1, got '#NAME?'
PERCENTRANK Excel for the web

=PERCENTRANK(A1:A4,30)

Actual result
0.666

Documented / expected
0.667

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

MISMATCH vs expected: expected 0.667, got 0.666
PERCENTRANK.EXC Google Sheets

=PERCENTRANK.EXC(A2:A10,5.43,1)

Actual result
0.4

Documented / expected
0.3

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft publishes =PERCENTRANK.EXC(A2:A10,5.43,1) = 0.3, "displaying only 1 significant digit in the result (the default is 3)". 0.381 cut to one significant digit is 0.3 -- and note that it is CUT, not rounded: rounding 0.381 to one significant digit would give 0.4. This case is the one that pins the truncation semantics of the significance argument. EXECUTED RESULT: LibreOffice returns 0.4 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, against Microsoft's published 0.3. The rounding-versus-truncation split shown by PERCENTRANK.INC's repeating-decimal rows, here made visible at ONE significant digit, where it moves the answer by a third of its own size. The two full-precision rows of this file (0.7 and 0.381) pass on every build, so the engine's ranking arithmetic is right and only the significance step differs.; MISMATCH vs expected: expected 0.3, got 0.4
PERCENTRANK.EXC LibreOffice Calc

=PERCENTRANK.EXC(A2:A10,5.43,1)

Actual result
0.4

Documented / expected
0.3

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft publishes =PERCENTRANK.EXC(A2:A10,5.43,1) = 0.3, "displaying only 1 significant digit in the result (the default is 3)". 0.381 cut to one significant digit is 0.3 -- and note that it is CUT, not rounded: rounding 0.381 to one significant digit would give 0.4. This case is the one that pins the truncation semantics of the significance argument. EXECUTED RESULT: LibreOffice returns 0.4 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, against Microsoft's published 0.3. The rounding-versus-truncation split shown by PERCENTRANK.INC's repeating-decimal rows, here made visible at ONE significant digit, where it moves the answer by a third of its own size. The two full-precision rows of this file (0.7 and 0.381) pass on every build, so the engine's ranking arithmetic is right and only the significance step differs.; MISMATCH vs expected: expected 0.3, got 0.4
PERCENTRANK.EXC Excel for the web

=PERCENTRANK.EXC(D20:D25,7)

Actual result
#N/A

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.EXC returns the #NUM! error value." The range D20:D25 is deliberately empty: no setup_cells value is written anywhere inside it, which is the entire point of the case (see scripts/check_test_setup_refs.py, which accepts an unset reference only when the case says in so many words that it is testing a blank).; MISMATCH vs expected: expected '#NUM!', got '#N/A'
PERCENTRANK.EXC Google Sheets

=PERCENTRANK.EXC(D20:D25,7)

Actual result
#N/A

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.EXC returns the #NUM! error value." The range D20:D25 is deliberately empty: no setup_cells value is written anywhere inside it, which is the entire point of the case (see scripts/check_test_setup_refs.py, which accepts an unset reference only when the case says in so many words that it is testing a blank).; MISMATCH vs expected: expected '#NUM!', got '#N/A'
PERCENTRANK.EXC LibreOffice Calc

=PERCENTRANK.EXC(D20:D25,7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.EXC returns the #NUM! error value." The range D20:D25 is deliberately empty: no setup_cells value is written anywhere inside it, which is the entire point of the case (see scripts/check_test_setup_refs.py, which accepts an unset reference only when the case says in so many words that it is testing a blank).; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTRANK.EXC Google Sheets

=PERCENTRANK.EXC(A2:A10,7,0)

Actual result
0.7

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If significance < 1, PERCENTRANK.EXC returns the #NUM! error value." OpenFormula 1.3 section 6.18.58 states the same constraint for its PERCENTRANK ("INT(Significance) = Significance; Significance >= 1").; MISMATCH vs expected: expected '#NUM!', got 0.7
PERCENTRANK.EXC LibreOffice Calc

=PERCENTRANK.EXC(A2:A10,7,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If significance < 1, PERCENTRANK.EXC returns the #NUM! error value." OpenFormula 1.3 section 6.18.58 states the same constraint for its PERCENTRANK ("INT(Significance) = Significance; Significance >= 1").; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTRANK.INC Google Sheets

=PERCENTRANK.INC(A2:A11,4)

Actual result
0.556

Documented / expected
0.555

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft publishes =PERCENTRANK.INC(A2:A11,4) = 0.555. THIS IS THE SHARPEST CASE IN THE FILE. Five of the ten values are below 4, so the exact rank is 5/9 = 0.55555... To three significant digits that is 0.555 if the significance argument TRUNCATES and 0.556 if it ROUNDS, and Microsoft publishes 0.555 -- so the documented behaviour is truncation. Microsoft's next row is the same test again in the other direction: =PERCENTRANK.INC(A2:A11,8) = 0.666, where 6/9 = 0.6666... truncates to 0.666 and would round to 0.667. An engine that rounds instead of truncating produces a plausible-looking number that differs from Excel in the third decimal on the most ordinary inputs imaginable, and only a case whose exact value is a repeating decimal can see it. EXECUTED RESULT -- A SILENT WRONG ANSWER, AND THE HEADLINE FINDING OF THIS BATCH: LibreOffice returns 0.556 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents and publishes 0.555. LibreOffice ROUNDS the result to the significance digits; Excel TRUNCATES it. Nothing errors, nothing warns, and the answer is wrong in the third decimal on the most ordinary input imaginable -- a percentile rank of a small integer list. The companion case in this file (rank of 8, exact value 6/9) shows the same split, 0.667 against Microsoft's published 0.666, and PERCENTRANK.EXC's significance-1 row shows it a third time, 0.4 against Microsoft's published 0.3. The corpus's legacy PERCENTRANK file never caught this because every value it asserts is exact at three digits.; MISMATCH vs expected: expected 0.555, got 0.556
PERCENTRANK.INC LibreOffice Calc

=PERCENTRANK.INC(A2:A11,4)

Actual result
0.556

Documented / expected
0.555

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft publishes =PERCENTRANK.INC(A2:A11,4) = 0.555. THIS IS THE SHARPEST CASE IN THE FILE. Five of the ten values are below 4, so the exact rank is 5/9 = 0.55555... To three significant digits that is 0.555 if the significance argument TRUNCATES and 0.556 if it ROUNDS, and Microsoft publishes 0.555 -- so the documented behaviour is truncation. Microsoft's next row is the same test again in the other direction: =PERCENTRANK.INC(A2:A11,8) = 0.666, where 6/9 = 0.6666... truncates to 0.666 and would round to 0.667. An engine that rounds instead of truncating produces a plausible-looking number that differs from Excel in the third decimal on the most ordinary inputs imaginable, and only a case whose exact value is a repeating decimal can see it. EXECUTED RESULT -- A SILENT WRONG ANSWER, AND THE HEADLINE FINDING OF THIS BATCH: LibreOffice returns 0.556 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents and publishes 0.555. LibreOffice ROUNDS the result to the significance digits; Excel TRUNCATES it. Nothing errors, nothing warns, and the answer is wrong in the third decimal on the most ordinary input imaginable -- a percentile rank of a small integer list. The companion case in this file (rank of 8, exact value 6/9) shows the same split, 0.667 against Microsoft's published 0.666, and PERCENTRANK.EXC's significance-1 row shows it a third time, 0.4 against Microsoft's published 0.3. The corpus's legacy PERCENTRANK file never caught this because every value it asserts is exact at three digits.; MISMATCH vs expected: expected 0.555, got 0.556
PERCENTRANK.INC Google Sheets

=PERCENTRANK.INC(A2:A11,8)

Actual result
0.667

Documented / expected
0.666

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft publishes =PERCENTRANK.INC(A2:A11,8) = 0.666. Six of the ten values are below 8, so the exact rank is 6/9 = 0.66666..., truncated to three significant digits by the default significance: 0.666, not 0.667. Asserted alongside the 5/9 case because the two together make the truncation reading unambiguous -- a single repeating-decimal row could be dismissed as a typo on Microsoft's page, two cannot. EXECUTED RESULT: LibreOffice returns 0.667 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, against Microsoft's published 0.666. The second of three demonstrations in this batch that LibreOffice rounds where Excel truncates; see the 5/9 case above.; MISMATCH vs expected: expected 0.666, got 0.667
PERCENTRANK.INC LibreOffice Calc

=PERCENTRANK.INC(A2:A11,8)

Actual result
0.667

Documented / expected
0.666

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft publishes =PERCENTRANK.INC(A2:A11,8) = 0.666. Six of the ten values are below 8, so the exact rank is 6/9 = 0.66666..., truncated to three significant digits by the default significance: 0.666, not 0.667. Asserted alongside the 5/9 case because the two together make the truncation reading unambiguous -- a single repeating-decimal row could be dismissed as a typo on Microsoft's page, two cannot. EXECUTED RESULT: LibreOffice returns 0.667 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, against Microsoft's published 0.666. The second of three demonstrations in this batch that LibreOffice rounds where Excel truncates; see the 5/9 case above.; MISMATCH vs expected: expected 0.666, got 0.667
PERCENTRANK.INC Excel for the web

=PERCENTRANK.INC(D20:D25,2)

Actual result
#N/A

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.INC returns the #NUM! error value." D20:D25 is deliberately empty; nothing is written into it by design.; MISMATCH vs expected: expected '#NUM!', got '#N/A'
PERCENTRANK.INC Google Sheets

=PERCENTRANK.INC(D20:D25,2)

Actual result
#N/A

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.INC returns the #NUM! error value." D20:D25 is deliberately empty; nothing is written into it by design.; MISMATCH vs expected: expected '#NUM!', got '#N/A'
PERCENTRANK.INC LibreOffice Calc

=PERCENTRANK.INC(D20:D25,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If array is empty, PERCENTRANK.INC returns the #NUM! error value." D20:D25 is deliberately empty; nothing is written into it by design.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERCENTRANK.INC Google Sheets

=PERCENTRANK.INC(A2:A11,2,0)

Actual result
0.333

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If significance < 1, PERCENTRANK.INC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got 0.333
PERCENTRANK.INC LibreOffice Calc

=PERCENTRANK.INC(A2:A11,2,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If significance < 1, PERCENTRANK.INC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERMUT LibreOffice Calc

=PERMUT(2,3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If number < number_chosen, PERMUT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PERMUT Excel for the web

=PERMUT(0,0)

Actual result
1

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Microsoft documents: "If number <= 0 or if number_chosen < 0, PERMUT returns the #NUM! error value." Zero is the boundary the <= includes, so PERMUT(0,0) is an error even though the empty arrangement of an empty set is mathematically 1 -- and note that PERMUTATIONA, the sibling function, documents the opposite treatment of the same input. That disagreement between two Microsoft pages is itself worth pinning. EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 1 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM!. Mathematically 1 is defensible -- there is exactly one arrangement of nothing -- but it is not what Microsoft's page specifies, and the disagreement is invisible: no error, no warning, just a number where Excel gives an error. Note that LibreOffice is here MORE permissive than Excel, the opposite direction from most of this batch's divergences.; MISMATCH vs expected: expected '#NUM!', got 1
PERMUT Google Sheets

=PERMUT(0,0)

Actual result
1

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If number <= 0 or if number_chosen < 0, PERMUT returns the #NUM! error value." Zero is the boundary the <= includes, so PERMUT(0,0) is an error even though the empty arrangement of an empty set is mathematically 1 -- and note that PERMUTATIONA, the sibling function, documents the opposite treatment of the same input. That disagreement between two Microsoft pages is itself worth pinning. EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 1 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM!. Mathematically 1 is defensible -- there is exactly one arrangement of nothing -- but it is not what Microsoft's page specifies, and the disagreement is invisible: no error, no warning, just a number where Excel gives an error. Note that LibreOffice is here MORE permissive than Excel, the opposite direction from most of this batch's divergences.; MISMATCH vs expected: expected '#NUM!', got 1
PERMUT LibreOffice Calc

=PERMUT(0,0)

Actual result
1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If number <= 0 or if number_chosen < 0, PERMUT returns the #NUM! error value." Zero is the boundary the <= includes, so PERMUT(0,0) is an error even though the empty arrangement of an empty set is mathematically 1 -- and note that PERMUTATIONA, the sibling function, documents the opposite treatment of the same input. That disagreement between two Microsoft pages is itself worth pinning. EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 1 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM!. Mathematically 1 is defensible -- there is exactly one arrangement of nothing -- but it is not what Microsoft's page specifies, and the disagreement is invisible: no error, no warning, just a number where Excel gives an error. Note that LibreOffice is here MORE permissive than Excel, the opposite direction from most of this batch's divergences.; MISMATCH vs expected: expected '#NUM!', got 1
PERMUTATIONA Excel for the web

=PERMUTATIONA(0,1)

Actual result
0

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Microsoft documents: "If numeric arguments are values that are not valid, for example, when the total number is zero (0) and the chosen number is larger than zero (0), PERMUTATIONA returns the #NUM! error value." This is the page's own worked-out example of an invalid argument, quoted exactly. EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 0 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM! for exactly this input (Microsoft names it as its own example of an invalid argument). 0^1 = 0 is what the bare formula gives, so LibreOffice has applied the equation without the guard the page describes. Together with PERMUT(0,0) returning 1 above, this shows the same pattern twice in one sibling pair: LibreOffice evaluates the closed form where Excel raises the documented error.; MISMATCH vs expected: expected '#NUM!', got 0
PERMUTATIONA LibreOffice Calc

=PERMUTATIONA(0,1)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If numeric arguments are values that are not valid, for example, when the total number is zero (0) and the chosen number is larger than zero (0), PERMUTATIONA returns the #NUM! error value." This is the page's own worked-out example of an invalid argument, quoted exactly. EXECUTED RESULT -- A SILENT WRONG ANSWER: LibreOffice returns 0 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, where Excel documents #NUM! for exactly this input (Microsoft names it as its own example of an invalid argument). 0^1 = 0 is what the bare formula gives, so LibreOffice has applied the equation without the guard the page describes. Together with PERMUT(0,0) returning 1 above, this shows the same pattern twice in one sibling pair: LibreOffice evaluates the closed form where Excel raises the documented error.; MISMATCH vs expected: expected '#NUM!', got 0
PERMUTATIONA Google Sheets

=PERMUTATIONA(0,0)

Actual result
#NUM!

Documented / expected
1

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

OpenFormula 1.3 section 6.18.60 is explicit: "The result is 1 if Total = 0 and Chosen = 0, otherwise the result is Total^Chosen." Microsoft's page does not print this row but its error clause is consistent with it -- it names an error only "when the total number is zero (0) and the chosen number is larger than zero (0)", which pointedly does not cover chosen = 0. Note this is the exact input on which PERMUT is documented to return #NUM!, so the two sibling functions are specified to disagree here and this corpus asserts both.; MISMATCH vs expected: expected 1, got '#NUM!'
PHONETIC Google Sheets

=PHONETIC((A2,C2))

Actual result
#ERROR!

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents: "If the reference is a range of nonadjacent cells, the #N/A error value is returned." This is the ONLY behaviour of PHONETIC this corpus can assert a value for, and that is why it is the only asserted case in this file. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/phonetic-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). LibreOffice has no PHONETIC function at all, so the two probe cases in this file return #NAME? as well -- which is the only reading of them the corpus offers: they assert nothing about a value, and here they record an absence rather than a difference.; MISMATCH vs expected: expected '#N/A', got '#ERROR!'; NOTE: #ERROR! is Google Sheets' parse-failure error (no Excel equivalent); it means Sheets could not parse the formula, which is not the same as #NAME?
PHONETIC LibreOffice Calc

=PHONETIC((A2,C2))

Actual result
#NAME?

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents: "If the reference is a range of nonadjacent cells, the #N/A error value is returned." This is the ONLY behaviour of PHONETIC this corpus can assert a value for, and that is why it is the only asserted case in this file. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/phonetic-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). LibreOffice has no PHONETIC function at all, so the two probe cases in this file return #NAME? as well -- which is the only reading of them the corpus offers: they assert nothing about a value, and here they record an absence rather than a difference.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
POISSON LibreOffice Calc

=POISSON(A2,-5,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If mean < 0, POISSON returns the #NUM! error value." Asserted separately from the negative-x case because the two are separate sentences on the page and an engine can guard one and not the other. Note Microsoft permits mean = 0 while OpenFormula 1.3 section 6.18.62 requires lambda > 0 -- a specification difference this corpus deliberately does not test, since the two sources disagree about what the right answer is.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
POISSON LibreOffice Calc

=POISSON(-1,A3,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

Microsoft documents: "If x < 0, POISSON returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
POISSON.DIST LibreOffice Calc

=POISSON.DIST(A2,-5,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If mean < 0, POISSON.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
POISSON.DIST LibreOffice Calc

=POISSON.DIST(-1,A3,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If x < 0, POISSON.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
POW Excel for the web

=POW(A2,B2)

Actual result
#NAME?

Documented / expected
81

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived; cells chosen by this corpus, since the page names A2/B2 without populating them. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 81, got '#NAME?'
POW LibreOffice Calc

=POW(A2,B2)

Actual result
#NAME?

Documented / expected
81

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived; cells chosen by this corpus, since the page names A2/B2 without populating them. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 81, got '#NAME?'
POW Excel for the web

=POW(4,0.5)

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Google's Sample Usage prints POW(4,0.5) with no result; 2 is DERIVED from the page's definition, "Returns a number raised to a power", i.e. the positive square root of 4. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 2, got '#NAME?'
POW LibreOffice Calc

=POW(4,0.5)

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Google's Sample Usage prints POW(4,0.5) with no result; 2 is DERIVED from the page's definition, "Returns a number raised to a power", i.e. the positive square root of 4. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected 2, got '#NAME?'
POW Excel for the web

=POW(2,5)

Actual result
#NAME?

Documented / expected
32

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

Derived from the same definition; the page publishes no results. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 32, got '#NAME?'
POW LibreOffice Calc

=POW(2,5)

Actual result
#NAME?

Documented / expected
32

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

Derived from the same definition; the page publishes no results. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 32, got '#NAME?'
POW Excel for the web

=POW(2,5)-POWER(2,5)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant. The page states "POW is equivalent to the POWER function." Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 0, got '#NAME?'
POW LibreOffice Calc

=POW(2,5)-POWER(2,5)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant. The page states "POW is equivalent to the POWER function." Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected 0, got '#NAME?'
POW Excel for the web

=POW(-3,3)

Actual result
#NAME?

Documented / expected
-27

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

The `base` argument description is the page's only constraint: "If `base` is negative, `exponent` must be an integer." An integer exponent over a negative base is therefore the documented-legal case and -27 follows from the definition. The page names NO error value for the forbidden case (negative base, fractional exponent), so this corpus asserts nothing about it. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected -27, got '#NAME?'
POW LibreOffice Calc

=POW(-3,3)

Actual result
#NAME?

Documented / expected
-27

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

The `base` argument description is the page's only constraint: "If `base` is negative, `exponent` must be an integer." An integer exponent over a negative base is therefore the documented-legal case and -27 follows from the definition. The page names NO error value for the forbidden case (negative base, fractional exponent), so this corpus asserts nothing about it. Google's POW page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093603.; MISMATCH vs expected: expected -27, got '#NAME?'
POWER Excel for the web

=POWER(-8,1/3)

Actual result
-1.9999999999999998

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math and trigonometry

Confirmed via Microsoft's own community support: entering =(-8)^(2/3) (equivalent power semantics to POWER) returns #NUM! in Excel -- https://answers.microsoft.com/en-us/msoffice/forum/all/excel-calculating-exponential-of-negative-number/5c67eae2-5682-4daf-b3d6-50b22e9919c2 -- note that -8^(1/3) is mathematically -2 as a real cube root, but Excel's POWER/^ implementation does not special-case rational exponents with odd integer denominators and returns #NUM! for any negative base with a non-integer exponent; MISMATCH vs expected: expected '#NUM!', got -1.9999999999999998
POWER Google Sheets

=POWER(-8,1/3)

Actual result
-2

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Math and trigonometry

Confirmed via Microsoft's own community support: entering =(-8)^(2/3) (equivalent power semantics to POWER) returns #NUM! in Excel -- https://answers.microsoft.com/en-us/msoffice/forum/all/excel-calculating-exponential-of-negative-number/5c67eae2-5682-4daf-b3d6-50b22e9919c2 -- note that -8^(1/3) is mathematically -2 as a real cube root, but Excel's POWER/^ implementation does not special-case rational exponents with odd integer denominators and returns #NUM! for any negative base with a non-integer exponent; MISMATCH vs expected: expected '#NUM!', got -2
POWER LibreOffice Calc

=POWER(-8,1/3)

Actual result
-2

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Confirmed via Microsoft's own community support: entering =(-8)^(2/3) (equivalent power semantics to POWER) returns #NUM! in Excel -- https://answers.microsoft.com/en-us/msoffice/forum/all/excel-calculating-exponential-of-negative-number/5c67eae2-5682-4daf-b3d6-50b22e9919c2 -- note that -8^(1/3) is mathematically -2 as a real cube root, but Excel's POWER/^ implementation does not special-case rational exponents with odd integer denominators and returns #NUM! for any negative base with a non-integer exponent; MISMATCH vs expected: expected '#NUM!', got -2
POWER Excel for the web

=POWER(0,0)

Actual result
#NUM!

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math and trigonometry

Real Excel (the worksheet function, and even the '^' operator) has a long-standing, Microsoft-acknowledged bug -- reproduced in Excel 2007 and 2010 and still reported unresolved -- where both '=0^0' and '=POWER(0,0)' incorrectly return #NUM! instead of 1, even though VBA's own 'x = 0 ^ 0' correctly evaluates to 1 in the same product. Recording the spec/cross-engine-consensus value (1) as 'expected' here so this exact Excel quirk shows up as a flagged divergence rather than being silently baked in as 'correct' -- https://learn.microsoft.com/en-us/answers/questions/4850441/excel-formula-bug-00-gives-num; MISMATCH vs expected: expected 1, got '#NUM!'
PRICE LibreOffice Calc

=PRICE(A2,A3,A4,A5,A6,A7,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, PRICE returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICE LibreOffice Calc

=PRICE(A2,A3,A4,A5,A6,3,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If frequency is any number other than 1, 2, or 4, PRICE returns the #NUM! error value." OpenFormula 1.3 section 6.12.38 states the same constraint.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICE LibreOffice Calc

=PRICE(A3,A3,A4,A5,A6,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If settlement >= maturity, PRICE returns the #NUM! error value." Equality is the boundary the >= includes.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICE LibreOffice Calc

=PRICE(A2,A3,A4,A5,0,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If redemption <= 0, PRICE returns the #NUM! error value." Note the asymmetry with rate and yld, which are excluded only BELOW zero: a zero-coupon bond is legal, a zero-redemption bond is not.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEDISC LibreOffice Calc

=PRICEDISC(A2,A3,A4,A5,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, PRICEDISC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEDISC LibreOffice Calc

=PRICEDISC(A3,A3,A4,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If settlement >= maturity, PRICEDISC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEDISC LibreOffice Calc

=PRICEDISC(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If discount <= 0 or if redemption <= 0, PRICEDISC returns the #NUM! error value." A zero discount would price the security at par, but the documented range excludes it -- the boundary is AT zero, not below it.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEMAT LibreOffice Calc

=PRICEMAT(A2,A3,A4,A5,A6,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, PRICEMAT returns the #NUM! error value." (This page prints its basis table with the row label "0 (zero) or omitted" where its sibling pages print "0 or omitted" -- a wording difference across Microsoft's own financial pages, not a behavioural one.); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEMAT LibreOffice Calc

=PRICEMAT(A2,A3,A4,-0.061,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If rate < 0 or if yld < 0, PRICEMAT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PRICEMAT LibreOffice Calc

=PRICEMAT(A3,A3,A4,A5,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If settlement >= maturity, PRICEMAT returns the #NUM! error value." OpenFormula 1.3 section 6.12.40 states the same constraint as "Settlement < Maturity".; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PROB Google Sheets

=PROB(A3:A6,C3:C6,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If the sum of the values in prob_range is not equal to 1, PROB returns the #NUM! error value." The C column sums to 0.9. OpenFormula 1.3 section 6.18.63 states the same constraint.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PROB LibreOffice Calc

=PROB(A3:A6,C3:C6,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If the sum of the values in prob_range is not equal to 1, PROB returns the #NUM! error value." The C column sums to 0.9. OpenFormula 1.3 section 6.18.63 states the same constraint.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
PROB Excel for the web

=PROB(A3:A6,D3:D6,2)

Actual result
0.1

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Statistical

Microsoft documents: "If any value in prob_range <= 0 or if any value in prob_range > 1, PROB returns the #NUM! error value." The D column is deliberately built to sum to exactly 1 (1.5 + 0.3 + 0.1 - 0.9 = 1.0) so that the OTHER documented constraint is satisfied and only the per-value range rule can fire -- otherwise a passing result would not say which rule the engine enforced.; MISMATCH vs expected: expected '#NUM!', got 0.1
PROB Google Sheets

=PROB(A3:A6,D3:D6,2)

Actual result
0.1

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Statistical

Microsoft documents: "If any value in prob_range <= 0 or if any value in prob_range > 1, PROB returns the #NUM! error value." The D column is deliberately built to sum to exactly 1 (1.5 + 0.3 + 0.1 - 0.9 = 1.0) so that the OTHER documented constraint is satisfied and only the per-value range rule can fire -- otherwise a passing result would not say which rule the engine enforced.; MISMATCH vs expected: expected '#NUM!', got 0.1
PROB LibreOffice Calc

=PROB(A3:A6,D3:D6,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents: "If any value in prob_range <= 0 or if any value in prob_range > 1, PROB returns the #NUM! error value." The D column is deliberately built to sum to exactly 1 (1.5 + 0.3 + 0.1 - 0.9 = 1.0) so that the OTHER documented constraint is satisfied and only the per-value range rule can fire -- otherwise a passing result would not say which rule the engine enforced.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
QUARTILE.INC LibreOffice Calc

=QUARTILE.INC(A1:A3,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
QUERY Excel for the web

=SUM(QUERY(A1:E6, "select max(C) group by B", 0))

Actual result
#NAME?

Documented / expected
2200

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED. The reference documents max() as "Returns the maximum value in the column for a group" and group by as "A single row is created for each distinct combination of values in the group-by clause". The three departments' maximum salaries are Eng 1000, Marketing 800 and Sales 400, which sum to 2200 -- and the function page's own embedded example sheet runs the same query shape, `select B, MAX(D) group by B`, and prints exactly those three values. SUM is used rather than a spilled comparison precisely because neither page says whether an aggregate result carries a header row; SUM ignores a leading text cell either way. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: expected 2200, got '#NAME?'
QUERY LibreOffice Calc

=SUM(QUERY(A1:E6, "select max(C) group by B", 0))

Actual result
#NAME?

Documented / expected
2200

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED. The reference documents max() as "Returns the maximum value in the column for a group" and group by as "A single row is created for each distinct combination of values in the group-by clause". The three departments' maximum salaries are Eng 1000, Marketing 800 and Sales 400, which sum to 2200 -- and the function page's own embedded example sheet runs the same query shape, `select B, MAX(D) group by B`, and prints exactly those three values. SUM is used rather than a spilled comparison precisely because neither page says whether an aggregate result carries a header row; SUM ignores a leading text cell either way. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: expected 2200, got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select Col1 where Col2 = 'Eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

THE TWO PAGES DISAGREE HERE AND THIS CASE EXECUTES THE ONE THAT IS SPECIFIC TO SHEETS. The query language reference says identifiers in a spreadsheet are "always letters" and the string `Col1` appears nowhere on it. QUERY's own function page says, in its Examples section, "QUERY can accept either \"Col\" notation or \"A, B\" notation", and its embedded example sheet runs `select Col1 where Col2 = 'Eng'` against a sheet range and returns John, Dave, Sally -- the same three this case counts. Neither page says when the Col form becomes REQUIRED rather than merely accepted, so this corpus asserts only that it is accepted and returns the same three rows as the letter form two cases above -- which are also the three names Google's own embedded sheet prints for this exact query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select Col1 where Col2 = 'Eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

THE TWO PAGES DISAGREE HERE AND THIS CASE EXECUTES THE ONE THAT IS SPECIFIC TO SHEETS. The query language reference says identifiers in a spreadsheet are "always letters" and the string `Col1` appears nowhere on it. QUERY's own function page says, in its Examples section, "QUERY can accept either \"Col\" notation or \"A, B\" notation", and its embedded example sheet runs `select Col1 where Col2 = 'Eng'` against a sheet range and returns John, Dave, Sally -- the same three this case counts. Neither page says when the Col form becomes REQUIRED rather than merely accepted, so this corpus asserts only that it is accepted and returns the same three rows as the letter form two cases above -- which are also the three names Google's own embedded sheet prints for this exact query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A where A contains 'a'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{Dave, Sally, Dana}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED. The reference defines contains as "A substring match. whole contains part is true if part is anywhere within whole", and its own example spells out the case rule: "where name contains 'John'" matches 'John', 'John Adams', 'Long John Silver' but NOT 'john adams'. Of the six names, Dave, Sally and Dana contain a lowercase 'a'; John, Ben and Mike do not -- and Dana is the case that matters, since an uppercase-insensitive match would also pull in nothing extra here but a case-FOLDING one would not change the answer, whereas 'A' as the pattern would return only Dave and Dana's neighbours. The three are returned in source order. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'Dave', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A where A contains 'a'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{Dave, Sally, Dana}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED. The reference defines contains as "A substring match. whole contains part is true if part is anywhere within whole", and its own example spells out the case rule: "where name contains 'John'" matches 'John', 'John Adams', 'Long John Silver' but NOT 'john adams'. Of the six names, Dave, Sally and Dana contain a lowercase 'a'; John, Ben and Mike do not -- and Dana is the case that matters, since an uppercase-insensitive match would also pull in nothing extra here but a case-FOLDING one would not change the answer, whereas 'A' as the pattern would return only Dave and Dana's neighbours. The three are returned in source order. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'Dave', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A where lower(B) = 'eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED, and the pair that makes the previous case mean something. The reference's own remedy is quoted there: "String matching is case sensitive (you can use upper() or lower() scalar functions to work around that)." A lowercase literal that matches through lower() must not match without it, so this case and the one above must return the same three rows while a bare 'eng' returns none. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A where lower(B) = 'eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED, and the pair that makes the previous case mean something. The reference's own remedy is quoted there: "String matching is case sensitive (you can use upper() or lower() scalar functions to work around that)." A lowercase literal that matches through lower() must not match without it, so this case and the one above must return the same three rows while a bare 'eng' returns none. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A order by C desc limit 2 offset 1", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{Mike, Sally}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED from the one sentence that fixes the interaction: "The offset clause is used to skip a given number of first rows. If a limit clause is used, offset is applied first: for example, limit 15 offset 30 returns rows 31 through 45." Skipping one row of the descending salary order and taking two gives Mike (800) and Sally (600). ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: value mismatch: expected 'Mike', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A order by C desc limit 2 offset 1", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{Mike, Sally}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED from the one sentence that fixes the interaction: "The offset clause is used to skip a given number of first rows. If a limit clause is used, offset is applied first: for example, limit 15 offset 30 returns rows 31 through 45." Skipping one row of the descending salary order and taking two gives Mike (800) and Sally (600). ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: value mismatch: expected 'Mike', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A order by C desc limit 2", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{John, Mike}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED. The reference's order by example is `order by dept, salary desc` and its limit example is `limit 100`; the clause order used here, order by before limit, is the order the reference's own clause table mandates ("The order of the clauses must be as follows": select, where, group by, pivot, order by, limit, offset, label, format, options). Salaries descending run 1000, 800, 600, 500, 400, 350, so the first two are John and Mike. NOTE THAT `asc` IS NEVER SHOWN in the reference's order by section and no default direction is stated, which is why only the explicit `desc` form is asserted. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A order by C desc limit 2", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{John, Mike}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED. The reference's order by example is `order by dept, salary desc` and its limit example is `limit 100`; the clause order used here, order by before limit, is the order the reference's own clause table mandates ("The order of the clauses must be as follows": select, where, group by, pivot, order by, limit, offset, label, format, options). Salaries descending run 1000, 800, 600, 500, 400, 350, so the first two are John and Mike. NOTE THAT `asc` IS NEVER SHOWN in the reference's order by section and no default direction is stated, which is why only the explicit `desc` form is asserted. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select B, A where C > 700", 0)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Eng, John}, {Marketing, Mike}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED from the select clause's documented purpose: "Selects which columns to return, and IN WHAT ORDER." The rows are the two the previous case returns, so only the column order is under test; row order is unchanged because no order by clause is given. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343.; MISMATCH vs expected: value mismatch: expected 'Eng', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select B, A where C > 700", 0)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Eng, John}, {Marketing, Mike}}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED from the select clause's documented purpose: "Selects which columns to return, and IN WHAT ORDER." The rows are the two the previous case returns, so only the column order is under test; row order is unchanged because no order by clause is given. ARRAY RESULT over a check_range. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343.; MISMATCH vs expected: value mismatch: expected 'Eng', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A where C > 700", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{John, Mike}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

GOOGLE'S OWN PUBLISHED EXAMPLE, translated only in its column identifiers. The query language reference prints the query `select name where salary > 700` over this exact table and then prints its output in full: John, Mike. Here `name` is column A and `salary` is column C. ARRAY RESULT: compared over an explicit check_range in row-major order. THE DATA IS GOOGLE'S, THE COLUMN LETTERS ARE NOT. Both Google pages build their examples on the same six-employee table (John/Dave/Sally/Eng, Ben/Dana/Sales, Mike/Marketing, with salaries 1000, 500, 600, 400, 350, 800 and ages 35, 27, 30, 32, 25, 24), and this file uses it. The query language reference names its columns by the identifiers `name`, `dept`, `salary`, ... because its examples run against a data source with named columns; inside the QUERY function the identifiers are the SHEET'S column letters, which the reference states flatly: "in a Google Spreadsheet, column identifiers are the one or two character column letter (A, B, C, ...)" and "column IDs in spreadsheets are always letters; the column heading text shown in the published spreadsheet are labels, not IDs. You must use the ID, not the label, in your query string." So `salary` becomes C here and `dept` becomes B. The lunchTime, hireDate and seniorityStartTime columns are omitted: they are time and date values whose text form would put a locale into every assertion. The range is HEADERLESS and every case passes headers = 0 explicitly, rather than relying on the `headers` argument's documented fallback ("If omitted or set to -1, the value is guessed based on the content of data") -- a guess is not something to assert against. TWO GAPS IN THE DOCUMENTATION THAT SHAPED THIS FILE. (1) NEITHER PAGE STATES WHETHER A QUERY RESULT CARRIES A HEADER ROW. The function page is silent; the language reference never uses the phrase. The only primary-source evidence either way is the behaviour of the example sheet the function page embeds, where an aggregate query does emit one. Rather than assert a header row this corpus cannot cite a sentence for, the aggregate cases below are asserted through SUM and COUNTA, which are unaffected by a leading text row. (2) NEITHER PAGE NAMES ANY ERROR VALUE. There is no statement anywhere about what an invalid query, an empty result or a type-mismatched column returns, so this corpus asserts no error behaviour for QUERY at all and every case below is written to match at least one row. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A where C > 700", 0)

Actual result
{#NAME?, #NAME?}

Documented / expected
{John, Mike}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

GOOGLE'S OWN PUBLISHED EXAMPLE, translated only in its column identifiers. The query language reference prints the query `select name where salary > 700` over this exact table and then prints its output in full: John, Mike. Here `name` is column A and `salary` is column C. ARRAY RESULT: compared over an explicit check_range in row-major order. THE DATA IS GOOGLE'S, THE COLUMN LETTERS ARE NOT. Both Google pages build their examples on the same six-employee table (John/Dave/Sally/Eng, Ben/Dana/Sales, Mike/Marketing, with salaries 1000, 500, 600, 400, 350, 800 and ages 35, 27, 30, 32, 25, 24), and this file uses it. The query language reference names its columns by the identifiers `name`, `dept`, `salary`, ... because its examples run against a data source with named columns; inside the QUERY function the identifiers are the SHEET'S column letters, which the reference states flatly: "in a Google Spreadsheet, column identifiers are the one or two character column letter (A, B, C, ...)" and "column IDs in spreadsheets are always letters; the column heading text shown in the published spreadsheet are labels, not IDs. You must use the ID, not the label, in your query string." So `salary` becomes C here and `dept` becomes B. The lunchTime, hireDate and seniorityStartTime columns are omitted: they are time and date values whose text form would put a locale into every assertion. The range is HEADERLESS and every case passes headers = 0 explicitly, rather than relying on the `headers` argument's documented fallback ("If omitted or set to -1, the value is guessed based on the content of data") -- a guess is not something to assert against. TWO GAPS IN THE DOCUMENTATION THAT SHAPED THIS FILE. (1) NEITHER PAGE STATES WHETHER A QUERY RESULT CARRIES A HEADER ROW. The function page is silent; the language reference never uses the phrase. The only primary-source evidence either way is the behaviour of the example sheet the function page embeds, where an aggregate query does emit one. Rather than assert a header row this corpus cannot cite a sentence for, the aggregate cases below are asserted through SUM and COUNTA, which are unaffected by a leading text row. (2) NEITHER PAGE NAMES ANY ERROR VALUE. There is no statement anywhere about what an invalid query, an empty result or a type-mismatched column returns, so this corpus asserts no error behaviour for QUERY at all and every case below is written to match at least one row. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY Excel for the web

=QUERY(A1:E6, "select A where B = 'Eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Google

DERIVED. Three employees are in Eng. The language reference has a dedicated case-sensitivity section, quoted in full: "Identifiers and string literals are case-sensitive. All other language elements are case-insensitive." It also fixes the quoting: "A string literal should be enclosed in either single or double quotes", and single quotes are used here so the query string's own double quotes are not disturbed. The three Eng employees come back in source order, which is also exactly the output QUERY's own embedded example sheet publishes for the equivalent Col-notation query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
QUERY LibreOffice Calc

=QUERY(A1:E6, "select A where B = 'Eng'", 0)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{John, Dave, Sally}

Engine
LibreOffice Calc 25.8.7.3

Category
Google

DERIVED. Three employees are in Eng. The language reference has a dedicated case-sensitivity section, quoted in full: "Identifiers and string literals are case-sensitive. All other language elements are case-insensitive." It also fixes the quoting: "A string literal should be enclosed in either single or double quotes", and single quotes are used here so the query string's own double quotes are not disturbed. The three Eng employees come back in source order, which is also exactly the output QUERY's own embedded example sheet publishes for the equivalent Col-notation query. Google's QUERY page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093343. THE QUERY LANGUAGE IS A SEPARATE DOCUMENT AND IS CITED SEPARATELY: Google Visualization API Query Language Reference (Version 0.7), footer "Last updated 2024-07-10 UTC", read live on 2026-08-31 at https://developers.google.com/chart/interactive/docs/querylanguage. QUERY's own function page does not define the language -- it says only "Runs a Google Visualization API Query Language query across data" and links there twice. WHY THIS CASE IS A SPILLED ARRAY AND NOT A COUNTA. It was first authored as =COUNTA(QUERY(...)) so that no assumption about an output header row could enter, and the LibreOffice run showed why that was a mistake: COUNTA counts an error cell as one non-empty value, so all four builds returned 1 -- a plausible-looking NUMBER that completely masked the #NAME? underneath, and would have been published as a wrong answer rather than as an absent function. (Batch G recorded the same trap the other way round, where COUNT(TRIMRANGE(...)) returned 0 instead of propagating #NAME?.) A plain select with headers = 0 emits no header row -- QUERY's own embedded example sheet shows `select Col1 where Col2 = 'Eng'` returning exactly three names and nothing else -- so the rows can simply be asserted directly, and an unrecognised function then propagates into every cell of the check_range where it belongs.; MISMATCH vs expected: value mismatch: expected 'John', got '#NAME?'
RAWSUBTRACT Excel for the web

=ROUND(RAWSUBTRACT(0.3,0.1,0.1,0.1)*1E17,10)

Actual result
#NAME?

Documented / expected
-2.7755575616

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Mathematical

DERIVED, and this is the case the function exists for. The page's first sentence is "Subtracts a set of numbers and gives the result without eliminating small roundoff errors", and its argument-order note says "RAWSUBTRACT() processes arguments from left to right. For example, RAWSUBTRACT(1;2;3;4) calculates 1-2-3-4 or ((1-2)-3)-4 in 'natural' order." Applying that stated order to 0.3, 0.1, 0.1, 0.1 in binary64: 0.3 - 0.1 = 0.19999999999999998, minus 0.1 = 0.09999999999999998, minus 0.1 = -2.7755575615628914E-17, which is one negative unit in the last place of 0.1. Derived independently by evaluating that sequence in IEEE-754 double precision. Scaled by 1E17 for the same reason as the case above. LibreOffice's RAWSUBTRACT help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_rawsubtract.html.; MISMATCH vs expected: expected -2.7755575616, got '#NAME?'
RAWSUBTRACT Google Sheets

=ROUND(RAWSUBTRACT(0.3,0.1,0.1,0.1)*1E17,10)

Actual result
#NAME?

Documented / expected
-2.7755575616

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Mathematical

DERIVED, and this is the case the function exists for. The page's first sentence is "Subtracts a set of numbers and gives the result without eliminating small roundoff errors", and its argument-order note says "RAWSUBTRACT() processes arguments from left to right. For example, RAWSUBTRACT(1;2;3;4) calculates 1-2-3-4 or ((1-2)-3)-4 in 'natural' order." Applying that stated order to 0.3, 0.1, 0.1, 0.1 in binary64: 0.3 - 0.1 = 0.19999999999999998, minus 0.1 = 0.09999999999999998, minus 0.1 = -2.7755575615628914E-17, which is one negative unit in the last place of 0.1. Derived independently by evaluating that sequence in IEEE-754 double precision. Scaled by 1E17 for the same reason as the case above. LibreOffice's RAWSUBTRACT help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_rawsubtract.html.; MISMATCH vs expected: expected -2.7755575616, got '#NAME?'
RAWSUBTRACT Excel for the web

=ROUND(RAWSUBTRACT(0.987654321098765,0.9876543210987)*1E14,10)

Actual result
#NAME?

Documented / expected
6.5059069243

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Mathematical

LIBREOFFICE-PUBLISHED RESULT CORRECTED -- THE HELP PAGE'S ONLY NUMERIC EXAMPLE IS WRONG. The page prints: "=RAWSUBTRACT(0.987654321098765, 0.9876543210987) returns 6.53921361504217E-14". That figure does not belong to those inputs. RAWSUBTRACT's whole purpose, in the page's own words, is to subtract "without eliminating small roundoff errors", so its result is exactly the IEEE-754 double-precision difference of the two arguments, and that difference is determined entirely by the two literals -- there is nothing left for an implementation to choose. Derived independently by taking the exact decimal value of each argument as stored in a binary64 double (0.98765432109876505339940422345534898340702056884765625 and 0.98765432109869999433016118928208015859127044677734375) and subtracting them exactly: 6.50590692430341732688248157501220703125E-14. The published figure differs in the THIRD significant digit (6.539 vs 6.506), far too large to be a rounding or display artefact of the same computation, so it is a stale or mistyped constant rather than a variant of the right answer. The correct value is asserted here and the discrepancy recorded rather than buried, following this corpus's existing treatment of wrong published figures. Asserted after scaling by 1E14, because the result is of order 1E-14 and a bare ROUND() to any ordinary number of places would collapse it to zero and assert nothing at all. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's RAWSUBTRACT help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_rawsubtract.html.; MISMATCH vs expected: expected 6.5059069243, got '#NAME?'
RAWSUBTRACT Google Sheets

=ROUND(RAWSUBTRACT(0.987654321098765,0.9876543210987)*1E14,10)

Actual result
#NAME?

Documented / expected
6.5059069243

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Mathematical

LIBREOFFICE-PUBLISHED RESULT CORRECTED -- THE HELP PAGE'S ONLY NUMERIC EXAMPLE IS WRONG. The page prints: "=RAWSUBTRACT(0.987654321098765, 0.9876543210987) returns 6.53921361504217E-14". That figure does not belong to those inputs. RAWSUBTRACT's whole purpose, in the page's own words, is to subtract "without eliminating small roundoff errors", so its result is exactly the IEEE-754 double-precision difference of the two arguments, and that difference is determined entirely by the two literals -- there is nothing left for an implementation to choose. Derived independently by taking the exact decimal value of each argument as stored in a binary64 double (0.98765432109876505339940422345534898340702056884765625 and 0.98765432109869999433016118928208015859127044677734375) and subtracting them exactly: 6.50590692430341732688248157501220703125E-14. The published figure differs in the THIRD significant digit (6.539 vs 6.506), far too large to be a rounding or display artefact of the same computation, so it is a stale or mistyped constant rather than a variant of the right answer. The correct value is asserted here and the discrepancy recorded rather than buried, following this corpus's existing treatment of wrong published figures. Asserted after scaling by 1E14, because the result is of order 1E-14 and a bare ROUND() to any ordinary number of places would collapse it to zero and assert nothing at all. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's RAWSUBTRACT help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_rawsubtract.html.; MISMATCH vs expected: expected 6.5059069243, got '#NAME?'
RECEIVED LibreOffice Calc

=RECEIVED(A2,A3,A4,A5,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If basis < 0 or if basis > 4, RECEIVED returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
RECEIVED LibreOffice Calc

=RECEIVED(A3,A3,A4,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If settlement >= maturity, RECEIVED returns the #NUM! error value." OpenFormula 1.3 section 6.12.43 requires Settlement < Maturity as well.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
RECEIVED LibreOffice Calc

=RECEIVED(A2,A3,A4,0,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The second half of "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value", asserted separately because an engine can guard one argument and not the other. A zero discount is arithmetically harmless -- the formula would simply return the investment -- so an engine that computes it instead of erroring is following the arithmetic rather than the documentation.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
RECEIVED LibreOffice Calc

=RECEIVED(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Microsoft documents: "If investment <= 0 or if discount <= 0, RECEIVED returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
REDUCE LibreOffice Calc

=REDUCE(0,A1:A3,LAMBDA(a,b,a+b))

Actual result
#NAME?

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: expected 6, got '#NAME?'
REGEX Excel for the web

=ISNA(REGEX("abc","z"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED, and the one case in this file that is not published: the Expression parameter's description states "If there is no match and Replacement is not given, #N/A is returned", and the Occurrence description repeats it. This is the only place in the batch where a LibreOffice page names a specific error value, so it is the only place an error value is asserted. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected True, got False
REGEX Google Sheets

=ISNA(REGEX("abc","z"))

Actual result
False

Documented / expected
True

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

DERIVED, and the one case in this file that is not published: the Expression parameter's description states "If there is no match and Replacement is not given, #N/A is returned", and the Occurrence description repeats it. This is the only place in the batch where a LibreOffice page names a specific error value, so it is the only place an error value is asserted. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected True, got False
REGEX Excel for the web

=REGEX("axbxcxd","(.)x","$1y",2)

Actual result
#NAME?

Documented / expected
axbycxd

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("axbxcxd";"(.)x";"$1y";2) returns "axbycxd", the second match of "(.)x" (i.e. "bx") replaced with the captured group of one character (i.e. "b") followed by "y"." This is the case that exercises the documented "references to capture groups" in the Replacement parameter, and the $1 syntax is ICU's. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'axbycxd', got '#NAME?'
REGEX Google Sheets

=REGEX("axbxcxd","(.)x","$1y",2)

Actual result
#NAME?

Documented / expected
axbycxd

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("axbxcxd";"(.)x";"$1y";2) returns "axbycxd", the second match of "(.)x" (i.e. "bx") replaced with the captured group of one character (i.e. "b") followed by "y"." This is the case that exercises the documented "references to capture groups" in the Replacement parameter, and the $1 syntax is ICU's. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'axbycxd', got '#NAME?'
REGEX Excel for the web

=REGEX("123456ABCDEF","[126]","","g")

Actual result
#NAME?

Documented / expected
345ABCDEF

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[126]";"";"g") returns "345ABCDEF", where any occurrence of "1", "2" or "6" is replaced by the empty string, thus deleted." LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected '345ABCDEF', got '#NAME?'
REGEX Google Sheets

=REGEX("123456ABCDEF","[126]","","g")

Actual result
#NAME?

Documented / expected
345ABCDEF

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[126]";"";"g") returns "345ABCDEF", where any occurrence of "1", "2" or "6" is replaced by the empty string, thus deleted." LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected '345ABCDEF', got '#NAME?'
REGEX Excel for the web

=REGEX("axbxcxd",".x",,2)

Actual result
#NAME?

Documented / expected
bx

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("axbxcxd";".x";;2) returns "bx", the second match of ".x"." The empty third argument is the page's own -- Replacement omitted turns the call from a replace into an extract, per "Occurrence: ... Number to indicate which match of Expression in Text is to be extracted or replaced." It is written here exactly as published, empty argument included. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'bx', got '#NAME?'
REGEX Google Sheets

=REGEX("axbxcxd",".x",,2)

Actual result
#NAME?

Documented / expected
bx

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("axbxcxd";".x";;2) returns "bx", the second match of ".x"." The empty third argument is the page's own -- Replacement omitted turns the call from a replace into an extract, per "Occurrence: ... Number to indicate which match of Expression in Text is to be extracted or replaced." It is written here exactly as published, empty argument included. LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'bx', got '#NAME?'
REGEX Excel for the web

=REGEX("123456ABCDEF","[:digit:]","Z","g")

Actual result
#NAME?

Documented / expected
ZZZZZZABCDEF

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[:digit:]";"Z";"g") returns "ZZZZZZABCDEF", where all digits were replaced by "Z"." Matches the documented Flags parameter: "'g' replaces all matches of Expression in Text, not extracted." LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'ZZZZZZABCDEF', got '#NAME?'
REGEX Google Sheets

=REGEX("123456ABCDEF","[:digit:]","Z","g")

Actual result
#NAME?

Documented / expected
ZZZZZZABCDEF

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[:digit:]";"Z";"g") returns "ZZZZZZABCDEF", where all digits were replaced by "Z"." Matches the documented Flags parameter: "'g' replaces all matches of Expression in Text, not extracted." LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'ZZZZZZABCDEF', got '#NAME?'
REGEX Excel for the web

=REGEX("123456ABCDEF","[:digit:]","Z")

Actual result
#NAME?

Documented / expected
Z23456ABCDEF

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[:digit:]";"Z") returns "Z23456ABCDEF", where the first match of a digit is replaced by "Z"." This page is the best-documented in the whole batch -- five worked examples with printed results -- so five of the six cases here are published rather than derived. THE REGEX FLAVOUR IS PART OF THE FINDING AND THE PAGE STATES IT: "Expression: A text representing the regular expression, using ICU regular expressions." That is a different flavour from the PCRE2 that Microsoft's REGEXEXTRACT/REGEXREPLACE/REGEXTEST pages specify, which is why this corpus keeps LibreOffice's REGEX and Microsoft's REGEX* trio as separate functions rather than treating either as the other's alias. Note also that the bracket expression published here is "[:digit:]" -- a bracketed set of the six characters : d g i t, not the POSIX class [[:digit:]] -- which happens to match the digits in this input anyway; the value asserted is the one the page publishes for the expression the page publishes. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'Z23456ABCDEF', got '#NAME?'
REGEX Google Sheets

=REGEX("123456ABCDEF","[:digit:]","Z")

Actual result
#NAME?

Documented / expected
Z23456ABCDEF

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Text

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=REGEX("123456ABCDEF";"[:digit:]";"Z") returns "Z23456ABCDEF", where the first match of a digit is replaced by "Z"." This page is the best-documented in the whole batch -- five worked examples with printed results -- so five of the six cases here are published rather than derived. THE REGEX FLAVOUR IS PART OF THE FINDING AND THE PAGE STATES IT: "Expression: A text representing the regular expression, using ICU regular expressions." That is a different flavour from the PCRE2 that Microsoft's REGEXEXTRACT/REGEXREPLACE/REGEXTEST pages specify, which is why this corpus keeps LibreOffice's REGEX and Microsoft's REGEX* trio as separate functions rather than treating either as the other's alias. Note also that the bracket expression published here is "[:digit:]" -- a bracketed set of the six characters : d g i t, not the POSIX class [[:digit:]] -- which happens to match the digits in this input anyway; the value asserted is the one the page publishes for the expression the page publishes. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's REGEX help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_regex.html.; MISMATCH vs expected: expected 'Z23456ABCDEF', got '#NAME?'
REGEXEXTRACT Excel for the web

=REGEXEXTRACT("abcDEF","[A-Z]+",0,1)

Actual result
abcDEF

Documented / expected
abc

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (the default) and "1: Case insensitive". With matching made case-insensitive, [A-Z]+ also matches lower-case letters, so the FIRST match in "abcDEF" is the leading run "abc" -- not "DEF", which is what the same call returns with the default sensitivity. The two readings give different answers on the same string, which is what makes this a real test of the argument rather than a decoration.; MISMATCH vs expected: expected 'abc', got 'abcDEF'
REGEXEXTRACT Google Sheets

=REGEXEXTRACT("abcDEF","[A-Z]+",0,1)

Actual result
#N/A

Documented / expected
abc

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (the default) and "1: Case insensitive". With matching made case-insensitive, [A-Z]+ also matches lower-case letters, so the FIRST match in "abcDEF" is the leading run "abc" -- not "DEF", which is what the same call returns with the default sensitivity. The two readings give different answers on the same string, which is what makes this a real test of the argument rather than a decoration.; MISMATCH vs expected: expected 'abc', got '#N/A'
REGEXEXTRACT LibreOffice Calc

=REGEXEXTRACT("abcDEF","[A-Z]+",0,1)

Actual result
#NAME?

Documented / expected
abc

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (the default) and "1: Case insensitive". With matching made case-insensitive, [A-Z]+ also matches lower-case letters, so the FIRST match in "abcDEF" is the leading run "abc" -- not "DEF", which is what the same call returns with the default sensitivity. The two readings give different answers on the same string, which is what makes this a real test of the argument rather than a decoration.; MISMATCH vs expected: expected 'abc', got '#NAME?'
REGEXEXTRACT Google Sheets

=COUNTA(REGEXEXTRACT(A2,"[A-Z][a-z]+",1))

Actual result
1

Documented / expected
2

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's Example 1 runs the same data a second time with return_mode 1, documented as "1: Return all strings that match the pattern as an array". "DylanWilliams" contains exactly two capitalised words, so the array has two elements. The result is wrapped in COUNTA DELIBERATELY: Microsoft's page shows the array only as a screenshot and never states whether it spills down a column or across a row, so asserting INDEX(...,2) would be asserting an orientation this corpus cannot source. COUNTA is orientation-blind and still distinguishes return_mode 1 from return_mode 0, which returns a single string and would count 1. EXECUTED RESULT -- READ THIS ONE CAREFULLY: LibreOffice returns 1 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, not #NAME?. That is NOT a partially-working REGEXEXTRACT. COUNTA counts non-empty cells, and an error value is not empty, so COUNTA(#NAME?) is 1: the wrapper this case uses to avoid asserting an array orientation also swallows the #NAME? underneath it. The other four cases in this file show the raw #NAME?, and the function is absent under all four spellings probed. The count of 1 here is an artefact of the wrapper, not evidence of anything the engine computed.; MISMATCH vs expected: expected 2, got 1
REGEXEXTRACT LibreOffice Calc

=COUNTA(REGEXEXTRACT(A2,"[A-Z][a-z]+",1))

Actual result
1

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's Example 1 runs the same data a second time with return_mode 1, documented as "1: Return all strings that match the pattern as an array". "DylanWilliams" contains exactly two capitalised words, so the array has two elements. The result is wrapped in COUNTA DELIBERATELY: Microsoft's page shows the array only as a screenshot and never states whether it spills down a column or across a row, so asserting INDEX(...,2) would be asserting an orientation this corpus cannot source. COUNTA is orientation-blind and still distinguishes return_mode 1 from return_mode 0, which returns a single string and would count 1. EXECUTED RESULT -- READ THIS ONE CAREFULLY: LibreOffice returns 1 on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, not #NAME?. That is NOT a partially-working REGEXEXTRACT. COUNTA counts non-empty cells, and an error value is not empty, so COUNTA(#NAME?) is 1: the wrapper this case uses to avoid asserting an array orientation also swallows the #NAME? underneath it. The other four cases in this file show the raw #NAME?, and the function is absent under all four spellings probed. The count of 1 here is an artefact of the wrapper, not evidence of anything the engine computed.; MISMATCH vs expected: expected 2, got 1
REGEXEXTRACT Google Sheets

=REGEXEXTRACT("2024-08-31","-([0-9]{2})-",2)

Actual result
#N/A

Documented / expected
08

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents return_mode "2: Return capturing groups from the first match as an array" and explains: "Capturing groups are parts of a regex pattern surrounded by parentheses '(...)'. They allow you to return separate parts of a single match individually." The pattern here has exactly ONE group, so the returned array has one element and coerces to the scalar string "08" -- chosen that way so the case tests the group extraction without depending on how a multi-element array is laid out. The match itself is "-08-" and the group inside it is "08". Note the documented remark that "REGEXEXTRACT always return text values" (Microsoft's own grammar): the expected value is the two-character STRING "08", not the number 8.; MISMATCH vs expected: expected '08', got '#N/A'
REGEXEXTRACT LibreOffice Calc

=REGEXEXTRACT("2024-08-31","-([0-9]{2})-",2)

Actual result
#NAME?

Documented / expected
08

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents return_mode "2: Return capturing groups from the first match as an array" and explains: "Capturing groups are parts of a regex pattern surrounded by parentheses '(...)'. They allow you to return separate parts of a single match individually." The pattern here has exactly ONE group, so the returned array has one element and coerces to the scalar string "08" -- chosen that way so the case tests the group extraction without depending on how a multi-element array is laid out. The match itself is "-08-" and the group inside it is "08". Note the documented remark that "REGEXEXTRACT always return text values" (Microsoft's own grammar): the expected value is the two-character STRING "08", not the number 8.; MISMATCH vs expected: expected '08', got '#NAME?'
REGEXEXTRACT LibreOffice Calc

=REGEXEXTRACT(A2,"[A-Z][a-z]+")

Actual result
#NAME?

Documented / expected
Dylan

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's Example 1 is exactly this: the data "DylanWilliams" with the pattern "[A-Z][a-z]+", described as "Extract names based on capital letters". DERIVATION: the pattern matches one upper-case letter followed by one or more lower-case letters; scanning from the left, the first such run in "DylanWilliams" is "Dylan" (it stops at the W, which is not in [a-z]). With return_mode omitted the documented behaviour is "0: Return the first string that matches the pattern", so the answer is the single string "Dylan". REGEX FLAVOUR, AS DOCUMENTED: "All regular expressions for this function, as well as REGEXTEST and REGEXREPLACE use the PCRE2 'flavor' of regex" -- Microsoft's own sentence, printed on all three REGEX pages. This corpus's patterns are deliberately confined to character classes, quantifiers and anchors, which mean the same thing in PCRE2, in RE2 and in the ICU flavour LibreOffice's own REGEX function documents, so a difference between engines here is a difference about the FUNCTION, not about dialect corners. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/regexextract-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed before the run (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). None of the three Excel REGEX functions exists in any LibreOffice release tested here. LibreOffice is not without regular expressions -- its own REGEX(Text; Expression [; [Replacement] [; Flags|Occurrence]]) is documented and works -- but it is a different function with a different name, a different argument shape and a different flavour (ICU, against the PCRE2 Microsoft's pages name), so a workbook using REGEXTEST or REGEXEXTRACT does not open and run; it has to be rewritten.; MISMATCH vs expected: expected 'Dylan', got '#NAME?'
REGEXEXTRACT LibreOffice Calc

=REGEXEXTRACT("abc","[0-9]+")

Actual result
#NAME?

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Text

There is no digit in "abc", so nothing matches. #N/A -- "not available" -- is Excel's error for a lookup that found nothing, and it is what this function family returns on no match; the value is asserted here so that an engine returning an empty string, a zero or #VALUE! instead is recorded as different.; MISMATCH vs expected: expected '#N/A', got '#NAME?'
REGEXMATCH Excel for the web

=REGEXMATCH("Spreadsheets", "^S.r$")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The companion to the case above, and the reason it is here: with ^ and $ the pattern must consume the whole string, and "Spreadsheets" is twelve characters, not three. If both this case and the unanchored one return the same answer, the engine is not honouring anchors. Anchors are RE2 syntax; the page itself says nothing about them. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXMATCH LibreOffice Calc

=REGEXMATCH("Spreadsheets", "^S.r$")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The companion to the case above, and the reason it is here: with ^ and $ the pattern must consume the whole string, and "Spreadsheets" is twelve characters, not three. If both this case and the unanchored one return the same answer, the engine is not honouring anchors. Anchors are RE2 syntax; the page itself says nothing about them. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXMATCH Excel for the web

=REGEXMATCH("ABC", "(?i)abc")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The pair that makes the previous case mean something: (?i) is RE2's inline flag for case-insensitive matching, from the linked syntax reference. Google's page mentions neither the flag nor the default. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXMATCH LibreOffice Calc

=REGEXMATCH("ABC", "(?i)abc")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The pair that makes the previous case mean something: (?i) is RE2's inline flag for case-insensitive matching, from the linked syntax reference. Google's page mentions neither the flag nor the default. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXMATCH Excel for the web

=REGEXMATCH("Spreadsheets", "S.r")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page prints REGEXMATCH("Spreadsheets", "S.r") and NO result, so TRUE is DERIVED. "S.r" matches the substring "Spr" at the start of "Spreadsheets". THE PAGE NEVER SAYS WHETHER THE MATCH IS ANCHORED OR A SUBSTRING SEARCH -- there is no such sentence on it. Two things settle it: RE2's linked syntax reference defines an unanchored match, and the page would not print this pattern as its one and only sample if the answer were FALSE. That reasoning is recorded here rather than presented as a Google claim. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXMATCH LibreOffice Calc

=REGEXMATCH("Spreadsheets", "S.r")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page prints REGEXMATCH("Spreadsheets", "S.r") and NO result, so TRUE is DERIVED. "S.r" matches the substring "Spr" at the start of "Spreadsheets". THE PAGE NEVER SAYS WHETHER THE MATCH IS ANCHORED OR A SUBSTRING SEARCH -- there is no such sentence on it. Two things settle it: RE2's linked syntax reference defines an unanchored match, and the page would not print this pattern as its one and only sample if the answer were FALSE. That reasoning is recorded here rather than presented as a Google claim. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXMATCH Excel for the web

=REGEXMATCH("ABC", "abc")

Actual result
#NAME?

Documented / expected
False

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

THE PAGE SAYS NOTHING ABOUT CASE SENSITIVITY -- searched for twice, on two separate fetches; there is no such sentence. FALSE is derived from RE2's linked syntax reference, under which matching is case sensitive unless a flag says otherwise. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXMATCH LibreOffice Calc

=REGEXMATCH("ABC", "abc")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Text

THE PAGE SAYS NOTHING ABOUT CASE SENSITIVITY -- searched for twice, on two separate fetches; there is no such sentence. FALSE is derived from RE2's linked syntax reference, under which matching is case sensitive unless a flag says otherwise. THE AUTHORITY FOR REGEX SEMANTICS ON THIS PAGE IS A LINK, AND IT IS CITED AS ONE. The page states: "Google products use RE2 for regular expressions. Google Sheets supports RE2 except Unicode character class matching", and links the syntax to https://github.com/google/re2/wiki/syntax. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXMATCH Excel for the web

=REGEXMATCH(TEXT(123,"0"), "2")

Actual result
#NAME?

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page states: "This function only works with text (not numbers) as input and returns a logical value, i.e. TRUE or FALSE, as output. If numbers are used as input, convert them to text using the TEXT function." It names NO error value for the rejected numeric case, so this corpus asserts nothing about REGEXMATCH(123, ...) and instead executes the workaround the page prescribes. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXMATCH LibreOffice Calc

=REGEXMATCH(TEXT(123,"0"), "2")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page states: "This function only works with text (not numbers) as input and returns a logical value, i.e. TRUE or FALSE, as output. If numbers are used as input, convert them to text using the TEXT function." It names NO error value for the rejected numeric case, so this corpus asserts nothing about REGEXMATCH(123, ...) and instead executes the workaround the page prescribes. Google's REGEXMATCH page, read live on 2026-08-31 at https://support.google.com/docs/answer/3098292.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXREPLACE Google Sheets

=REGEXREPLACE("Apple apple","apple","X",0,1)

Actual result
#N/A

Documented / expected
X X

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (default) and "1: Case insensitive". With 1, the literal pattern "apple" matches both "Apple" and "apple", so both are replaced and the answer is "X X"; with the default it would be "Apple X". Note the fifth argument requires the fourth, so occurrence is passed explicitly as its documented default of 0.; MISMATCH vs expected: expected 'X X', got '#N/A'
REGEXREPLACE LibreOffice Calc

=REGEXREPLACE("Apple apple","apple","X",0,1)

Actual result
#NAME?

Documented / expected
X X

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (default) and "1: Case insensitive". With 1, the literal pattern "apple" matches both "Apple" and "apple", so both are replaced and the answer is "X X"; with the default it would be "Apple X". Note the fifth argument requires the fourth, so occurrence is passed explicitly as its documented default of 0.; MISMATCH vs expected: expected 'X X', got '#NAME?'
REGEXREPLACE LibreOffice Calc

=REGEXREPLACE("a1b2c3","[0-9]","#")

Actual result
#NAME?

Documented / expected
a#b#c#

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents: "By default, occurrence is 0, which replaces all instances." All three digits in "a1b2c3" are replaced, giving "a#b#c#" -- an engine that replaced only the first would return "a#b2c3", which is the single most likely difference between two implementations of this function and is why the default is asserted explicitly.; MISMATCH vs expected: expected 'a#b#c#', got '#NAME?'
REGEXREPLACE LibreOffice Calc

=REGEXREPLACE(A2,"[0-9]+-","***-")

Actual result
#NAME?

Documented / expected
(378) ***-4195

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's Example 1 uses exactly this pattern -- "Use REGEXREPLACE to anonymize phone numbers by replacing their first 3 digits with ***, using pattern [0-9]+-" -- over a block of names and numbers. DERIVATION on one line of that data: "[0-9]+-" matches a run of digits followed by a hyphen. In "(378) 555-4195" the only such run is "555-" (the "378" is followed by ")", and "4195" ends the string), so it alone is replaced by "***-", giving "(378) ***-4195". REGEX FLAVOUR, AS DOCUMENTED: "All regular expressions for this function, as well as REGEXTEST and REGEXREPLACE use the PCRE2 'flavor' of regex" -- Microsoft's own sentence, printed on all three REGEX pages. This corpus's patterns are deliberately confined to character classes, quantifiers and anchors, which mean the same thing in PCRE2, in RE2 and in the ICU flavour LibreOffice's own REGEX function documents, so a difference between engines here is a difference about the FUNCTION, not about dialect corners. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/regexreplace-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed before the run (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). None of the three Excel REGEX functions exists in any LibreOffice release tested here. LibreOffice is not without regular expressions -- its own REGEX(Text; Expression [; [Replacement] [; Flags|Occurrence]]) is documented and works -- but it is a different function with a different name, a different argument shape and a different flavour (ICU, against the PCRE2 Microsoft's pages name), so a workbook using REGEXTEST or REGEXEXTRACT does not open and run; it has to be rewritten.; MISMATCH vs expected: expected '(378) ***-4195', got '#NAME?'
REGEXREPLACE Google Sheets

=REGEXREPLACE("a1b2c3","[0-9]","#",-1)

Actual result
#N/A

Documented / expected
a1b2c#

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents: "A negative number replaces that instance, searching from the end." So -1 is the LAST digit, the 3, and only it is replaced: "a1b2c#". This is an unusual convention -- most regex APIs have no notion of it at all -- which makes it a good probe of whether an engine implemented Excel's documented argument or borrowed a host language's replace-all/replace-first semantics.; MISMATCH vs expected: expected 'a1b2c#', got '#N/A'
REGEXREPLACE LibreOffice Calc

=REGEXREPLACE("a1b2c3","[0-9]","#",-1)

Actual result
#NAME?

Documented / expected
a1b2c#

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents: "A negative number replaces that instance, searching from the end." So -1 is the LAST digit, the 3, and only it is replaced: "a1b2c#". This is an unusual convention -- most regex APIs have no notion of it at all -- which makes it a good probe of whether an engine implemented Excel's documented argument or borrowed a host language's replace-all/replace-first semantics.; MISMATCH vs expected: expected 'a1b2c#', got '#NAME?'
REGEXREPLACE LibreOffice Calc

=REGEXREPLACE("abc","[0-9]","#")

Actual result
#NAME?

Documented / expected
abc

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Nothing matches, so there is nothing to replace and the text comes back unchanged. This is the one place where the REGEX family does NOT return #N/A on a failed match -- REGEXEXTRACT does, because it has nothing to return, while a replacement over zero matches is simply the identity -- and asserting it here pins that difference. LibreOffice's own REGEX function documents the same behaviour ("if a replacement is given and no match occurs, the original text is returned unchanged").; MISMATCH vs expected: expected 'abc', got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST("ALFALFA","alfalfa",1)

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (default) and "1: Case insensitive". With 1, the lower-case literal pattern matches the upper-case string, so TRUE; with the default it would be FALSE.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST("ALFALFA","alfalfa",1)

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft documents case_sensitivity as "0: Case sensitive" (default) and "1: Case insensitive". With 1, the lower-case literal pattern matches the upper-case string, so TRUE; with the default it would be FALSE.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"a")

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's Example 1 checks "various aspects of the string 'alfalfa'", and its first row is =REGEXTEST(A2,"a") with the question "Does it contain the letter 'a'?". The documented return is "TRUE if there is a match and FALSE if there is not", and "alfalfa" plainly contains an 'a', so the answer is TRUE. (The page shows the result column only as a screenshot, so the TRUE/FALSE values in this file are read off the questions Microsoft prints in text, each of which has one and only one correct answer for the string 'alfalfa'.) REGEX FLAVOUR, AS DOCUMENTED: "All regular expressions for this function, as well as REGEXTEST and REGEXREPLACE use the PCRE2 'flavor' of regex" -- Microsoft's own sentence, printed on all three REGEX pages. This corpus's patterns are deliberately confined to character classes, quantifiers and anchors, which mean the same thing in PCRE2, in RE2 and in the ICU flavour LibreOffice's own REGEX function documents, so a difference between engines here is a difference about the FUNCTION, not about dialect corners. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/regextest-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed before the run (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). None of the three Excel REGEX functions exists in any LibreOffice release tested here. LibreOffice is not without regular expressions -- its own REGEX(Text; Expression [; [Replacement] [; Flags|Occurrence]]) is documented and works -- but it is a different function with a different name, a different argument shape and a different flavour (ICU, against the PCRE2 Microsoft's pages name), so a workbook using REGEXTEST or REGEXEXTRACT does not open and run; it has to be rewritten.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"a")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's Example 1 checks "various aspects of the string 'alfalfa'", and its first row is =REGEXTEST(A2,"a") with the question "Does it contain the letter 'a'?". The documented return is "TRUE if there is a match and FALSE if there is not", and "alfalfa" plainly contains an 'a', so the answer is TRUE. (The page shows the result column only as a screenshot, so the TRUE/FALSE values in this file are read off the questions Microsoft prints in text, each of which has one and only one correct answer for the string 'alfalfa'.) REGEX FLAVOUR, AS DOCUMENTED: "All regular expressions for this function, as well as REGEXTEST and REGEXREPLACE use the PCRE2 'flavor' of regex" -- Microsoft's own sentence, printed on all three REGEX pages. This corpus's patterns are deliberately confined to character classes, quantifiers and anchors, which mean the same thing in PCRE2, in RE2 and in the ICU flavour LibreOffice's own REGEX function documents, so a difference between engines here is a difference about the FUNCTION, not about dialect corners. Microsoft's page was re-read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/regextest-function (the /en-us/office/<name>-function-<guid> path was returning Microsoft's 'Sorry, the page you're looking for can't be found' body throughout this batch, and the working path serves an 87 KB stub about half the time, so pages were fetched with retries until the payload exceeded 150 KB). EXECUTED RESULT -- GENUINELY ABSENT: LibreOffice returns #NAME? on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3), which agree case for case, under all four spellings probed before the run (plain, _xlfn., COM.MICROSOFT. and ORG.OPENOFFICE.). None of the three Excel REGEX functions exists in any LibreOffice release tested here. LibreOffice is not without regular expressions -- its own REGEX(Text; Expression [; [Replacement] [; Flags|Occurrence]]) is documented and works -- but it is a different function with a different name, a different argument shape and a different flavour (ICU, against the PCRE2 Microsoft's pages name), so a workbook using REGEXTEST or REGEXEXTRACT does not open and run; it has to be rewritten.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"[0-9]")

Actual result
#NAME?

Documented / expected
False

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's fifth documented row, question "Does it contain any number digits?". No digits, so FALSE. Asserted alongside the TRUE rows so that an engine that always returns TRUE (or that returns a truthy string) is caught.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"[0-9]")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's fifth documented row, question "Does it contain any number digits?". No digits, so FALSE. Asserted alongside the TRUE rows so that an engine that always returns TRUE (or that returns a truthy string) is caught.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"[a-z]")

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's second documented row, question "Does it contain any lower case letters?". Every character of "alfalfa" is lower case, so TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"[a-z]")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's second documented row, question "Does it contain any lower case letters?". Every character of "alfalfa" is lower case, so TRUE.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$")

Actual result
#NAME?

Documented / expected
True

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's Example 2 checks "whether phone numbers have the specific format '(###) ###-####'" using the pattern ^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$, and notes: "Backslash '\' is used to 'escape' parentheses '()' and some other characters. In this pattern, '$' is interpreted as '(' and '$' is interpreted as ')'." The string "(378) 555-4195" is Microsoft's own first data row and matches the pattern end to end -- three digits in literal parentheses, a space, three digits, a hyphen, four digits -- so TRUE. This case also exercises the anchors and the escaping, which are the parts of a pattern most likely to be mangled on the way into a stored .xlsx.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$")

Actual result
#NAME?

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's Example 2 checks "whether phone numbers have the specific format '(###) ###-####'" using the pattern ^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$, and notes: "Backslash '\' is used to 'escape' parentheses '()' and some other characters. In this pattern, '$' is interpreted as '(' and '$' is interpreted as ')'." The string "(378) 555-4195" is Microsoft's own first data row and matches the pattern end to end -- three digits in literal parentheses, a space, three digits, a hyphen, four digits -- so TRUE. This case also exercises the anchors and the escaping, which are the parts of a pattern most likely to be mangled on the way into a stored .xlsx.; MISMATCH vs expected: expected True, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$")

Actual result
#NAME?

Documented / expected
False

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's second data row for the same example is "+1(878) 555-8622". The pattern is anchored at both ends with ^ and $, so the leading "+1" makes the whole string fail to match: FALSE. The pair of phone cases is the sharpest test in this file -- an engine that ignored the anchors would return TRUE for both.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"^$[0-9]{3}$ [0-9]{3}-[0-9]{4}$")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's second data row for the same example is "+1(878) 555-8622". The pattern is anchored at both ends with ^ and $, so the leading "+1" makes the whole string fail to match: FALSE. The pair of phone cases is the sharpest test in this file -- an engine that ignored the anchors would return TRUE for both.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXTEST Google Sheets

=REGEXTEST(A2,"[A-Z]")

Actual result
#NAME?

Documented / expected
False

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft's third documented row, question "Does it contain any upper case letters?". It does not, so FALSE -- and this is the row that proves matching is case-SENSITIVE by default, since a case-insensitive engine would answer TRUE here and every subsequent case-sensitivity assertion in this batch would be meaningless.; MISMATCH vs expected: expected False, got '#NAME?'
REGEXTEST LibreOffice Calc

=REGEXTEST(A2,"[A-Z]")

Actual result
#NAME?

Documented / expected
False

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft's third documented row, question "Does it contain any upper case letters?". It does not, so FALSE -- and this is the row that proves matching is case-SENSITIVE by default, since a case-insensitive engine would answer TRUE here and every subsequent case-sensitivity assertion in this batch would be meaningless.; MISMATCH vs expected: expected False, got '#NAME?'
ROT13 Excel for the web

=ROT13(ROT13("Hello, World! 123"))

Actual result
#NAME?

Documented / expected
Hello, World! 123

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in

A structural assertion with no constant taken from the page, from the Text parameter's own sentence: "ROT13(ROT13(Text)) decrypts the code." The argument mixes upper case, lower case, punctuation, a space and digits so that the round trip covers every character class the published example mentions. LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'Hello, World! 123', got '#NAME?'
ROT13 Google Sheets

=ROT13(ROT13("Hello, World! 123"))

Actual result
#NAME?

Documented / expected
Hello, World! 123

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Add-in

A structural assertion with no constant taken from the page, from the Text parameter's own sentence: "ROT13(ROT13(Text)) decrypts the code." The argument mixes upper case, lower case, punctuation, a space and digits so that the round trip covers every character class the published example mentions. LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'Hello, World! 123', got '#NAME?'
ROT13 Excel for the web

=ROT13("Gur Qbphzrag Sbhaqngvba jnf sbhaqrq va Frcgrzore 2010.")

Actual result
#NAME?

Documented / expected
The Document Foundation was founded in September 2010.

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=ROT13("Gur Qbphzrag Sbhaqngvba jnf sbhaqrq va Frcgrzore 2010.") returns the string "The Document Foundation was founded in September 2010.". Notice how spaces, digits, and full stops are unaffected by ROT13." The example is unusually well chosen: it carries the alphabetic rotation, the case preservation, and the pass-through of spaces, digits and punctuation in a single string, and the page's own closing sentence says so. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'The Document Foundation was founded in September 2010.', got '#NAME?'
ROT13 Google Sheets

=ROT13("Gur Qbphzrag Sbhaqngvba jnf sbhaqrq va Frcgrzore 2010.")

Actual result
#NAME?

Documented / expected
The Document Foundation was founded in September 2010.

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Add-in

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=ROT13("Gur Qbphzrag Sbhaqngvba jnf sbhaqrq va Frcgrzore 2010.") returns the string "The Document Foundation was founded in September 2010.". Notice how spaces, digits, and full stops are unaffected by ROT13." The example is unusually well chosen: it carries the alphabetic rotation, the case preservation, and the pass-through of spaces, digits and punctuation in a single string, and the page's own closing sentence says so. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'The Document Foundation was founded in September 2010.', got '#NAME?'
ROT13 Excel for the web

=ROT13("abcXYZ")

Actual result
#NAME?

Documented / expected
nopKLM

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Add-in

DERIVED from the description: "Encrypts a character string by moving the characters 13 positions in the alphabet. After the letter Z, the alphabet begins again (Rotation)." a b c move forward to n o p, while X Y Z pass the end and wrap to K L M. The published example above contains no letter beyond m in the second half of the alphabet in a position that shows the wrap unambiguously, so this case is what actually tests the sentence about beginning again. LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'nopKLM', got '#NAME?'
ROT13 Google Sheets

=ROT13("abcXYZ")

Actual result
#NAME?

Documented / expected
nopKLM

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Add-in

DERIVED from the description: "Encrypts a character string by moving the characters 13 positions in the alphabet. After the letter Z, the alphabet begins again (Rotation)." a b c move forward to n o p, while X Y Z pass the end and wrap to K L M. The published example above contains no letter beyond m in the second half of the alphabet in a position that shows the wrap unambiguously, so this case is what actually tests the sentence about beginning again. LibreOffice's ROT13 help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 'nopKLM', got '#NAME?'
RRI Google Sheets

=RRI(0,10000,11000)

Actual result
#DIV/0!

Documented / expected
#NUM!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Financial

Excel documents #NUM! if nper is less than or equal to 0 (and if pv is less than or equal to 0); MISMATCH vs expected: expected '#NUM!', got '#DIV/0!'
RRI LibreOffice Calc

=RRI(0,10000,11000)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if nper is less than or equal to 0 (and if pv is less than or equal to 0); MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
RRI LibreOffice Calc

=RRI(96,0,11000)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

Excel documents #NUM! if pv is less than or equal to 0; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
SCAN LibreOffice Calc

=SCAN(0,A1:A3,LAMBDA(a,b,a+b))

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{1, 3, 6}

Engine
LibreOffice Calc 25.8.7.3

Category
Logical

MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
SEC LibreOffice Calc

=SEC(200000000)

Actual result
-1.35887556717362

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The Remarks publish: "The absolute value of number must be less than 2^27" and "If number is outside its constraints, SEC returns the #NUM! error value." 2^27 = 134217728, so 200000000 is outside the documented range. LIBREOFFICE DOES NOT ENFORCE THE LIMIT: all four builds returned -1.35887556717362 rather than #NUM!. That is a silent wrong answer rather than a harmless permissiveness, and the limit exists precisely because of it -- at 2e8 radians the argument reduction consumes every bit of a double's precision, so the secant returned is numerically meaningless. Excel documents the guard; LibreOffice computes through it.; MISMATCH vs expected: expected '#NUM!', got -1.35887556717362
SECH Excel for the web

=SECH(200000000)

Actual result
0

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Math and trigonometry

The Remarks publish the same constraint SEC carries: "The absolute value of number must be less than 2^27" (= 134217728) and "If number is outside its constraints, SECH returns the #NUM! error value." LIBREOFFICE DOES NOT ENFORCE THE LIMIT: all four builds returned 0 rather than #NUM!. That is a silent wrong answer rather than a harmless permissiveness, and the limit exists precisely because of it -- at 2e8 radians the argument reduction consumes every bit of a double's precision, so the hyperbolic secant simply underflows to zero. Excel documents the guard; LibreOffice computes through it.; MISMATCH vs expected: expected '#NUM!', got 0
SECH LibreOffice Calc

=SECH(200000000)

Actual result
0

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The Remarks publish the same constraint SEC carries: "The absolute value of number must be less than 2^27" (= 134217728) and "If number is outside its constraints, SECH returns the #NUM! error value." LIBREOFFICE DOES NOT ENFORCE THE LIMIT: all four builds returned 0 rather than #NUM!. That is a silent wrong answer rather than a harmless permissiveness, and the limit exists precisely because of it -- at 2e8 radians the argument reduction consumes every bit of a double's precision, so the hyperbolic secant simply underflows to zero. Excel documents the guard; LibreOffice computes through it.; MISMATCH vs expected: expected '#NUM!', got 0
SKEW LibreOffice Calc

=SKEW(A1:A4)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Excel documents #DIV/0! if the sample standard deviation is zero, since the formula standardizes each deviation by s; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
SKEW.P LibreOffice Calc

=SKEW.P(5,5,5,5)

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The second half of the same Remark: a standard deviation of zero is a #DIV/0!. Four identical values give a population standard deviation of exactly 0, so the divisor in ((x-mu)/sigma)^3 vanishes.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
SMALL LibreOffice Calc

=SMALL(A1:A5,6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Only 5 values exist; requesting the 6th-smallest is out of range; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
SMALL LibreOffice Calc

=SMALL(A1:A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
SORT Google Sheets

=SORT(A1:A5,1,-1)

Actual result
{1, 1.0, 3.0, 4.0, 5.0}

Documented / expected
{5, 4, 3, 1, 1}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 5, got 1
SORTBY Google Sheets

=SORTBY(A1:A3,B1:B3)

Actual result
{#NAME?, , }

Documented / expected
{y, z, x}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 'y', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: =SORTN(A2:C6) -> Alice 100 90. Two defaults are doing the work and the page states both: n is "[OPTIONAL - 1 by default]", and the Notes say "If sort_column1 and is_ascending1 aren't included, the sort is performed on the lowest-index column in range" -- column A, the names, ascending, where Alice sorts first. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. SORTN's page carries a real Examples block in the article body: a source table ("The following table is used for the examples below") of five students with two scores each, and seven Formula/Result rows over it. This file executes all seven, on that exact data. EVERY EXPECTED VALUE HERE IS GOOGLE'S OWN PUBLISHED OUTPUT, and each was additionally re-derived by hand from the display_ties_mode definitions before being written down; all seven reproduce. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6)

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: =SORTN(A2:C6) -> Alice 100 90. Two defaults are doing the work and the page states both: n is "[OPTIONAL - 1 by default]", and the Notes say "If sort_column1 and is_ascending1 aren't included, the sort is performed on the lowest-index column in range" -- column A, the names, ascending, where Alice sorts first. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. SORTN's page carries a real Examples block in the article body: a source table ("The following table is used for the examples below") of five students with two scores each, and seven Formula/Result rows over it. This file executes all seven, on that exact data. EVERY EXPECTED VALUE HERE IS GOOGLE'S OWN PUBLISHED OUTPUT, and each was additionally re-derived by hand from the display_ties_mode definitions before being written down; all seven reproduce. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Bob, 75, 85}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Bob 75 85. Still sorted by the name column, so the two lowest names come back regardless of score. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 2)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Bob, 75, 85}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Bob 75 85. Still sorted by the name column, so the two lowest names come back regardless of score. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 3, 0, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Devon 100 95 / Carol 80 85. Mode 0 is "Show at most the first n rows in the sorted range", so the tie between Alice and Devon at 100 is simply truncated at three rows and Eloise, also on 80, is cut off. The relative order within a tie follows the source, which the Notes support: "range is sorted only by the specified columns. Other columns are returned in the order they originally appear." ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 3, 0, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Devon 100 95 / Carol 80 85. Mode 0 is "Show at most the first n rows in the sorted range", so the tie between Alice and Devon at 100 is simply truncated at three rows and Eloise, also on 80, is cut off. The relative order within a tie follows the source, which the Notes support: "range is sorted only by the specified columns. Other columns are returned in the order they originally appear." ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 3, 1, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}, {Eloise, 80, 90}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Devon 100 95 / Carol 80 85 / Eloise 80 90. Mode 1 is "Show at most the first n rows, plus any additional rows that are identical to the nth row". The nth row is Carol; Eloise is NOT identical to Carol as a row (85 against 90 on Test 2) but ties her on the sort column, and the published output includes her. A NOTE THE PAGE NEEDS AND DOES NOT HAVE: its display_ties_mode wording talks about "rows that are identical to the nth row" and "removing duplicate rows", but no two rows in its own example data are identical -- Alice and Devon share only their Test 1 score, as do Carol and Eloise. The published outputs are only consistent with "identical" and "duplicate" meaning EQUAL IN THE SORT COLUMN OR COLUMNS, not equal as whole rows. That reading is recorded here because it is derived from Google's results rather than stated in Google's prose. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 3, 1, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}, {Eloise, 80, 90}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Devon 100 95 / Carol 80 85 / Eloise 80 90. Mode 1 is "Show at most the first n rows, plus any additional rows that are identical to the nth row". The nth row is Carol; Eloise is NOT identical to Carol as a row (85 against 90 on Test 2) but ties her on the sort column, and the published output includes her. A NOTE THE PAGE NEEDS AND DOES NOT HAVE: its display_ties_mode wording talks about "rows that are identical to the nth row" and "removing duplicate rows", but no two rows in its own example data are identical -- Alice and Devon share only their Test 1 score, as do Carol and Eloise. The published outputs are only consistent with "identical" and "duplicate" meaning EQUAL IN THE SORT COLUMN OR COLUMNS, not equal as whole rows. That reading is recorded here because it is derived from Google's results rather than stated in Google's prose. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 3, 2, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Carol, 80, 85}, {Bob, 75, 85}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Carol 80 85 / Bob 75 85. Mode 2 is "Show at most the first n rows after removing duplicate rows", and this is the row that proves "duplicate" cannot mean what it says: no two rows in the data are identical, yet Devon and Eloise are both removed. They are the second row at each of the tied scores 100 and 80. A NOTE THE PAGE NEEDS AND DOES NOT HAVE: its display_ties_mode wording talks about "rows that are identical to the nth row" and "removing duplicate rows", but no two rows in its own example data are identical -- Alice and Devon share only their Test 1 score, as do Carol and Eloise. The published outputs are only consistent with "identical" and "duplicate" meaning EQUAL IN THE SORT COLUMN OR COLUMNS, not equal as whole rows. That reading is recorded here because it is derived from Google's results rather than stated in Google's prose. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 3, 2, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Carol, 80, 85}, {Bob, 75, 85}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Alice 100 90 / Carol 80 85 / Bob 75 85. Mode 2 is "Show at most the first n rows after removing duplicate rows", and this is the row that proves "duplicate" cannot mean what it says: no two rows in the data are identical, yet Devon and Eloise are both removed. They are the second row at each of the tied scores 100 and 80. A NOTE THE PAGE NEEDS AND DOES NOT HAVE: its display_ties_mode wording talks about "rows that are identical to the nth row" and "removing duplicate rows", but no two rows in its own example data are identical -- Alice and Devon share only their Test 1 score, as do Carol and Eloise. The published outputs are only consistent with "identical" and "duplicate" meaning EQUAL IN THE SORT COLUMN OR COLUMNS, not equal as whole rows. That reading is recorded here because it is derived from Google's results rather than stated in Google's prose. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 3, 3, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}, {Eloise, 80, 90}, {Bob, 75, 85}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: all five students come back. Mode 3 is "Show at most the first n unique rows, but show every duplicate of these rows": the three distinct Test 1 scores are 100, 80 and 75, and every row carrying one of them is returned. It is the clearest demonstration that n counts DISTINCT SORT KEYS in this mode, not output rows. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 3, 3, B2:B6, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Alice, 100, 90}, {Devon, 100, 95}, {Carol, 80, 85}, {Eloise, 80, 90}, {Bob, 75, 85}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: all five students come back. Mode 3 is "Show at most the first n unique rows, but show every duplicate of these rows": the three distinct Test 1 scores are 100, 80 and 75, and every row carrying one of them is returned. It is the clearest demonstration that n counts DISTINCT SORT KEYS in this mode, not output rows. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Alice', got '#NAME?'
SORTN Excel for the web

=SORTN(A2:C6, 3, 3, 2, FALSE, 3, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Devon, 100, 95}, {Alice, 100, 90}, {Eloise, 80, 90}}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Devon 100 95 / Alice 100 90 / Eloise 80 90. This row looks malformed beside the others and is not: sort_column1 is documented as "the INDEX of the column in range or a range outside of range", so the bare 2 and 3 are column indices, each followed by its own is_ascending flag. Sorting descending by Test 1 then by Test 2 orders Devon (100,95) ahead of Alice (100,90) -- reversing them relative to every other row in the table, which is what makes this the one case that proves the second sort key is honoured. Mode 3 then counts DISTINCT COMBINED SORT KEYS, not distinct Test 1 scores: the pairs (100,95), (100,90) and (80,90) are the first three, none of them duplicated, so exactly three rows come back -- where the single-column mode-3 row above returned all five. That refinement is derived from this published output; the page never says uniqueness is measured over the whole set of sort columns. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Devon', got '#NAME?'
SORTN LibreOffice Calc

=SORTN(A2:C6, 3, 3, 2, FALSE, 3, FALSE)

Actual result
{#NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?, #NAME?}

Documented / expected
{{Devon, 100, 95}, {Alice, 100, 90}, {Eloise, 80, 90}}

Engine
LibreOffice Calc 25.8.7.3

Category
Filter

GOOGLE'S OWN PUBLISHED RESULT: -> Devon 100 95 / Alice 100 90 / Eloise 80 90. This row looks malformed beside the others and is not: sort_column1 is documented as "the INDEX of the column in range or a range outside of range", so the bare 2 and 3 are column indices, each followed by its own is_ascending flag. Sorting descending by Test 1 then by Test 2 orders Devon (100,95) ahead of Alice (100,90) -- reversing them relative to every other row in the table, which is what makes this the one case that proves the second sort key is honoured. Mode 3 then counts DISTINCT COMBINED SORT KEYS, not distinct Test 1 scores: the pairs (100,95), (100,90) and (80,90) are the first three, none of them duplicated, so exactly three rows come back -- where the single-column mode-3 row above returned all five. That refinement is derived from this published output; the page never says uniqueness is measured over the whole set of sort columns. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SORTN page, read live on 2026-08-31 at https://support.google.com/docs/answer/7354624.; MISMATCH vs expected: value mismatch: expected 'Devon', got '#NAME?'
SPLIT Excel for the web

=SPLIT("a-the-b","the",FALSE)

Actual result
{#NAME?, #NAME?}

Documented / expected
{a-, -b}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED from "Set split_by_each to FALSE to turn off this behavior", i.e. the delimiter is then matched as one whole string. "a-the-b" contains "the" once, so it yields two fragments and the hyphens -- which the previous case's character-set reading would have left untouched anyway -- survive. This is the exact pair that shows the flag doing something. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: value mismatch: expected 'a-', got '#NAME?'
SPLIT LibreOffice Calc

=SPLIT("a-the-b","the",FALSE)

Actual result
{#NAME?, #NAME?}

Documented / expected
{a-, -b}

Engine
LibreOffice Calc 25.8.7.3

Category
Text

DERIVED from "Set split_by_each to FALSE to turn off this behavior", i.e. the delimiter is then matched as one whole string. "a-the-b" contains "the" once, so it yields two fragments and the hyphens -- which the previous case's character-set reading would have left untouched anyway -- survive. This is the exact pair that shows the flag doing something. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: value mismatch: expected 'a-', got '#NAME?'
SPLIT Excel for the web

=COLUMNS(SPLIT("a,,b",","))

Actual result
#NAME?

Documented / expected
2

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED from the remove_empty_text description: "[OPTIONAL - TRUE by default] ... The default behavior is to treat consecutive delimiters as one (if TRUE)." Counted through COLUMNS rather than compared as a spilled array, because the interesting quantity is HOW MANY cells come back and an empty cell is exactly the thing that is hard to compare. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 2, got '#NAME?'
SPLIT LibreOffice Calc

=COLUMNS(SPLIT("a,,b",","))

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Text

DERIVED from the remove_empty_text description: "[OPTIONAL - TRUE by default] ... The default behavior is to treat consecutive delimiters as one (if TRUE)." Counted through COLUMNS rather than compared as a spilled array, because the interesting quantity is HOW MANY cells come back and an empty cell is exactly the thing that is hard to compare. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 2, got '#NAME?'
SPLIT Excel for the web

=COLUMNS(SPLIT("a,,b",",",TRUE,FALSE))

Actual result
#NAME?

Documented / expected
3

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED from the rest of the same sentence: "If FALSE, empty cells values are added between consecutive delimiters." The pair with the previous case is what makes either meaningful: 2 against 3. Note the third argument must be supplied positionally to reach the fourth. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 3, got '#NAME?'
SPLIT LibreOffice Calc

=COLUMNS(SPLIT("a,,b",",",TRUE,FALSE))

Actual result
#NAME?

Documented / expected
3

Engine
LibreOffice Calc 25.8.7.3

Category
Text

DERIVED from the rest of the same sentence: "If FALSE, empty cells values are added between consecutive delimiters." The pair with the previous case is what makes either meaningful: 2 against 3. Note the third argument must be supplied positionally to reach the fourth. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 3, got '#NAME?'
SPLIT Excel for the web

=COUNTIF(SPLIT("a-b-c","-"),"*-*")

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

A structural assertion with no derived constant, from the Note: "Note that the character or characters to split the string around will not be contained in the result themselves." COUNTIF with the wildcard pattern "*-*" counts fragments still containing a hyphen, and the Note says that must be none. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 0, got '#NAME?'
SPLIT LibreOffice Calc

=COUNTIF(SPLIT("a-b-c","-"),"*-*")

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Text

A structural assertion with no derived constant, from the Note: "Note that the character or characters to split the string around will not be contained in the result themselves." COUNTIF with the wildcard pattern "*-*" counts fragments still containing a hyphen, and the Note says that must be none. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: expected 0, got '#NAME?'
SPLIT Excel for the web

=SPLIT("mother","the")

Actual result
{#NAME?, #NAME?}

Documented / expected
{mo, r}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

DERIVED FROM THE PAGE'S OWN WORDED EXAMPLE, which it never executes: "By default, each character in delimiter is considered individually, e.g. if delimiter is \"the\", then text is divided around the characters \"t\", \"h\", and \"e\"." Splitting "mother" on {t, h, e} gives "mo", "", "", "r"; remove_empty_text defaults to TRUE, which the page says means "treat consecutive delimiters as one", so the empties drop and two fragments remain. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: value mismatch: expected 'mo', got '#NAME?'
SPLIT LibreOffice Calc

=SPLIT("mother","the")

Actual result
{#NAME?, #NAME?}

Documented / expected
{mo, r}

Engine
LibreOffice Calc 25.8.7.3

Category
Text

DERIVED FROM THE PAGE'S OWN WORDED EXAMPLE, which it never executes: "By default, each character in delimiter is considered individually, e.g. if delimiter is \"the\", then text is divided around the characters \"t\", \"h\", and \"e\"." Splitting "mother" on {t, h, e} gives "mo", "", "", "r"; remove_empty_text defaults to TRUE, which the page says means "treat consecutive delimiters as one", so the empties drop and two fragments remain. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136.; MISMATCH vs expected: value mismatch: expected 'mo', got '#NAME?'
SPLIT Excel for the web

=SPLIT("Alas, poor Yorick"," ")

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{Alas,, poor, Yorick}

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Text

The page's own sample formula. DERIVED from the definition "Divides text around a specified character or string, and puts each fragment into a separate cell in the row" together with the Note "Note that the character or characters to split the string around will not be contained in the result themselves" -- so the spaces vanish and the comma, which is not the delimiter, stays attached to "Alas,". This sample was chosen over the page's SPLIT("1,2,3", ",") line deliberately: that one's fragments look like numbers and would test type coercion rather than splitting. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. SPLIT's page publishes NO results: three Sample Usage formulas, and an Examples section that is only a "Make a copy" link to an external spreadsheet, which is not article text. Every value below is DERIVED from the argument descriptions, which are unusually explicit for this batch. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'Alas,', got '#NAME?'
SPLIT LibreOffice Calc

=SPLIT("Alas, poor Yorick"," ")

Actual result
{#NAME?, #NAME?, #NAME?}

Documented / expected
{Alas,, poor, Yorick}

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The page's own sample formula. DERIVED from the definition "Divides text around a specified character or string, and puts each fragment into a separate cell in the row" together with the Note "Note that the character or characters to split the string around will not be contained in the result themselves" -- so the spaces vanish and the comma, which is not the delimiter, stays attached to "Alas,". This sample was chosen over the page's SPLIT("1,2,3", ",") line deliberately: that one's fragments look like numbers and would test type coercion rather than splitting. ARRAY RESULT: this case spills more than one cell, so it is written as a real array formula over an explicit check_range and compared cell by cell in row-major order, the same convention SORT, UNIQUE, SEQUENCE and TEXTSPLIT already use in this corpus. SPLIT's page publishes NO results: three Sample Usage formulas, and an Examples section that is only a "Make a copy" link to an external spreadsheet, which is not article text. Every value below is DERIVED from the argument descriptions, which are unusually explicit for this batch. Google's SPLIT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094136. BATCH PROVENANCE (batch H, the first Sheets/LibreOffice-only batch). Every function in this batch has x == false in docs/data/compat.json: it is a Google Sheets function that Microsoft does not document at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE ACTUALLY PRINTS, WHICH IS LESS THAN IT LOOKS: most of these pages carry a 'Sample Usage' block of FORMULAS WITH NO RESULTS. Where a value below is Google's own published output the note says so; where it is derived from the page's stated semantics the note says that instead, and says from which sentence. No value in this batch was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them, so the expected values below describe Google Sheets and the LibreOffice column records absence.; MISMATCH vs expected: value mismatch: expected 'Alas,', got '#NAME?'
SQRT LibreOffice Calc

=SQRT(-16)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Microsoft's SQRT docs state verbatim: 'If number is negative, SQRT returns the #NUM! error value' -- https://support.microsoft.com/en-US/Excel/functions/sqrt-function; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
SQRTPI LibreOffice Calc

=SQRTPI(-1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The page's single Remark publishes: "If number < 0, SQRTPI returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
STEYX LibreOffice Calc

=STEYX({1,2,3},{1,2})

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If known_y's and known_x's have a different number of data points, STEYX returns the #N/A error value."; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
STEYX LibreOffice Calc

=STEYX({1,2},{3,4})

Actual result
#VALUE!

Documented / expected
#DIV/0!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If known_y's and known_x's are empty or have less than three data points, STEYX returns the #DIV/0! error value." With n = 2 the documented denominator n-2 is zero, so the error code and the formula agree.; MISMATCH vs expected: expected '#DIV/0!', got '#VALUE!'
SUM LibreOffice Calc

=SUM(1,"2",3)

Actual result
#VALUE!

Documented / expected
6

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

Contrast with SUM_text_in_cell_reference_ignored: Excel coerces literal string arguments that look like numbers when they are typed directly into the formula, but does not do so for text found inside a range reference; MISMATCH vs expected: expected 6, got '#VALUE!'
SUMX2MY2 LibreOffice Calc

=SUMX2MY2({1,2,3},{1,2})

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The Remarks publish: "If array_x and array_y have a different number of values, the SUMX2MY2 function returns the #N/A error value."; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
SUMX2PY2 LibreOffice Calc

=SUMX2PY2({1,2,3},{1,2})

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The Remarks publish: "If array_x and array_y have a different number of values, SUMX2PY2 returns the #N/A error value."; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
SUMXMY2 LibreOffice Calc

=SUMXMY2({1,2,3},{1,2})

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Math and trigonometry

The Remarks publish: "If array_x and array_y do not have the same number of values, SUMXMY2 returns the #N/A error value."; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
T.DIST.2T LibreOffice Calc

=T.DIST.2T(1,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If deg_freedom < 1, T.DIST.2T returns the #NUM! error value." Unlike the T.DIST page, this one names the code.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.DIST.2T LibreOffice Calc

=T.DIST.2T(-1,10)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If x < 0, then T.DIST.2T returns the #NUM! error value." Worth noting that P(|X| > x) is perfectly well defined for negative x (it is 1), so this is a documented RESTRICTION rather than a mathematical necessity -- and its right-tailed sibling T.DIST.RT publishes no such rule, which is why the two files assert different things about negative arguments.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.DIST.RT LibreOffice Calc

=T.DIST.RT(1,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If deg_freedom < 1, T.DIST.RT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.INV LibreOffice Calc

=T.INV(0.75,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If deg_freedom < 1, T.INV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.INV LibreOffice Calc

=T.INV(0,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If probability <= 0 or if probability > 1, T.INV returns the #NUM! error value." Note the asymmetry, which is Microsoft's: zero is excluded and ONE IS NOT, so probability = 1 is not listed as an error even though the left-tailed inverse there is unbounded.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.INV.2T LibreOffice Calc

=T.INV.2T(0.5,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If deg_freedom < 1, T.INV.2T returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.INV.2T LibreOffice Calc

=T.INV.2T(0,60)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If probability <= 0 or if probability > 1, T.INV.2T returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.TEST LibreOffice Calc

=T.TEST({1,2,3},{4,5,6},3,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If tails is any value other than 1 or 2, T.TEST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
T.TEST LibreOffice Calc

=T.TEST({1,2,3},{1,2},2,1)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If array1 and array2 have a different number of data points, and type = 1 (paired), T.TEST returns the #N/A error value." The restriction is specific to the paired type -- types 2 and 3 accept unequal sample sizes -- which is why this case names type 1.; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
TAKE Google Sheets

=TAKE(A1:C3,2,2)

Actual result
{#NAME?, , , }

Documented / expected
{{1, 2}, {4, 5}}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Lookup and reference

MISMATCH vs expected: value mismatch: expected 1, got '#NAME?'
TBILLEQ LibreOffice Calc

=TBILLEQ(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If discount <= 0, TBILLEQ returns the #NUM! error value." Zero is inside the excluded range because the rule uses <=.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLEQ LibreOffice Calc

=TBILLEQ(A3,A2,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If settlement > maturity, or if maturity is more than one year after settlement, TBILLEQ returns the #NUM! error value." Passing A3 as settlement and A2 as maturity reverses them.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLEQ LibreOffice Calc

=TBILLEQ(A2,A2+400,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The second half of the same Remark. 400 days is unambiguously more than one year, chosen well clear of the 365/366 boundary so the case does not turn on how an engine reads "one year".; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLPRICE LibreOffice Calc

=TBILLPRICE(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If discount <= 0, TBILLPRICE returns the #NUM! error value." Note that the arithmetic would be perfectly well defined at zero (the price would be par, 100), so this is a documented restriction rather than a mathematical one.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLPRICE LibreOffice Calc

=TBILLPRICE(A2,A2+400,A4)

Actual result
90.1

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If settlement > maturity, or if maturity is more than one year after settlement, TBILLPRICE returns the #NUM! error value." LIBREOFFICE DOES NOT ENFORCE THIS RULE AT ALL IN TBILLPRICE, AND ITS TWO SIBLINGS DO. Probed on LibreOffice 25.8.7.3 with the same settlement date and maturities 365, 366, 370, 400, 500 and 730 days out, TBILLPRICE returned a price for EVERY one of them (90.975, 90.95, 90.85, 90.1, 87.65 and 81.975) -- a two-year bill priced without complaint -- while TBILLEQ and TBILLYIELD rejected all six. The rejection is itself off-spec: the siblings return #VALUE! where Microsoft documents #NUM!, the corpus-wide pattern already recorded in 160-odd cases. AND TBILLPRICE'S PERMISSIVENESS IS NOT EVEN MONOTONIC: at 364 days it returns #VALUE!, at 365 days and beyond it returns a price, so the one input near the documented boundary that it does reject is the one INSIDE the documented range. The returned price does not follow the documented formula on the actual day count either: 90.1 at a 400-day maturity implies DSM = 396 in 100*(1 - discount*DSM/360), which is neither the actual count (400) nor the US 30/360 count (395). The case asserts the documented #NUM! and records the divergence rather than accommodating it.; MISMATCH vs expected: expected '#NUM!', got 90.1
TBILLYIELD LibreOffice Calc

=TBILLYIELD(A2,A2+400,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The second half of the same Remark.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLYIELD LibreOffice Calc

=TBILLYIELD(A2,A3,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If pr <= 0, TBILLYIELD returns the #NUM! error value." The formula divides by pr, so zero would be a division by zero as well as a documented exclusion.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TBILLYIELD LibreOffice Calc

=TBILLYIELD(A2,A2,A4)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

A DELIBERATE DIFFERENCE BETWEEN THE THREE TBILL PAGES, recorded because it is testable. TBILLYIELD's Remark publishes "If settlement >= maturity, or if maturity is more than one year after settlement, TBILLYIELD returns the #NUM! error value" -- with a GREATER-THAN-OR-EQUAL -- while TBILLEQ and TBILLPRICE both publish "If settlement > maturity". Equal dates are therefore documented as an error here and not documented as one on the other two pages; the arithmetic agrees, since DSM = 0 would divide by zero. Only TBILLYIELD's file asserts this case, because only TBILLYIELD's page states it.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TDIST LibreOffice Calc

=TDIST(1.96,0,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If deg_freedom < 1, TDIST returns the #NUM! error value." Note this legacy page NAMES the code where its modern sibling T.DIST does not.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TDIST LibreOffice Calc

=TDIST(1.96,60,3)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If tails is any value other than 1 or 2, TDIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TDIST LibreOffice Calc

=TDIST(-1,60,2)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If x < 0, then TDIST returns the #NUM! error value." The same page ALSO publishes, two bullets later, the identities "TDIST(-x,df,1) = 1 - TDIST(x,df,1) = P(X > -x)" and "TDIST(-x,df,2) = TDIST(x,df,2) = P(|X| > x)" -- i.e. it defines the function at negative arguments in the same breath as forbidding them. Recorded as published; the #NUM! rule is the one asserted, because it is the one stated as a return value.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TEXTAFTER Google Sheets

=TEXTAFTER("a-b-c","-")

Actual result
#NAME?

Documented / expected
b-c

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'b-c', got '#NAME?'
TEXTAFTER Google Sheets

=TEXTAFTER("a-b-c","-",2)

Actual result
#NAME?

Documented / expected
c

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'c', got '#NAME?'
TEXTAFTER Google Sheets

=TEXTAFTER("a-b-c","-",-1)

Actual result
#NAME?

Documented / expected
c

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

-1 means the last delimiter; text after it is 'c'; MISMATCH vs expected: expected 'c', got '#NAME?'
TEXTAFTER Google Sheets

=TEXTAFTER("abc","-","none")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Signature: TEXTAFTER(text, delimiter, [instance_num], [match_mode], [match_end], [if_not_found]). "none" here is passed as instance_num, where a number is required, so the documented result is #VALUE! -- confirmed by Excel for the web and LibreOffice 25.8. if_not_found must be the sixth argument.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
TEXTBEFORE Google Sheets

=TEXTBEFORE("a-b-c","-")

Actual result
#NAME?

Documented / expected
a

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'a', got '#NAME?'
TEXTBEFORE Google Sheets

=TEXTBEFORE("a-b-c","-",2)

Actual result
#NAME?

Documented / expected
a-b

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected 'a-b', got '#NAME?'
TEXTBEFORE Google Sheets

=TEXTBEFORE("a-b-c","-",-1)

Actual result
#NAME?

Documented / expected
a-b

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

-1 means the last delimiter; text before it is 'a-b'; MISMATCH vs expected: expected 'a-b', got '#NAME?'
TEXTBEFORE Google Sheets

=TEXTBEFORE("abc","-","none")

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Signature: TEXTBEFORE(text, delimiter, [instance_num], [match_mode], [match_end], [if_not_found]). "none" here is passed as instance_num, where a number is required, so the documented result is #VALUE! -- confirmed by Excel for the web and LibreOffice 25.8. if_not_found must be the sixth argument.; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
TEXTBEFORE Google Sheets

=TEXTBEFORE("abc","-")

Actual result
#NAME?

Documented / expected
#N/A

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: expected '#N/A', got '#NAME?'
TEXTSPLIT Google Sheets

=TEXTSPLIT("a,b,c",",")

Actual result
{#NAME?, , }

Documented / expected
{a, b, c}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: value mismatch: expected 'a', got '#NAME?'
TEXTSPLIT Google Sheets

=TEXTSPLIT("a,,b",",",,TRUE)

Actual result
{#NAME?, }

Documented / expected
{a, b}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: value mismatch: expected 'a', got '#NAME?'
TEXTSPLIT Google Sheets

=TEXTSPLIT("a,b,c;d",",",";",FALSE,0,"-")

Actual result
{#NAME?, , , , , }

Documented / expected
{{a, b, c}, {d, -, -}}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: value mismatch: expected 'a', got '#NAME?'
TEXTSPLIT Google Sheets

=TEXTSPLIT("a,b;c,d",",",";")

Actual result
{#NAME?, , , }

Documented / expected
{{a, b}, {c, d}}

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

MISMATCH vs expected: value mismatch: expected 'a', got '#NAME?'
TINV LibreOffice Calc

=TINV(0.05,0)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If deg_freedom < 1, TINV returns the #NUM! error value." A separate documented failure mode is NOT asserted anywhere in this file: "If the search has not converged after 100 iterations, the function returns the #N/A error value" is a property of Microsoft's particular iterative implementation, not of the function, and no input is known that reliably triggers it.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TINV Excel for the web

=TINV(1.5,60)

Actual result
-0.6786007206481388

Documented / expected
#NUM!

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Compatibility

The Remarks publish: "If probability <= 0 or if probability > 1, TINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got -0.6786007206481388
TINV LibreOffice Calc

=TINV(1.5,60)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If probability <= 0 or if probability > 1, TINV returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TO_DATE Excel for the web

=ROUND(TO_DATE(40826.4375)-DATE(2011,10,10),10)

Actual result
#NAME?

Documented / expected
0.4375

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "fractional values indicate time of day past midnight", applied to the page's own Sample Usage formula TO_DATE(40826.4375) (again printed with no result). Derived independently: 1899-12-30 + 40826 days = 2011-10-10, and the remaining 0.4375 of a day is 10h30m past midnight. Asserted as the difference from DATE(2011,10,10) so both halves of the claim -- the date and the fraction -- are checked in one value without depending on a locale's time format. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0.4375, got '#NAME?'
TO_DATE LibreOffice Calc

=ROUND(TO_DATE(40826.4375)-DATE(2011,10,10),10)

Actual result
#NAME?

Documented / expected
0.4375

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "fractional values indicate time of day past midnight", applied to the page's own Sample Usage formula TO_DATE(40826.4375) (again printed with no result). Derived independently: 1899-12-30 + 40826 days = 2011-10-10, and the remaining 0.4375 of a day is 10h30m past midnight. Asserted as the difference from DATE(2011,10,10) so both halves of the claim -- the date and the fraction -- are checked in one value without depending on a locale's time format. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0.4375, got '#NAME?'
TO_DATE Excel for the web

=N(TO_DATE(25405))

Actual result
#NAME?

Documented / expected
25405

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the Notes bullet "TO_DATE is the inverse of N as applied to a date". If TO_DATE only re-formats the number it is given, then N -- which reads a date back as its serial -- must return the original argument. No constant was taken from the page; 25405 is the page's own sample argument coming back out. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 25405, got '#NAME?'
TO_DATE LibreOffice Calc

=N(TO_DATE(25405))

Actual result
#NAME?

Documented / expected
25405

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the Notes bullet "TO_DATE is the inverse of N as applied to a date". If TO_DATE only re-formats the number it is given, then N -- which reads a date back as its serial -- must return the original argument. No constant was taken from the page; 25405 is the page's own sample argument coming back out. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 25405, got '#NAME?'
TO_DATE Excel for the web

=TO_DATE("not a number")

Actual result
#NAME?

Documented / expected
not a number

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the sentence "If value is not a number or a reference to a cell containing a numeric value, TO_DATE returns value without modification." The page gives no example of this, so the argument here is a plain string chosen to be unambiguously non-numeric. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 'not a number', got '#NAME?'
TO_DATE LibreOffice Calc

=TO_DATE("not a number")

Actual result
#NAME?

Documented / expected
not a number

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the sentence "If value is not a number or a reference to a cell containing a numeric value, TO_DATE returns value without modification." The page gives no example of this, so the argument here is a plain string chosen to be unambiguously non-numeric. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 'not a number', got '#NAME?'
TO_DATE Excel for the web

=TO_DATE(25405)-DATE(1969,7,21)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, not published: the page prints TO_DATE(25405) as a Sample Usage formula with NO result beside it. The rule it is derived from is the page's own sentence "If value is a number or a reference to a cell containing a numeric value, TO_DATE returns value converted to a date, interpreting value as number of days since December 30, 1899." Derived independently: 1899-12-30 + 25405 days = 1969-07-21 (computed with Python's proleptic Gregorian calendar, which agrees with the 1899-12-30-origin serial system for every date after 1900-03-01). Asserted as a DIFFERENCE against DATE(1969,7,21) rather than as a serial or a formatted string, so the case is independent of the locale's date format and of whether the engine hands the harness a date object or a number. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0, got '#NAME?'
TO_DATE LibreOffice Calc

=TO_DATE(25405)-DATE(1969,7,21)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, not published: the page prints TO_DATE(25405) as a Sample Usage formula with NO result beside it. The rule it is derived from is the page's own sentence "If value is a number or a reference to a cell containing a numeric value, TO_DATE returns value converted to a date, interpreting value as number of days since December 30, 1899." Derived independently: 1899-12-30 + 25405 days = 1969-07-21 (computed with Python's proleptic Gregorian calendar, which agrees with the 1899-12-30-origin serial system for every date after 1900-03-01). Asserted as a DIFFERENCE against DATE(1969,7,21) rather than as a serial or a formatted string, so the case is independent of the locale's date format and of whether the engine hands the harness a date object or a number. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0, got '#NAME?'
TO_DATE Excel for the web

=ROUND(TO_DATE(10/10/2000)+0,10)

Actual result
#NAME?

Documented / expected
0.0005

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the Notes bullet, which states the arithmetic outright: "TO_DATE does not autoconvert number formats in the same way as direct entry into cells. Therefore, TO_DATE(10/10/2000) is interpreted as TO_DATE(0.0005), the quotient of 10 divided by 10 divided by 2000." Derived independently: 10/10 = 1 and 1/2000 = 0.0005 exactly. The bullet names the intermediate value 0.0005 but prints no result for the call, so the assertion is that the VALUE survives -- +0 strips the date formatting the function applies, and ROUND(...,10) keeps the case free of last-bit formatting differences. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0.0005, got '#NAME?'
TO_DATE LibreOffice Calc

=ROUND(TO_DATE(10/10/2000)+0,10)

Actual result
#NAME?

Documented / expected
0.0005

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the Notes bullet, which states the arithmetic outright: "TO_DATE does not autoconvert number formats in the same way as direct entry into cells. Therefore, TO_DATE(10/10/2000) is interpreted as TO_DATE(0.0005), the quotient of 10 divided by 10 divided by 2000." Derived independently: 10/10 = 1 and 1/2000 = 0.0005 exactly. The bullet names the intermediate value 0.0005 but prints no result for the call, so the assertion is that the VALUE survives -- +0 strips the date formatting the function applies, and ROUND(...,10) keeps the case free of last-bit formatting differences. Google's TO_DATE page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094239.; MISMATCH vs expected: expected 0.0005, got '#NAME?'
TO_DOLLARS Excel for the web

=ROUND(TO_DOLLARS(TO_PERCENT(0.5))+0,10)

Actual result
#NAME?

Documented / expected
0.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the Notes bullet "Because dates and percentages are backed by numbers, TO_DOLLARS will convert them successfully. However, these conversions are not typically meaningful." The page warns that the RESULT is not meaningful, not that it errors, so what is asserted is precisely that: the call succeeds and the underlying number is untouched. No claim is made about how it displays. Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 0.5, got '#NAME?'
TO_DOLLARS LibreOffice Calc

=ROUND(TO_DOLLARS(TO_PERCENT(0.5))+0,10)

Actual result
#NAME?

Documented / expected
0.5

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the Notes bullet "Because dates and percentages are backed by numbers, TO_DOLLARS will convert them successfully. However, these conversions are not typically meaningful." The page warns that the RESULT is not meaningful, not that it errors, so what is asserted is precisely that: the call succeeds and the underlying number is untouched. No claim is made about how it displays. Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 0.5, got '#NAME?'
TO_DOLLARS Excel for the web

=TO_DOLLARS("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_DOLLARS returns value without modification." Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_DOLLARS LibreOffice Calc

=TO_DOLLARS("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_DOLLARS returns value without modification." Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_DOLLARS Excel for the web

=ISNUMBER(TO_DOLLARS(5))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the Notes bullet "TO_DOLLARS differs from the related function DOLLAR in that DOLLAR outputs text rather than applying a cell format to a number." That sentence makes two separable claims; this case asserts the TO_DOLLARS half (the result is still a number) and the next case asserts the DOLLAR half, so a failure identifies which of the two is wrong. Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_DOLLARS LibreOffice Calc

=ISNUMBER(TO_DOLLARS(5))

Actual result
False

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the Notes bullet "TO_DOLLARS differs from the related function DOLLAR in that DOLLAR outputs text rather than applying a cell format to a number." That sentence makes two separable claims; this case asserts the TO_DOLLARS half (the result is still a number) and the next case asserts the DOLLAR half, so a failure identifies which of the two is wrong. Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_DOLLARS Excel for the web

=ROUND(TO_DOLLARS(40826.43)+0,10)

Actual result
#NAME?

Documented / expected
40826.43

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, not published: TO_DOLLARS(40826.43) appears in the Sample Usage block with no result beside it. The claim being checked is the page's own framing -- "TO_DOLLARS is equivalent to applying Format -> Number -> Currency from the menu bar" -- which makes the operation a formatting change, so the number must come back unchanged. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 40826.43, got '#NAME?'
TO_DOLLARS LibreOffice Calc

=ROUND(TO_DOLLARS(40826.43)+0,10)

Actual result
#NAME?

Documented / expected
40826.43

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, not published: TO_DOLLARS(40826.43) appears in the Sample Usage block with no result beside it. The claim being checked is the page's own framing -- "TO_DOLLARS is equivalent to applying Format -> Number -> Currency from the menu bar" -- which makes the operation a formatting change, so the number must come back unchanged. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_DOLLARS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094241.; MISMATCH vs expected: expected 40826.43, got '#NAME?'
TO_PERCENT Excel for the web

=TO_PERCENT("x")

Actual result
#NAME?

Documented / expected
x

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_PERCENT returns value without modification." Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 'x', got '#NAME?'
TO_PERCENT LibreOffice Calc

=TO_PERCENT("x")

Actual result
#NAME?

Documented / expected
x

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_PERCENT returns value without modification." Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 'x', got '#NAME?'
TO_PERCENT Excel for the web

=ROUND(TO_PERCENT(UNARY_PERCENT(100))+0,10)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from two sentences on two Google pages that agree with each other: TO_PERCENT's "with the standard interpretation that 1 = 100%" and UNARY_PERCENT's own description, which states its result inline as "UNARY_PERCENT(100) equals 1". UNARY_PERCENT(100) is therefore 1, and TO_PERCENT of 1 leaves the value 1 while displaying it as 100%. Nothing here asserts anything about the display. Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 1, got '#NAME?'
TO_PERCENT LibreOffice Calc

=ROUND(TO_PERCENT(UNARY_PERCENT(100))+0,10)

Actual result
#NAME?

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from two sentences on two Google pages that agree with each other: TO_PERCENT's "with the standard interpretation that 1 = 100%" and UNARY_PERCENT's own description, which states its result inline as "UNARY_PERCENT(100) equals 1". UNARY_PERCENT(100) is therefore 1, and TO_PERCENT of 1 leaves the value 1 while displaying it as 100%. Nothing here asserts anything about the display. Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 1, got '#NAME?'
TO_PERCENT Excel for the web

=ISNUMBER(TO_PERCENT(0.5))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the same Format-menu sentence: applying a number format leaves a number. This is the discriminator against an implementation that returned a string like "50%"; the page never says the result is text. Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_PERCENT LibreOffice Calc

=ISNUMBER(TO_PERCENT(0.5))

Actual result
False

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the same Format-menu sentence: applying a number format leaves a number. This is the discriminator against an implementation that returned a string like "50%"; the page never says the result is text. Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_PERCENT Excel for the web

=ROUND(TO_PERCENT(0.40826)+0,10)

Actual result
#NAME?

Documented / expected
0.40826

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, not published: TO_PERCENT(0.40826) appears in Sample Usage with no result. The page states the operation is "equivalent to clicking Format Number Percent from the menu bar", i.e. a formatting change, so the underlying number must be unchanged. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 0.40826, got '#NAME?'
TO_PERCENT LibreOffice Calc

=ROUND(TO_PERCENT(0.40826)+0,10)

Actual result
#NAME?

Documented / expected
0.40826

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, not published: TO_PERCENT(0.40826) appears in Sample Usage with no result. The page states the operation is "equivalent to clicking Format Number Percent from the menu bar", i.e. a formatting change, so the underlying number must be unchanged. WHAT THIS HARNESS CAN AND CANNOT SEE FOR A TO_* FUNCTION. The TO_* parsers are FORMATTING functions: the page itself describes the operation as equivalent to applying a Format > Number command from the menu bar. What changes is the cell's number format, not the number. This harness records the computed VALUE read back from a recalculated .xlsx, so the format half of the documented behaviour is invisible to it and is NOT asserted anywhere in this file. What is asserted is the value half, which the page states outright: the underlying number survives the conversion unchanged, and a non-numeric argument is returned unmodified. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094284.; MISMATCH vs expected: expected 0.40826, got '#NAME?'
TO_PURE_NUMBER Excel for the web

=ISTEXT(TO_PURE_NUMBER("abc"))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the Notes bullet "TO_PURE_NUMBER is similar to N, except that N returns 0 for non-numeric values except for TRUE which returns 1, whereas TO_PURE_NUMBER returns the value passed without modification for all non-numeric types." Only the TO_PURE_NUMBER half is asserted: N is a separate function with its own page and its own cases in this corpus. NOTHING IS ASSERTED ABOUT A BOOLEAN ARGUMENT -- the bullet says what N does with TRUE but never says whether TO_PURE_NUMBER counts a boolean as a non-numeric type, so the page settles nothing there and this file asserts nothing there. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_PURE_NUMBER LibreOffice Calc

=ISTEXT(TO_PURE_NUMBER("abc"))

Actual result
False

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the Notes bullet "TO_PURE_NUMBER is similar to N, except that N returns 0 for non-numeric values except for TRUE which returns 1, whereas TO_PURE_NUMBER returns the value passed without modification for all non-numeric types." Only the TO_PURE_NUMBER half is asserted: N is a separate function with its own page and its own cases in this corpus. NOTHING IS ASSERTED ABOUT A BOOLEAN ARGUMENT -- the bullet says what N does with TRUE but never says whether TO_PURE_NUMBER counts a boolean as a non-numeric type, so the page settles nothing there and this file asserts nothing there. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_PURE_NUMBER Excel for the web

=TO_PURE_NUMBER("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, AND THE SENTENCE IT IS DERIVED FROM CONTAINS A PUBLISHED ERROR WORTH RECORDING. The rule paragraph on TO_PURE_NUMBER's page reads, verbatim: "If value is not a number or a reference to a cell containing a numeric value, TO_PERCENT returns value without modification." It names TO_PERCENT -- a different function, which has its own page carrying the same sentence correctly -- in the middle of TO_PURE_NUMBER's own rule block. The intended subject is unambiguous from position and from the parallel Notes bullet below it ("TO_PURE_NUMBER returns the value passed without modification for all non-numeric types"), so the behaviour asserted here is not in doubt; the copy-paste slip is recorded rather than silently read past. Re-fetched on a second request the same day to rule out a transcription error on this end: it says TO_PERCENT both times. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_PURE_NUMBER LibreOffice Calc

=TO_PURE_NUMBER("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, AND THE SENTENCE IT IS DERIVED FROM CONTAINS A PUBLISHED ERROR WORTH RECORDING. The rule paragraph on TO_PURE_NUMBER's page reads, verbatim: "If value is not a number or a reference to a cell containing a numeric value, TO_PERCENT returns value without modification." It names TO_PERCENT -- a different function, which has its own page carrying the same sentence correctly -- in the middle of TO_PURE_NUMBER's own rule block. The intended subject is unambiguous from position and from the parallel Notes bullet below it ("TO_PURE_NUMBER returns the value passed without modification for all non-numeric types"), so the behaviour asserted here is not in doubt; the copy-paste slip is recorded rather than silently read past. Re-fetched on a second request the same day to rule out a transcription error on this end: it says TO_PERCENT both times. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_PURE_NUMBER Excel for the web

=ROUND(TO_PURE_NUMBER(TO_DOLLARS(12.5)),10)

Actual result
#NAME?

Documented / expected
12.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from the page's opening sentence, which names its accepted inputs: "Converts a provided date/time, percentage, currency or other formatted numeric value to a pure number without formatting." The currency value is produced by TO_DOLLARS, the function the page's own See Also list points at for that format. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 12.5, got '#NAME?'
TO_PURE_NUMBER LibreOffice Calc

=ROUND(TO_PURE_NUMBER(TO_DOLLARS(12.5)),10)

Actual result
#NAME?

Documented / expected
12.5

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from the page's opening sentence, which names its accepted inputs: "Converts a provided date/time, percentage, currency or other formatted numeric value to a pure number without formatting." The currency value is produced by TO_DOLLARS, the function the page's own See Also list points at for that format. Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 12.5, got '#NAME?'
TO_PURE_NUMBER Excel for the web

=ROUND(TO_PURE_NUMBER(50%),10)

Actual result
#NAME?

Documented / expected
0.5

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, not published: TO_PURE_NUMBER(50%) is printed in Sample Usage with no result. The rule is the page's own "If value is a number or a reference to a cell containing a numeric value, TO_PURE_NUMBER returns value with all formatting and interpretation removed", and 50% is the literal the page itself chose. Derived independently: a percent literal is one hundredth of its face value, so 50% is 0.5. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 0.5, got '#NAME?'
TO_PURE_NUMBER LibreOffice Calc

=ROUND(TO_PURE_NUMBER(50%),10)

Actual result
#NAME?

Documented / expected
0.5

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, not published: TO_PURE_NUMBER(50%) is printed in Sample Usage with no result. The rule is the page's own "If value is a number or a reference to a cell containing a numeric value, TO_PURE_NUMBER returns value with all formatting and interpretation removed", and 50% is the literal the page itself chose. Derived independently: a percent literal is one hundredth of its face value, so 50% is 0.5. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_PURE_NUMBER page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094243.; MISMATCH vs expected: expected 0.5, got '#NAME?'
TO_TEXT Excel for the web

=RIGHT(TO_TEXT(TO_PERCENT(0.5)),1)

Actual result
#NAME?

Documented / expected
%

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "Currencies appear as currencies, decimals as decimals, percentages as percentages, and dates as dates." THE PAGE NEVER STATES A DIGIT COUNT OR A FORMAT PATTERN, so no full string is asserted here -- "50%", "50.00%" and "50.0%" are all consistent with what it says. What the sentence does license is that the result still reads as a percentage, and the last character is the smallest observable form of that claim. Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected '%', got '#NAME?'
TO_TEXT LibreOffice Calc

=RIGHT(TO_TEXT(TO_PERCENT(0.5)),1)

Actual result
#NAME?

Documented / expected
%

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "Currencies appear as currencies, decimals as decimals, percentages as percentages, and dates as dates." THE PAGE NEVER STATES A DIGIT COUNT OR A FORMAT PATTERN, so no full string is asserted here -- "50%", "50.00%" and "50.0%" are all consistent with what it says. What the sentence does license is that the result still reads as a percentage, and the last character is the smallest observable form of that claim. Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected '%', got '#NAME?'
TO_TEXT Excel for the web

=TO_TEXT("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_TEXT returns value without modification." Note this makes the function idempotent on text, which is the only reading under which the Notes bullet "TO_TEXT is equivalent to prefixing a number with an apostrophe (')" does not double up its own apostrophe. Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_TEXT LibreOffice Calc

=TO_TEXT("abc")

Actual result
#NAME?

Documented / expected
abc

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "If value is not a number or a reference to a cell containing a numeric value, TO_TEXT returns value without modification." Note this makes the function idempotent on text, which is the only reading under which the Notes bullet "TO_TEXT is equivalent to prefixing a number with an apostrophe (')" does not double up its own apostrophe. Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected 'abc', got '#NAME?'
TO_TEXT Excel for the web

=ISTEXT(TO_TEXT(24))

Actual result
False

Documented / expected
True

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED, not published: TO_TEXT(24) is printed in Sample Usage with no result. The rule is "If value is a number or a reference to a cell containing a numeric value, TO_TEXT returns value as a string". BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_TEXT LibreOffice Calc

=ISTEXT(TO_TEXT(24))

Actual result
False

Documented / expected
True

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED, not published: TO_TEXT(24) is printed in Sample Usage with no result. The rule is "If value is a number or a reference to a cell containing a numeric value, TO_TEXT returns value as a string". BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285. WHAT THIS CASE LOOKS LIKE IN AN ENGINE THAT LACKS THE FUNCTION, SAID HERE SO THE ROW IS NOT MISREAD. The assertion is wrapped in an IS* predicate, and a predicate does not propagate #NAME? -- it answers it. On all four LibreOffice builds, where this function does not exist, the case therefore returns a plain FALSE rather than the #NAME? its unwrapped siblings return. That FALSE is a correct answer to the question the predicate asks and a misleading one about the engine, so it is recorded as a mismatch and the function's LibreOffice verdict is carried by the unwrapped cases in the same file, which do return #NAME?. (Batch H hit the same masking trap from the other side, where COUNTA(QUERY(...)) counted an error cell as one value and returned a plausible 1.); MISMATCH vs expected: expected True, got False
TO_TEXT Excel for the web

=TO_TEXT(24)

Actual result
#NAME?

Documented / expected
24

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Parser

DERIVED from "returns value as a string, with existing formatting retained". The page's own sample argument carries no format, so the retained formatting is none and the string is the bare digits. This is the weakest reading of the sentence that is still a testable claim: no assertion is made about how a FORMATTED number renders, because the page describes that only qualitatively (see the next case). Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected '24', got '#NAME?'
TO_TEXT LibreOffice Calc

=TO_TEXT(24)

Actual result
#NAME?

Documented / expected
24

Engine
LibreOffice Calc 25.8.7.3

Category
Parser

DERIVED from "returns value as a string, with existing formatting retained". The page's own sample argument carries no format, so the retained formatting is none and the string is the bare digits. This is the weakest reading of the sentence that is still a testable claim: no assertion is made about how a FORMATTED number renders, because the page describes that only qualitatively (see the next case). Google's TO_TEXT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3094285.; MISMATCH vs expected: expected '24', got '#NAME?'
TRIM LibreOffice Calc

=TRIM(CHAR(160)&"Hello"&CHAR(160))

Actual result
�Hello�

Documented / expected
Hello

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft docs state explicitly: "by itself, the TRIM function does not remove the nonbreaking space character (which has a decimal value of 160 and is commonly used in web pages as the HTML entity )." Source: https://support.microsoft.com/en-us/office/trim-function-410388fa-c5df-49c6-b16c-9e5630b479f9; MISMATCH vs expected: expected '\xa0Hello\xa0', got '�Hello�'
TRIM Google Sheets

=TRIM(CHAR(9)&"Hello")

Actual result
Hello

Documented / expected
U+0009Hello

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Text

Microsoft docs: "the TRIM function was designed to trim the 7-bit ASCII space character (value 32) from text" -- it does not generalize to other whitespace. Source: https://support.microsoft.com/en-us/office/trim-function-410388fa-c5df-49c6-b16c-9e5630b479f9; MISMATCH vs expected: expected '\tHello', got 'Hello'
TRIMRANGE Google Sheets

=COUNT(TRIMRANGE(A1:E10))

Actual result
0

Documented / expected
4

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

COUNT tallies numeric cells, so it reports 4 whether or not the blanks were trimmed -- but paired with the ROWS case below it pins the shape down. The data block B3:C4 holds exactly four numbers.; MISMATCH vs expected: expected 4, got 0
TRIMRANGE LibreOffice Calc

=COUNT(TRIMRANGE(A1:E10))

Actual result
0

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

COUNT tallies numeric cells, so it reports 4 whether or not the blanks were trimmed -- but paired with the ROWS case below it pins the shape down. The data block B3:C4 holds exactly four numbers.; MISMATCH vs expected: expected 4, got 0
TRIMRANGE Google Sheets

=SUM(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
10

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

THE PAGE PUBLISHES NO EXAMPLE TABLE AND NO ERROR REMARKS AT ALL -- every value in this file is derived from the prose, and that is said out loud rather than dressed up as a citation. What the page does document: "=TRIMRANGE(range,[trim_rows],[trim_cols])", with trim_rows and trim_cols each taking 0 = None, 1 = leading, 2 = trailing, 3 = both, and 3 as the default for each. A1:E10 IS DELIBERATELY MOSTLY BLANK: only B3:C4 holds data (1, 2, 3, 4), so trimming both leading and trailing blank rows and columns must reduce A1:E10 to exactly B3:C4, whose sum is 10. SUM is wrapped around the call because TRIMRANGE returns a RANGE rather than a scalar, and a sum is the cheapest assertion that depends on the whole trimmed shape. Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/trimrange-function. FETCH NOTE FOR THIS BATCH: batch F recorded every /en-us/office/<name>-function-<guid> URL returning Microsoft's 'Sorry, the page you're looking for can't be found' body; today BOTH paths serve the article again -- the GUID form redirects to /en-us/excel/functions/<slug>-function -- and every page cited in this batch came back complete (217-223 KB) in one or two attempts, with no 87 KB stub responses. Nothing here is sourced from a search snippet or a mirror.; MISMATCH vs expected: expected 10, got '#NAME?'
TRIMRANGE LibreOffice Calc

=SUM(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
10

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

THE PAGE PUBLISHES NO EXAMPLE TABLE AND NO ERROR REMARKS AT ALL -- every value in this file is derived from the prose, and that is said out loud rather than dressed up as a citation. What the page does document: "=TRIMRANGE(range,[trim_rows],[trim_cols])", with trim_rows and trim_cols each taking 0 = None, 1 = leading, 2 = trailing, 3 = both, and 3 as the default for each. A1:E10 IS DELIBERATELY MOSTLY BLANK: only B3:C4 holds data (1, 2, 3, 4), so trimming both leading and trailing blank rows and columns must reduce A1:E10 to exactly B3:C4, whose sum is 10. SUM is wrapped around the call because TRIMRANGE returns a RANGE rather than a scalar, and a sum is the cheapest assertion that depends on the whole trimmed shape. Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/trimrange-function. FETCH NOTE FOR THIS BATCH: batch F recorded every /en-us/office/<name>-function-<guid> URL returning Microsoft's 'Sorry, the page you're looking for can't be found' body; today BOTH paths serve the article again -- the GUID form redirects to /en-us/excel/functions/<slug>-function -- and every page cited in this batch came back complete (217-223 KB) in one or two attempts, with no 87 KB stub responses. Nothing here is sourced from a search snippet or a mirror.; MISMATCH vs expected: expected 10, got '#NAME?'
TRIMRANGE Google Sheets

=ROWS(TRIMRANGE(A1:E10,1,1))

Actual result
#NAME?

Documented / expected
8

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

With trim_rows = 1 ("1 - Trims leading blank rows") the two blank rows before the data are removed and THE SIX BLANK ROWS AFTER IT ARE DELIBERATELY LEFT, so A1:E10 becomes A3:E10 -- eight rows. Derived from the prose; the page publishes no worked example of any trim code. This case and the trailing one below are what separate the three non-zero codes from each other, which the default case cannot do.; MISMATCH vs expected: expected 8, got '#NAME?'
TRIMRANGE LibreOffice Calc

=ROWS(TRIMRANGE(A1:E10,1,1))

Actual result
#NAME?

Documented / expected
8

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

With trim_rows = 1 ("1 - Trims leading blank rows") the two blank rows before the data are removed and THE SIX BLANK ROWS AFTER IT ARE DELIBERATELY LEFT, so A1:E10 becomes A3:E10 -- eight rows. Derived from the prose; the page publishes no worked example of any trim code. This case and the trailing one below are what separate the three non-zero codes from each other, which the default case cannot do.; MISMATCH vs expected: expected 8, got '#NAME?'
TRIMRANGE Google Sheets

=SUM(TRIMRANGE(A1:E10,0,0))

Actual result
#NAME?

Documented / expected
10

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

With trim_rows = 0 and trim_cols = 0 -- both documented as "0 - None" -- nothing is trimmed and the range stays A1:E10, WHICH IS DELIBERATELY FULL OF BLANK CELLS. The sum is still 10 because blanks contribute nothing to SUM, so this case does NOT prove the range was left untrimmed; it proves only that the 0 codes are accepted and do not error. The shape difference between this and the case above is invisible to SUM, which is stated here rather than glossed: a sharper test would need a function sensitive to the range's dimensions, and ROWS/COLUMNS of a trimmed reference is exactly the sort of thing an engine without TRIMRANGE cannot be asked.; MISMATCH vs expected: expected 10, got '#NAME?'
TRIMRANGE LibreOffice Calc

=SUM(TRIMRANGE(A1:E10,0,0))

Actual result
#NAME?

Documented / expected
10

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

With trim_rows = 0 and trim_cols = 0 -- both documented as "0 - None" -- nothing is trimmed and the range stays A1:E10, WHICH IS DELIBERATELY FULL OF BLANK CELLS. The sum is still 10 because blanks contribute nothing to SUM, so this case does NOT prove the range was left untrimmed; it proves only that the 0 codes are accepted and do not error. The shape difference between this and the case above is invisible to SUM, which is stated here rather than glossed: a sharper test would need a function sensitive to the range's dimensions, and ROWS/COLUMNS of a trimmed reference is exactly the sort of thing an engine without TRIMRANGE cannot be asked.; MISMATCH vs expected: expected 10, got '#NAME?'
TRIMRANGE Google Sheets

=ROWS(TRIMRANGE(A1:E10,2,2))

Actual result
#NAME?

Documented / expected
4

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

With trim_rows = 2 ("2 - Trims trailing blank rows") the six blank rows after the data are removed and THE TWO BLANK ROWS BEFORE IT ARE DELIBERATELY LEFT, so A1:E10 becomes A1:E4 -- four rows. The page documents the equivalent Trim Refs operator spellings for these codes in a table that is worth recording as published, typo and all: "Trim All (.:.) | A1.:.E10 | TRIMRANGE(A1:E10,3,3)", "Trim Trailing (:.) | A1:.E10 | TRIMRANGE(A1:E10,2,2)", "Trim Leading (.:) | A1.:Z10 | TRIMRANGE(A1:E10,1,1)" -- note the third row's example says Z10 where its equivalent says E10, which is a slip in Microsoft's own table.; MISMATCH vs expected: expected 4, got '#NAME?'
TRIMRANGE LibreOffice Calc

=ROWS(TRIMRANGE(A1:E10,2,2))

Actual result
#NAME?

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

With trim_rows = 2 ("2 - Trims trailing blank rows") the six blank rows after the data are removed and THE TWO BLANK ROWS BEFORE IT ARE DELIBERATELY LEFT, so A1:E10 becomes A1:E4 -- four rows. The page documents the equivalent Trim Refs operator spellings for these codes in a table that is worth recording as published, typo and all: "Trim All (.:.) | A1.:.E10 | TRIMRANGE(A1:E10,3,3)", "Trim Trailing (:.) | A1:.E10 | TRIMRANGE(A1:E10,2,2)", "Trim Leading (.:) | A1.:Z10 | TRIMRANGE(A1:E10,1,1)" -- note the third row's example says Z10 where its equivalent says E10, which is a slip in Microsoft's own table.; MISMATCH vs expected: expected 4, got '#NAME?'
TRIMRANGE Google Sheets

=COLUMNS(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
2

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

The column half of the same assertion: five columns A through E trim to the two, B and C, that hold data. Derived from the documented default trim_cols = 3.; MISMATCH vs expected: expected 2, got '#NAME?'
TRIMRANGE LibreOffice Calc

=COLUMNS(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

The column half of the same assertion: five columns A through E trim to the two, B and C, that hold data. Derived from the documented default trim_cols = 3.; MISMATCH vs expected: expected 2, got '#NAME?'
TRIMRANGE Google Sheets

=ROWS(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
2

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Lookup and reference

THIS IS THE CASE THAT MAKES THE FILE MEAN SOMETHING. A1:E10 IS TEN ROWS OF MOSTLY BLANK CELLS; trimmed to its data block B3:C4 it is two. ROWS() reads the reference's shape rather than its values, so an engine that accepted TRIMRANGE but ignored it would return 10 here and pass every other case in this file. Derived from the documented default trim_rows = 3 ("Trims both leading and trailing blank rows"), not from any published example -- there is none.; MISMATCH vs expected: expected 2, got '#NAME?'
TRIMRANGE LibreOffice Calc

=ROWS(TRIMRANGE(A1:E10))

Actual result
#NAME?

Documented / expected
2

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

THIS IS THE CASE THAT MAKES THE FILE MEAN SOMETHING. A1:E10 IS TEN ROWS OF MOSTLY BLANK CELLS; trimmed to its data block B3:C4 it is two. ROWS() reads the reference's shape rather than its values, so an engine that accepted TRIMRANGE but ignored it would return 10 here and pass every other case in this file. Derived from the documented default trim_rows = 3 ("Trims both leading and trailing blank rows"), not from any published example -- there is none.; MISMATCH vs expected: expected 2, got '#NAME?'
TTEST LibreOffice Calc

=TTEST({1,2,3},{4,5,6},3,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If tails is any value other than 1 or 2, TTEST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
TTEST LibreOffice Calc

=TTEST({1,2,3},{1,2},2,1)

Actual result
#VALUE!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The TTEST Remarks publish the same rule as T.TEST: "If array1 and array2 have a different number of data points, and type = 1 (paired), TTEST returns the #N/A error value."; MISMATCH vs expected: expected '#N/A', got '#VALUE!'
TYPE Excel for the web

=TYPE(A1:A3)

Actual result
1

Documented / expected
64

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Information

MISMATCH vs expected: expected 64, got 1
TYPE Google Sheets

=TYPE(A1:A3)

Actual result
1

Documented / expected
64

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Information

MISMATCH vs expected: expected 64, got 1
TYPE LibreOffice Calc

=TYPE(A1:A3)

Actual result
1

Documented / expected
64

Engine
LibreOffice Calc 25.8.7.3

Category
Information

MISMATCH vs expected: expected 64, got 1
TYPE LibreOffice Calc

=TYPE(TRUE)

Actual result
1

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Information

MISMATCH vs expected: expected 4, got 1
UMINUS Excel for the web

=ROUND(UMINUS(UMINUS(9)),10)

Actual result
#NAME?

Documented / expected
9

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from the same one-line description: reversing a sign twice restores it. Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 9, got '#NAME?'
UMINUS LibreOffice Calc

=ROUND(UMINUS(UMINUS(9)),10)

Actual result
#NAME?

Documented / expected
9

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from the same one-line description: reversing a sign twice restores it. Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 9, got '#NAME?'
UMINUS Excel for the web

=ROUND(UMINUS(3.5)-(3.5*-1),12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from the parameter description "value - The number to have its sign reversed. Equivalently, the number to multiply by -1." Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 0, got '#NAME?'
UMINUS LibreOffice Calc

=ROUND(UMINUS(3.5)-(3.5*-1),12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from the parameter description "value - The number to have its sign reversed. Equivalently, the number to multiply by -1." Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 0, got '#NAME?'
UMINUS Excel for the web

=UMINUS(7)

Actual result
#NAME?

Documented / expected
-7

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

DERIVED from the same sentence. The page gives only a negative sample, so the positive direction is asserted here to pin "sign reversed" rather than "absolute value" -- two readings the page's single sample cannot distinguish. Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected -7, got '#NAME?'
UMINUS LibreOffice Calc

=UMINUS(7)

Actual result
#NAME?

Documented / expected
-7

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

DERIVED from the same sentence. The page gives only a negative sample, so the positive direction is asserted here to pin "sign reversed" rather than "absolute value" -- two readings the page's single sample cannot distinguish. Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected -7, got '#NAME?'
UMINUS Excel for the web

=UMINUS(-4)

Actual result
#NAME?

Documented / expected
4

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

DERIVED, not published: UMINUS(-4) is printed in Sample Usage with no result. The rule is the page's one-line description, "Returns a number with the sign reversed". BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 4, got '#NAME?'
UMINUS LibreOffice Calc

=UMINUS(-4)

Actual result
#NAME?

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

DERIVED, not published: UMINUS(-4) is printed in Sample Usage with no result. The rule is the page's one-line description, "Returns a number with the sign reversed". BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UMINUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093606.; MISMATCH vs expected: expected 4, got '#NAME?'
UNARY_PERCENT Excel for the web

=ROUND(UNARY_PERCENT(50)-50%,12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant, from "Returns a value interpreted as a percentage": whatever the engine means by the literal 50%, UNARY_PERCENT(50) must mean the same thing. This is the case that would catch an implementation that divided by 100 only for display. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 0, got '#NAME?'
UNARY_PERCENT LibreOffice Calc

=ROUND(UNARY_PERCENT(50)-50%,12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant, from "Returns a value interpreted as a percentage": whatever the engine means by the literal 50%, UNARY_PERCENT(50) must mean the same thing. This is the case that would catch an implementation that divided by 100 only for display. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 0, got '#NAME?'
UNARY_PERCENT Excel for the web

=ROUND(UNARY_PERCENT(UNARY_PERCENT(10000)),10)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion. THE PAGE'S OWN INVERSE CLAIM IS DELIBERATELY NOT ASSERTED: the Notes bullet says "UNARY_PERCENT is roughly equivalent to the inverse of TO_PERCENT", and the word ROUGHLY is doing real work -- TO_PERCENT changes a format and leaves the value alone, while UNARY_PERCENT changes the value, so the two are not inverses at the value layer at all and a case asserting that they are would be asserting something the page hedges. What is asserted instead is the unhedged rule applied twice: 10000 -> 100 -> 1. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 1, got '#NAME?'
UNARY_PERCENT LibreOffice Calc

=ROUND(UNARY_PERCENT(UNARY_PERCENT(10000)),10)

Actual result
#NAME?

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion. THE PAGE'S OWN INVERSE CLAIM IS DELIBERATELY NOT ASSERTED: the Notes bullet says "UNARY_PERCENT is roughly equivalent to the inverse of TO_PERCENT", and the word ROUGHLY is doing real work -- TO_PERCENT changes a format and leaves the value alone, while UNARY_PERCENT changes the value, so the two are not inverses at the value layer at all and a case asserting that they are would be asserting something the page hedges. What is asserted instead is the unhedged rule applied twice: 10000 -> 100 -> 1. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 1, got '#NAME?'
UNARY_PERCENT Excel for the web

=UNARY_PERCENT(100)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

GOOGLE'S OWN PUBLISHED RESULT, and the single exception to this group's rule that nothing is published: UNARY_PERCENT's one-line description reads, verbatim, "Returns a value interpreted as a percentage; that is, `UNARY_PERCENT(100)` equals `1`." It is not in a Formula/Result table -- it is inside the sentence -- but it is a formula and its result, printed in the article body, so it is quoted here as published rather than derived. The same sentence is repeated verbatim in the See Also blocks of the TO_PERCENT and UPLUS pages. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 1, got '#NAME?'
UNARY_PERCENT LibreOffice Calc

=UNARY_PERCENT(100)

Actual result
#NAME?

Documented / expected
1

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

GOOGLE'S OWN PUBLISHED RESULT, and the single exception to this group's rule that nothing is published: UNARY_PERCENT's one-line description reads, verbatim, "Returns a value interpreted as a percentage; that is, `UNARY_PERCENT(100)` equals `1`." It is not in a Formula/Result table -- it is inside the sentence -- but it is a formula and its result, printed in the article body, so it is quoted here as published rather than derived. The same sentence is repeated verbatim in the See Also blocks of the TO_PERCENT and UPLUS pages. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 1, got '#NAME?'
UNARY_PERCENT Excel for the web

=ROUND(UNARY_PERCENT(93),10)

Actual result
#NAME?

Documented / expected
0.93

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

DERIVED from the published 100 -> 1 relation applied to the page's other Sample Usage formula, UNARY_PERCENT(93), which is printed with no result: a value interpreted as a percentage is one hundredth of its face value, so 93 gives 0.93. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 0.93, got '#NAME?'
UNARY_PERCENT LibreOffice Calc

=ROUND(UNARY_PERCENT(93),10)

Actual result
#NAME?

Documented / expected
0.93

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

DERIVED from the published 100 -> 1 relation applied to the page's other Sample Usage formula, UNARY_PERCENT(93), which is printed with no result: a value interpreted as a percentage is one hundredth of its face value, so 93 gives 0.93. Google's UNARY_PERCENT page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093982.; MISMATCH vs expected: expected 0.93, got '#NAME?'
UNICHAR LibreOffice Calc

=UNICHAR(0)

Actual result
_x0000_

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Text

MISMATCH vs expected: expected '#VALUE!', got '_x0000_'
UPLUS Excel for the web

=ROUND(UPLUS(3.5)-3.5,12)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion from "Returns a specified number, unchanged": the difference between the result and the argument is zero. A non-integer argument is used so the case would also catch an implementation that truncated. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 0, got '#NAME?'
UPLUS LibreOffice Calc

=ROUND(UPLUS(3.5)-3.5,12)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion from "Returns a specified number, unchanged": the difference between the result and the argument is zero. A non-integer argument is used so the case would also catch an implementation that truncated. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 0, got '#NAME?'
UPLUS Excel for the web

=ROUND(UPLUS(UMINUS(9))+9,10)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

A structural assertion with no derived constant. Each of the two pages lists the other in its See Also block with a one-line summary, and the composition follows from those two summaries alone: UMINUS(9) reverses the sign and UPLUS returns it unchanged, so adding 9 gives zero. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 0, got '#NAME?'
UPLUS LibreOffice Calc

=ROUND(UPLUS(UMINUS(9))+9,10)

Actual result
#NAME?

Documented / expected
0

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

A structural assertion with no derived constant. Each of the two pages lists the other in its See Also block with a one-line summary, and the composition follows from those two summaries alone: UMINUS(9) reverses the sign and UPLUS returns it unchanged, so adding 9 gives zero. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 0, got '#NAME?'
UPLUS Excel for the web

=UPLUS(7)

Actual result
#NAME?

Documented / expected
7

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

DERIVED from the same sentence. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 7, got '#NAME?'
UPLUS LibreOffice Calc

=UPLUS(7)

Actual result
#NAME?

Documented / expected
7

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

DERIVED from the same sentence. Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected 7, got '#NAME?'
UPLUS Excel for the web

=UPLUS(-4)

Actual result
#NAME?

Documented / expected
-4

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Operator

DERIVED, not published: UPLUS(-4) is printed in Sample Usage with no result. The rule is the page's one-line description, "Returns a specified number, unchanged", and its parameter description "value - The number to return". The sample is deliberately negative, which is the case that separates UPLUS from ABS. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected -4, got '#NAME?'
UPLUS LibreOffice Calc

=UPLUS(-4)

Actual result
#NAME?

Documented / expected
-4

Engine
LibreOffice Calc 25.8.7.3

Category
Operator

DERIVED, not published: UPLUS(-4) is printed in Sample Usage with no result. The rule is the page's one-line description, "Returns a specified number, unchanged", and its parameter description "value - The number to return". The sample is deliberately negative, which is the case that separates UPLUS from ABS. BATCH PROVENANCE (batch I, group 1 -- the last eight Google-documented functions in the corpus, closing the group A set sheets-lo-only-plan.md opened). This function has x == false in docs/data/compat.json: Microsoft does not document it at all, so this corpus makes NO claim about it in that engine and nothing here is measured against that vendor's documentation. The authority is Google's own support.google.com function page, cited by full URL and by the date it was read (2026-08-31) -- Google publishes no version number for these pages, so a bare URL dates nothing. WHAT GOOGLE PRINTS ON THESE EIGHT PAGES IS LESS THAN IT LOOKS, AND EVERY NOTE SAYS SO. Each page carries a 'Sample Usage' block of FORMULAS WITH NO RESULTS and an 'Examples' section that is a live embedded spreadsheet rather than article text, so ACROSS ALL EIGHT PAGES THERE IS NOT ONE PUBLISHED FORMULA/RESULT PAIR IN THE BODY. Every expected value in this group is therefore DERIVED from the page's own stated semantics and names the sentence it came from; the one exception is UNARY_PERCENT, whose one-line description states its result inline. No value was taken from a search snippet, a blog or a mirror. LIBREOFFICE: probed before execution on all four pinned builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) in five storage spellings -- plain, _xlfn., COM.MICROSOFT., ORG.OPENOFFICE. and _xlfn.ORG.OPENOFFICE. -- and #NAME? under every one of them on every build, so the expected values below describe Google Sheets and the LibreOffice column records absence. (A separate check confirms the absence is real rather than a name-mapping artefact: round-tripping these eight names through LibreOffice's own formula parser and its .xlsx export writes them back lower-cased -- 'to_date', 'uminus' -- which is what LibreOffice does with an identifier it does not recognise as a function at all.) Google's UPLUS page, read live on 2026-08-31 at https://support.google.com/docs/answer/3093608.; MISMATCH vs expected: expected -4, got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A2,0)

Actual result
#NAME?

Documented / expected
TRUE

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft publishes =VALUETOTEXT(A2, 0) = TRUE for A2 = TRUE. Format 0 is documented as "Concise format that is easy to read. The text returned will be the same as the text rendered in a cell that has general formatting applied." Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/valuetotext-function. FETCH NOTE FOR THIS BATCH: batch F recorded every /en-us/office/<name>-function-<guid> URL returning Microsoft's 'Sorry, the page you're looking for can't be found' body; today BOTH paths serve the article again -- the GUID form redirects to /en-us/excel/functions/<slug>-function -- and every page cited in this batch came back complete (217-223 KB) in one or two attempts, with no 87 KB stub responses. Nothing here is sourced from a search snippet or a mirror.; MISMATCH vs expected: expected 'TRUE', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A2,0)

Actual result
#NAME?

Documented / expected
TRUE

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft publishes =VALUETOTEXT(A2, 0) = TRUE for A2 = TRUE. Format 0 is documented as "Concise format that is easy to read. The text returned will be the same as the text rendered in a cell that has general formatting applied." Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/valuetotext-function. FETCH NOTE FOR THIS BATCH: batch F recorded every /en-us/office/<name>-function-<guid> URL returning Microsoft's 'Sorry, the page you're looking for can't be found' body; today BOTH paths serve the article again -- the GUID form redirects to /en-us/excel/functions/<slug>-function -- and every page cited in this batch came back complete (217-223 KB) in one or two attempts, with no 87 KB stub responses. Nothing here is sourced from a search snippet or a mirror.; MISMATCH vs expected: expected 'TRUE', got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A3,0)

Actual result
#NAME?

Documented / expected
1234.01234

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft publishes =VALUETOTEXT(A3, 0) = 1234.01234. The published Strict row for the same cell is ALSO 1234.01234, because the page documents strict format as encapsulating "returned strings in quotes except for Booleans, Numbers and Errors" -- numbers are one of the three exceptions.; MISMATCH vs expected: expected '1234.01234', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A3,0)

Actual result
#NAME?

Documented / expected
1234.01234

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft publishes =VALUETOTEXT(A3, 0) = 1234.01234. The published Strict row for the same cell is ALSO 1234.01234, because the page documents strict format as encapsulating "returned strings in quotes except for Booleans, Numbers and Errors" -- numbers are one of the three exceptions.; MISMATCH vs expected: expected '1234.01234', got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A4,0)

Actual result
#NAME?

Documented / expected
Hello

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft publishes =VALUETOTEXT(A4, 0) = Hello, with no quotation marks. This is the concise half of the pair that defines the format argument.; MISMATCH vs expected: expected 'Hello', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A4,0)

Actual result
#NAME?

Documented / expected
Hello

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft publishes =VALUETOTEXT(A4, 0) = Hello, with no quotation marks. This is the concise half of the pair that defines the format argument.; MISMATCH vs expected: expected 'Hello', got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A4,2)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

The Remarks publish: "If format is anything other than 0 or 1, VALUETOTEXT returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A4,2)

Actual result
#NAME?

Documented / expected
#VALUE!

Engine
LibreOffice Calc 25.8.7.3

Category
Text

The Remarks publish: "If format is anything other than 0 or 1, VALUETOTEXT returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A6,1)

Actual result
#NAME?

Documented / expected
"Seattle"

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft publishes =VALUETOTEXT(A6, 1) = "Seattle". Asserted alongside the Hello pair so the quoting behaviour rests on two independent strings rather than one.; MISMATCH vs expected: expected '"Seattle"', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A6,1)

Actual result
#NAME?

Documented / expected
"Seattle"

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft publishes =VALUETOTEXT(A6, 1) = "Seattle". Asserted alongside the Hello pair so the quoting behaviour rests on two independent strings rather than one.; MISMATCH vs expected: expected '"Seattle"', got '#NAME?'
VALUETOTEXT Google Sheets

=VALUETOTEXT(A4,1)

Actual result
#NAME?

Documented / expected
"Hello"

Engine
Google Sheets, executed 2026-08-31 (Drive import)

Category
Text

Microsoft publishes =VALUETOTEXT(A4, 1) = "Hello" WITH the quotation marks, against the unquoted Hello from format 0 on the identical cell. THIS PAIR IS THE ONLY THING IN THE PUBLISHED TABLE THAT DISTINGUISHES THE TWO FORMATS: rows A2, A3, A5 and A7 (a Boolean, two numbers and an error) print identically under both formats, so an engine that ignored the format argument entirely would pass four of the six documented rows. The expected value here contains literal double-quote characters as part of the string.; MISMATCH vs expected: expected '"Hello"', got '#NAME?'
VALUETOTEXT LibreOffice Calc

=VALUETOTEXT(A4,1)

Actual result
#NAME?

Documented / expected
"Hello"

Engine
LibreOffice Calc 25.8.7.3

Category
Text

Microsoft publishes =VALUETOTEXT(A4, 1) = "Hello" WITH the quotation marks, against the unquoted Hello from format 0 on the identical cell. THIS PAIR IS THE ONLY THING IN THE PUBLISHED TABLE THAT DISTINGUISHES THE TWO FORMATS: rows A2, A3, A5 and A7 (a Boolean, two numbers and an error) print identically under both formats, so an engine that ignored the format argument entirely would pass four of the six documented rows. The expected value here contains literal double-quote characters as part of the string.; MISMATCH vs expected: expected '"Hello"', got '#NAME?'
VAR.P LibreOffice Calc

=ROUND(VAR.P(A1:A3),4)

Actual result
8.2222

Documented / expected
4

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

Microsoft documents logical values in a reference as ignored by VAR.P. Data 4 and 8, mean 6, squared deviations 4+4 = 8, divided by n = 2 gives 4; MISMATCH vs expected: expected 4, got 8.2222
VDB LibreOffice Calc

=VDB(2400,300,-10,0,1)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

DERIVED, not quoted: Microsoft's VDB page states 'All arguments except no_switch must be positive numbers' but does not name the error code. #NUM! is Excel's documented error for an out-of-domain argument across the rest of the depreciation family (DB, DDB, SLN, SYD all document #NUM! for a negative life), so #NUM! is what is asserted here; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
VLOOKUP LibreOffice Calc

=VLOOKUP("a",A1:B3,5,FALSE)

Actual result
#VALUE!

Documented / expected
#REF!

Engine
LibreOffice Calc 25.8.7.3

Category
Lookup and reference

Microsoft docs specify #REF! for out-of-range col_index_num; record engines' ACTUAL error code here since this is a known point of cross-engine divergence; MISMATCH vs expected: expected '#REF!', got '#VALUE!'
WEEKDAY LibreOffice Calc

=WEEKDAY(DATE(2008,2,14),99)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Microsoft docs: an invalid return_type raises #NUM!.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
WEEKNUM_OOO Excel for the web

=WEEKNUM_OOO(DATE(1995,1,1),5)-WEEKNUM_OOO(DATE(1995,1,1),2)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

A structural assertion with no derived constant, from the Mode parameter's own list: "1 = Sunday / 2 = Monday (ISO 8601) / any other value = Monday (ISO 8601)". Mode 5 is 'any other value', so it must agree with mode 2 exactly. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKNUM_OOO Google Sheets

=WEEKNUM_OOO(DATE(1995,1,1),5)-WEEKNUM_OOO(DATE(1995,1,1),2)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

A structural assertion with no derived constant, from the Mode parameter's own list: "1 = Sunday / 2 = Monday (ISO 8601) / any other value = Monday (ISO 8601)". Mode 5 is 'any other value', so it must agree with mode 2 exactly. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKNUM_OOO Excel for the web

=WEEKNUM_OOO(DATE(1995,1,1),1)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKNUM_OOO(DATE(1995;1;1);1) returns 1". Mode 1 is documented as Sunday-start, and 1995-01-01 was a Sunday, so it opens week 1. THIS FUNCTION EXISTS ONLY AS A COMPATIBILITY SHIM AND THE PAGE SAYS SO: "This function exists for interoperability with LibreOffice releases older than 5.1.0 and OpenOffice.org. It calculates week numbers for a week numbering system in that week number 1 is the week that contains the January 4th. This function does not provide interoperability with other spreadsheet applications. For new documents use the WEEKNUM or ISOWEEKNUM function instead." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKNUM_OOO Google Sheets

=WEEKNUM_OOO(DATE(1995,1,1),1)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKNUM_OOO(DATE(1995;1;1);1) returns 1". Mode 1 is documented as Sunday-start, and 1995-01-01 was a Sunday, so it opens week 1. THIS FUNCTION EXISTS ONLY AS A COMPATIBILITY SHIM AND THE PAGE SAYS SO: "This function exists for interoperability with LibreOffice releases older than 5.1.0 and OpenOffice.org. It calculates week numbers for a week numbering system in that week number 1 is the week that contains the January 4th. This function does not provide interoperability with other spreadsheet applications. For new documents use the WEEKNUM or ISOWEEKNUM function instead." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKNUM_OOO Excel for the web

=WEEKNUM_OOO(DATE(1995,1,1),2)

Actual result
#NAME?

Documented / expected
52

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim including its explanation: "=WEEKNUM_OOO(DATE(1995;1;1);2) returns 52. Week 1 starts on Monday, 1995-01-02." This pair of published examples is the sharpest thing in the batch: the SAME DATE returns 1 or 52 depending only on the Mode argument, so the case cannot be passed by an implementation that ignores it. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 52, got '#NAME?'
WEEKNUM_OOO Google Sheets

=WEEKNUM_OOO(DATE(1995,1,1),2)

Actual result
#NAME?

Documented / expected
52

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim including its explanation: "=WEEKNUM_OOO(DATE(1995;1;1);2) returns 52. Week 1 starts on Monday, 1995-01-02." This pair of published examples is the sharpest thing in the batch: the SAME DATE returns 1 or 52 depending only on the Mode argument, so the case cannot be passed by an implementation that ignores it. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 52, got '#NAME?'
WEEKNUM_OOO Excel for the web

=WEEKNUM_OOO(DATE(2021,1,4),2)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the page's own definition of the numbering system it implements: "week number 1 is the week that contains the January 4th". 4 January 2021 must therefore be in week 1 whatever weekday it falls on -- it was a Monday. This is the defining property, asserted directly rather than through a published example. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKNUM_OOO Google Sheets

=WEEKNUM_OOO(DATE(2021,1,4),2)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the page's own definition of the numbering system it implements: "week number 1 is the week that contains the January 4th". 4 January 2021 must therefore be in week 1 whatever weekday it falls on -- it was a Monday. This is the defining property, asserted directly rather than through a published example. LibreOffice's WEEKNUM_OOO help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/func_weeknum_ooo.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKS Excel for the web

=WEEKS("2022-01-12","2022-01-17",0)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-17",0) returns 0 because Type was set to 0 and there are only 5 days in the interval." All four of this file's published cases keep the page's own ISO-8601 date STRINGS rather than converting them to DATE() calls, because the page introduces them deliberately -- "In the following examples, dates are passed as strings. However, they can also be stored in separate cells and be passed as references" -- and the string form is therefore part of what is published. Type 0 is documented as "the function will assume that 7 days is equivalent to one week without considering any specific day to mark the beginning of a week." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKS Google Sheets

=WEEKS("2022-01-12","2022-01-17",0)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-17",0) returns 0 because Type was set to 0 and there are only 5 days in the interval." All four of this file's published cases keep the page's own ISO-8601 date STRINGS rather than converting them to DATE() calls, because the page introduces them deliberately -- "In the following examples, dates are passed as strings. However, they can also be stored in separate cells and be passed as references" -- and the string form is therefore part of what is published. Type 0 is documented as "the function will assume that 7 days is equivalent to one week without considering any specific day to mark the beginning of a week." STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKS Excel for the web

=WEEKS("2022-01-12","2022-01-19",0)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-19",0) returns 1 because Type was set to 0 and there are 7 days in the interval." With the case above this brackets the Type 0 boundary exactly: five days gives 0, seven days gives 1. LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKS Google Sheets

=WEEKS("2022-01-12","2022-01-19",0)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-19",0) returns 1 because Type was set to 0 and there are 7 days in the interval." With the case above this brackets the Type 0 boundary exactly: five days gives 0, seven days gives 1. LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKS Excel for the web

=WEEKS("2022-01-12","2022-01-17",1)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-17",1) returns 1 because Type was set to 1 and the interval contains a Monday, since 2022-01-12 is a Wednesday and 2022-01-17 is a Monday." THE SAME DATE PAIR AS THE FIRST CASE, with only the Type changed, and the answer changes from 0 to 1 -- so this pair is what makes the Type argument observable. Type 1 is documented as "the function will consider Monday to be the first day of the week. Therefore, except for the start date, each occurrence of a Monday in the interval is counted as an additional week", and the page adds that it does so "regardless of the current locale settings." LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKS Google Sheets

=WEEKS("2022-01-12","2022-01-17",1)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-17",1) returns 1 because Type was set to 1 and the interval contains a Monday, since 2022-01-12 is a Wednesday and 2022-01-17 is a Monday." THE SAME DATE PAIR AS THE FIRST CASE, with only the Type changed, and the answer changes from 0 to 1 -- so this pair is what makes the Type argument observable. Type 1 is documented as "the function will consider Monday to be the first day of the week. Therefore, except for the start date, each occurrence of a Monday in the interval is counted as an additional week", and the page adds that it does so "regardless of the current locale settings." LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
WEEKS Excel for the web

=WEEKS("2022-01-12","2022-01-15",1)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-15",1) returns 0 because Type was set to 1 and the interval does not contain any Mondays, except for the start date." LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKS Google Sheets

=WEEKS("2022-01-12","2022-01-15",1)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT, quoted verbatim: "=WEEKS("2022-01-12","2022-01-15",1) returns 0 because Type was set to 1 and the interval does not contain any Mondays, except for the start date." LibreOffice's WEEKS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
WEEKSINYEAR Excel for the web

=WEEKSINYEAR(DATE(2026,6,1))

Actual result
#NAME?

Documented / expected
53

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the same ISO rule. A year has 53 ISO weeks when it begins on a Thursday, or when it is a leap year beginning on a Wednesday; 1 January 2026 is a Thursday. Computed independently here from the ISO week-date calendar rather than looked up. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 53, got '#NAME?'
WEEKSINYEAR Google Sheets

=WEEKSINYEAR(DATE(2026,6,1))

Actual result
#NAME?

Documented / expected
53

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the same ISO rule. A year has 53 ISO weeks when it begins on a Thursday, or when it is a leap year beginning on a Wednesday; 1 January 2026 is a Thursday. Computed independently here from the ISO week-date calendar rather than looked up. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 53, got '#NAME?'
WEEKSINYEAR Excel for the web

=WEEKSINYEAR(DATE(2025,6,1))

Actual result
#NAME?

Documented / expected
52

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the ISO rule the page states. 1 January 2025 was a Wednesday and 2025 is not a leap year, so it has 52 ISO weeks. The page publishes only a 53-week year, so this is the case that shows the function is computing rather than returning a constant. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 52, got '#NAME?'
WEEKSINYEAR Google Sheets

=WEEKSINYEAR(DATE(2025,6,1))

Actual result
#NAME?

Documented / expected
52

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the ISO rule the page states. 1 January 2025 was a Wednesday and 2025 is not a leap year, so it has 52 ISO weeks. The page publishes only a 53-week year, so this is the case that shows the function is computing rather than returning a constant. LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 52, got '#NAME?'
WEEKSINYEAR Excel for the web

=WEEKSINYEAR(DATE(1970,2,17))

Actual result
#NAME?

Documented / expected
53

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "WEEKSINYEAR(A1) returns 53 if A1 contains 1970-02-17, a valid date for the year 1970." (The page prints the example without a leading '=', unlike its neighbours; the formula is otherwise as published, with DATE() substituted for the cell reference for the reason the sibling ISLEAPYEAR entry gives.) Derived independently as well: 1 January 1970 was a Thursday, and under the ISO rule the page states -- "Following ISO 8601, this function considers Monday to be the first day of the week, and the first week of a year is the one with most days in this year" -- a common year beginning on a Thursday has 53 ISO weeks. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 53, got '#NAME?'
WEEKSINYEAR Google Sheets

=WEEKSINYEAR(DATE(1970,2,17))

Actual result
#NAME?

Documented / expected
53

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

LIBREOFFICE'S OWN PUBLISHED RESULT: "WEEKSINYEAR(A1) returns 53 if A1 contains 1970-02-17, a valid date for the year 1970." (The page prints the example without a leading '=', unlike its neighbours; the formula is otherwise as published, with DATE() substituted for the cell reference for the reason the sibling ISLEAPYEAR entry gives.) Derived independently as well: 1 January 1970 was a Thursday, and under the ISO rule the page states -- "Following ISO 8601, this function considers Monday to be the first day of the week, and the first week of a year is the one with most days in this year" -- a common year beginning on a Thursday has 53 ISO weeks. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's WEEKSINYEAR help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 53, got '#NAME?'
WEIBULL LibreOffice Calc

=WEIBULL(105,0,100,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If alpha <= 0 or if beta <= 0, WEIBULL returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
WEIBULL LibreOffice Calc

=WEIBULL(-1,20,100,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If x < 0, WEIBULL returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
WEIBULL.DIST LibreOffice Calc

=WEIBULL.DIST(105,0,100,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If alpha <= 0 or if beta <= 0, WEIBULL.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
WEIBULL.DIST LibreOffice Calc

=WEIBULL.DIST(-1,20,100,TRUE)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If x < 0, WEIBULL.DIST returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YEAR Google Sheets

=YEAR(1)

Actual result
1899

Documented / expected
1900

Engine
Google Sheets, executed 2026-08-29 (Drive import)

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1900, got 1899
YEAR LibreOffice Calc

=YEAR(1)

Actual result
1899

Documented / expected
1900

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Serial 1 is Jan 1, 1900 in the 1900 date system; MISMATCH vs expected: expected 1900, got 1899
YEARFRAC LibreOffice Calc

=YEARFRAC(DATE(2012,1,1),DATE(2012,7,30),9)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Date and time

Microsoft docs: 'invalid basis values (< 0 or > 4) return a #NUM! error.'; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YEARS Excel for the web

=YEARS(DATE(2020,3,10),DATE(2021,3,9),1)

Actual result
#NAME?

Documented / expected
1

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

THIS PAGE PUBLISHES NO EXAMPLES, EXACTLY AS ITS SIBLING MONTHS DOES NOT, AND THIS FILE SAYS SO RATHER THAN INVENTING SEMANTICS. YEARS's entire entry is: "Calculates the difference in years between two dates", a Syntax block, "StartDate is the first date", "EndDate is the second date", and "Type calculates the type of difference. Possible values are 0 (interval) and 1 (in calendar years)." No Example section, no sign convention for reversed dates, no statement about other Type values; none of those is asserted anywhere in this file. What IS asserted is the two parenthetical glosses, on a date pair chosen so the two readings DIFFER. Under 'in calendar years' the difference is between the years themselves, 2021 - 2020 = 1, whatever the days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
YEARS Google Sheets

=YEARS(DATE(2020,3,10),DATE(2021,3,9),1)

Actual result
#NAME?

Documented / expected
1

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

THIS PAGE PUBLISHES NO EXAMPLES, EXACTLY AS ITS SIBLING MONTHS DOES NOT, AND THIS FILE SAYS SO RATHER THAN INVENTING SEMANTICS. YEARS's entire entry is: "Calculates the difference in years between two dates", a Syntax block, "StartDate is the first date", "EndDate is the second date", and "Type calculates the type of difference. Possible values are 0 (interval) and 1 (in calendar years)." No Example section, no sign convention for reversed dates, no statement about other Type values; none of those is asserted anywhere in this file. What IS asserted is the two parenthetical glosses, on a date pair chosen so the two readings DIFFER. Under 'in calendar years' the difference is between the years themselves, 2021 - 2020 = 1, whatever the days. STORAGE FORM, ESTABLISHED EMPIRICALLY IN BOTH DIRECTIONS BEFORE THIS FILE WAS RUN. A LibreOffice-only function has no OOXML name of its own -- the .xlsx format was frozen on Excel's function set -- so LibreOffice invents one, and this harness must write exactly the token LibreOffice's own .xlsx filter reads. Both directions were measured rather than assumed. IMPORT: every candidate spelling was written into a workbook by openpyxl (which caches no value, so the engine must evaluate from scratch) and round-tripped through `soffice --headless --convert-to xlsx` on all four pinned builds. EXPORT: the same formulas were fed to each build through its own formula parser and written back out to .xlsx, and the stored token was read out of the raw sheet XML. The token recorded for this function in harness/xlfn_map.py is the one both directions agree on across all four builds; the per-function note above says which it is. BATCH PROVENANCE (batch I, group C -- LibreOffice-only functions). This function has x == false AND g == false in docs/data/compat.json: NEITHER Microsoft NOR Google documents it, so this corpus makes no claim about either of those engines, nothing here is measured against their documentation, and the Excel column on the published page reads 'n/a (not an Excel function)' rather than a verdict. The authority is LibreOffice's own help, cited by full URL, by the date it was read (2026-08-31), and by the help version the page serves -- the URLs in this file are pinned to /25.8/ rather than /latest/ so the citation still means this text after the help site rolls forward, and /25.8/ is the help for the newest of the four engine builds the corpus executes. GOOGLE SHEETS: this batch builds the Sheets chunk whose ingest will record presence or absence in that engine. Until that ingest lands, the Sheets column on the published page reads 'Not yet' and nothing in this file claims anything about it. (Stated positively on purpose. scripts/check_honesty.py bans the blanket negative shape of this sentence outright -- it was once a true site-wide claim and is now false for more than 500 functions -- and that guard is worth keeping blunt, so this note carries the same per-function fact in a form the guard does not have to make an exception for.) LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 1, got '#NAME?'
YEARS Excel for the web

=YEARS(DATE(2020,3,10),DATE(2021,3,9),0)

Actual result
#NAME?

Documented / expected
0

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the other gloss on identical arguments: an interval counts whole elapsed years, and one day short of the anniversary no whole year has elapsed. This is the case that separates the two Types. LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
YEARS Google Sheets

=YEARS(DATE(2020,3,10),DATE(2021,3,9),0)

Actual result
#NAME?

Documented / expected
0

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the other gloss on identical arguments: an interval counts whole elapsed years, and one day short of the anniversary no whole year has elapsed. This is the case that separates the two Types. LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 0, got '#NAME?'
YEARS Excel for the web

=YEARS(DATE(2020,3,10),DATE(2023,3,10),0)

Actual result
#NAME?

Documented / expected
3

Engine
Excel for the web, executed 2026-09-01 (OneDrive recalculation)

Category
Date & Time

DERIVED from the 'interval' gloss: from 10 March 2020 to 10 March 2023 is exactly three whole elapsed years. Fixes the scale of the answer, and lands exactly on the anniversary boundary the case above lands one day before. LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 3, got '#NAME?'
YEARS Google Sheets

=YEARS(DATE(2020,3,10),DATE(2023,3,10),0)

Actual result
#NAME?

Documented / expected
3

Engine
Google Sheets, executed 2026-09-01 (Drive import)

Category
Date & Time

DERIVED from the 'interval' gloss: from 10 March 2020 to 10 March 2023 is exactly three whole elapsed years. Fixes the scale of the answer, and lands exactly on the anniversary boundary the case above lands one day before. LibreOffice's YEARS help page, read live on 2026-08-31 at https://help.libreoffice.org/25.8/en-US/text/scalc/01/04060111.html.; MISMATCH vs expected: expected 3, got '#NAME?'
YIELD LibreOffice Calc

=YIELD(A2,A3,A4,A5,A6,A7,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If basis < 0 or if basis > 4, YIELD returns the #NUM! error value." The basis table runs 0 = US (NASD) 30/360, 1 = Actual/actual, 2 = Actual/360, 3 = Actual/365, 4 = European 30/360.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELD LibreOffice Calc

=YIELD(A2,A3,A4,A5,A6,3,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If frequency is any number other than 1, 2, or 4, YIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELD LibreOffice Calc

=YIELD(A2,A3,A4,0,A6,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If pr <= 0 or if redemption <= 0, YIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELD LibreOffice Calc

=YIELD(A3,A2,A4,A5,A6,A7,A8)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If settlement >= maturity, YIELD returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDDISC LibreOffice Calc

=YIELDDISC(A2,A3,A4,A5,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If basis < 0 or if basis > 4, YIELDDISC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDDISC LibreOffice Calc

=YIELDDISC(A2,A3,0,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If pr <= 0 or if redemption <= 0, YIELDDISC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDDISC LibreOffice Calc

=YIELDDISC(A3,A2,A4,A5,A6)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If settlement >= maturity, YIELDDISC returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDMAT LibreOffice Calc

=YIELDMAT(A2,A3,A4,A5,A6,5)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If basis < 0 or if basis > 4, YIELDMAT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDMAT LibreOffice Calc

=YIELDMAT(A2,A3,A4,-0.01,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If rate < 0 or if pr <= 0, YIELDMAT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDMAT LibreOffice Calc

=YIELDMAT(A2,A3,A4,A5,0,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The second half of the same Remark: pr <= 0 is a #NUM!.; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
YIELDMAT LibreOffice Calc

=YIELDMAT(A3,A2,A4,A5,A6,A7)

Actual result
#VALUE!

Documented / expected
#NUM!

Engine
LibreOffice Calc 25.8.7.3

Category
Financial

The Remarks publish: "If settlement >= maturity, YIELDMAT returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'
Z.TEST LibreOffice Calc

=Z.TEST(A20:A21,4)

Actual result
#DIV/0!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Statistical

The Remarks publish: "If array is empty, Z.TEST returns the #N/A error value." A2:A11 holds the data; A20:A21 IS DELIBERATELY BLANK AND UNPOPULATED, which is the entire content of this case -- see scripts/check_test_setup_refs.py, which accepts a reference to an unset cell only when the case says in its own words that emptiness is the point.; MISMATCH vs expected: expected '#N/A', got '#DIV/0!'
ZTEST LibreOffice Calc

=ZTEST(A20:A21,4)

Actual result
#DIV/0!

Documented / expected
#N/A

Engine
LibreOffice Calc 25.8.7.3

Category
Compatibility

The Remarks publish: "If array is empty, ZTEST returns the #N/A error value." A20:A21 IS DELIBERATELY BLANK AND UNPOPULATED; emptiness is the whole content of the case.; MISMATCH vs expected: expected '#N/A', got '#DIV/0!'

Discovered quirks

ACCRINT LibreOffice Calc

ACCRINT LibreOffice Calc

ACCRINT LibreOffice Calc

ACCRINT LibreOffice Calc

ACCRINT LibreOffice Calc

ACCRINTM LibreOffice Calc

ACCRINTM LibreOffice Calc

ACCRINTM LibreOffice Calc

ACOSH LibreOffice Calc

ACOT Google Sheets

ACOTH LibreOffice Calc

ADD Excel for the web

ADD LibreOffice Calc

ADD Excel for the web

ADD LibreOffice Calc

ADD Excel for the web

ADD LibreOffice Calc

ADD Excel for the web

ADD LibreOffice Calc

ADD Excel for the web

ADD LibreOffice Calc

AGGREGATE Google Sheets

AMORDEGRC Google Sheets

AMORDEGRC Excel for the web

AMORDEGRC Google Sheets

AMORDEGRC LibreOffice Calc

AMORDEGRC Excel for the web

AMORDEGRC Google Sheets

AMORDEGRC LibreOffice Calc

AMORDEGRC Google Sheets

AND Excel for the web

AREAS Google Sheets

AREAS Google Sheets

AREAS Google Sheets

AREAS Google Sheets

ARRAYFORMULA Excel for the web

ARRAYFORMULA LibreOffice Calc

ARRAYFORMULA Excel for the web

ARRAYFORMULA LibreOffice Calc

ARRAYFORMULA Excel for the web

ARRAYFORMULA LibreOffice Calc

ARRAYFORMULA Excel for the web

ARRAYFORMULA LibreOffice Calc

ARRAYTOTEXT Google Sheets

ARRAYTOTEXT LibreOffice Calc

ARRAYTOTEXT Google Sheets

ARRAYTOTEXT LibreOffice Calc

ARRAYTOTEXT Google Sheets

ARRAYTOTEXT LibreOffice Calc

ARRAYTOTEXT Google Sheets

ARRAYTOTEXT LibreOffice Calc

ARRAY_CONSTRAIN Excel for the web

ARRAY_CONSTRAIN LibreOffice Calc

ARRAY_CONSTRAIN Excel for the web

ARRAY_CONSTRAIN LibreOffice Calc

ARRAY_CONSTRAIN Excel for the web

ARRAY_CONSTRAIN LibreOffice Calc

ARRAY_CONSTRAIN Excel for the web

ARRAY_CONSTRAIN LibreOffice Calc

ASC Excel for the web

ASC LibreOffice Calc

ASC Excel for the web

ATAN2 LibreOffice Calc

ATANH LibreOffice Calc

AVERAGE.WEIGHTED Excel for the web

AVERAGE.WEIGHTED LibreOffice Calc

AVERAGE.WEIGHTED Excel for the web

AVERAGE.WEIGHTED LibreOffice Calc

AVERAGE.WEIGHTED Excel for the web

AVERAGE.WEIGHTED LibreOffice Calc

AVERAGE.WEIGHTED Excel for the web

AVERAGE.WEIGHTED LibreOffice Calc

AVERAGE.WEIGHTED Excel for the web

AVERAGE.WEIGHTED LibreOffice Calc

BESSELI Google Sheets

BESSELI Google Sheets

BESSELI LibreOffice Calc

BESSELI Google Sheets

BESSELI Google Sheets