ARRAY_CONSTRAIN

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.