ISO.CEILING

Microsoft publishes '=ISO.CEILING(4.3)' with the result 5 and the description "Rounds 4.3 up to nearest multiple of 1". Significance is omitted, which the page documents as defaulting to 1. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3)' with the result -4. This is the case that defines the function: -4 is GREATER than -4.3, so rounding "up" has moved the value toward zero, not away from it. An engine that rounds away from zero returns -5 here. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3, 2)' with the result 6: the multiples of 2 around 4.3 are 4 and 6, and 6 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3,-2)' with the result 6 -- the same answer as for significance +2. This is what the page's Note means by "The absolute value of the multiple is used": the sign of significance is discarded entirely. It is also the sharpest difference between ISO.CEILING and the older CEILING, which errors or changes direction on a sign mismatch. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,2)' with the result -4: the multiples of 2 around -4.3 are -6 and -4, and -4 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,-2)' with the result -4 -- again the same as for significance +2, because the absolute value of the multiple is used. All four sign combinations of the (number, significance) pair are asserted in this file, which is the only way to show that a ceiling implementation is sign-correct rather than accidentally right on the positive quadrant. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

The page's description ends with the sentence "However, if the number or the significance is zero, zero is returned" -- so a zero significance is a documented branch returning 0, not a division-by-zero error. Worth its own case because "round 4.3 to the nearest multiple of nothing" has no mathematical answer and the specification simply legislates one. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3)' with the result 5 and the description "Rounds 4.3 up to nearest multiple of 1". Significance is omitted, which the page documents as defaulting to 1. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3)' with the result -4. This is the case that defines the function: -4 is GREATER than -4.3, so rounding "up" has moved the value toward zero, not away from it. An engine that rounds away from zero returns -5 here. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3, 2)' with the result 6: the multiples of 2 around 4.3 are 4 and 6, and 6 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3,-2)' with the result 6 -- the same answer as for significance +2. This is what the page's Note means by "The absolute value of the multiple is used": the sign of significance is discarded entirely. It is also the sharpest difference between ISO.CEILING and the older CEILING, which errors or changes direction on a sign mismatch. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,2)' with the result -4: the multiples of 2 around -4.3 are -6 and -4, and -4 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,-2)' with the result -4 -- again the same as for significance +2, because the absolute value of the multiple is used. All four sign combinations of the (number, significance) pair are asserted in this file, which is the only way to show that a ceiling implementation is sign-correct rather than accidentally right on the positive quadrant. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

The page's description ends with the sentence "However, if the number or the significance is zero, zero is returned" -- so a zero significance is a documented branch returning 0, not a division-by-zero error. Worth its own case because "round 4.3 to the nearest multiple of nothing" has no mathematical answer and the specification simply legislates one. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3)' with the result 5 and the description "Rounds 4.3 up to nearest multiple of 1". Significance is omitted, which the page documents as defaulting to 1. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3)' with the result -4. This is the case that defines the function: -4 is GREATER than -4.3, so rounding "up" has moved the value toward zero, not away from it. An engine that rounds away from zero returns -5 here. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3, 2)' with the result 6: the multiples of 2 around 4.3 are 4 and 6, and 6 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(4.3,-2)' with the result 6 -- the same answer as for significance +2. This is what the page's Note means by "The absolute value of the multiple is used": the sign of significance is discarded entirely. It is also the sharpest difference between ISO.CEILING and the older CEILING, which errors or changes direction on a sign mismatch. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,2)' with the result -4: the multiples of 2 around -4.3 are -6 and -4, and -4 is the one above. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

Microsoft publishes '=ISO.CEILING(-4.3,-2)' with the result -4 -- again the same as for significance +2, because the absolute value of the multiple is used. All four sign combinations of the (number, significance) pair are asserted in this file, which is the only way to show that a ceiling implementation is sign-correct rather than accidentally right on the positive quadrant. ISO.CEILING's rule, quoted from the page: "Returns a number that is rounded up to the nearest integer or to the nearest multiple of significance. Regardless of the sign of the number, the number is rounded up. However, if the number or the significance is zero, zero is returned", plus the Note: "The absolute value of the multiple is used, so that the ISO.CEILING function returns the mathematical ceiling irrespective of the signs of number and significance." "Rounded up" here means toward positive infinity, not away from zero -- which is exactly what makes the negative cases worth asserting separately. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.

The page's description ends with the sentence "However, if the number or the significance is zero, zero is returned" -- so a zero significance is a documented branch returning 0, not a division-by-zero error. Worth its own case because "round 4.3 to the nearest multiple of nothing" has no mathematical answer and the specification simply legislates one. STORAGE FORM, CORRECTED BY THIS BATCH. ISO.CEILING was in harness/xlfn_map.py's prefix set before batch E, which would have written _xlfn.ISO.CEILING into the .xlsx and recorded a #NAME? -- a false "unsupported" verdict for a function all four LibreOffice builds compute correctly. It is a future function (it is not in ISO/IEC 29500's predefined list), but it is one of exactly FOUR future functions that [MS-XLSX] section 2.2.3 "Functions" spells WITHOUT the prefix -- ECMA.CEILING, ISO.CEILING, NETWORKDAYS.INTL and WORKDAY.INTL, each a bare row in a table whose other 155 rows begin "_xlfn.". LibreOffice's own filter agrees: sc/source/filter/oox/formulabase.cxx tags ISO.CEILING with plain FuncFlags::MACROCALL (prefix in the old binary format only) rather than the MACROCALL_NEW its neighbour CEILING.PRECISE carries. Confirmed empirically in both directions on all four builds: =ISO.CEILING(4.3) evaluates while =_xlfn.ISO.CEILING(4.3) and =COM.MICROSOFT.ISO.CEILING(4.3) are #NAME?, and round-tripping a workbook through LibreOffice's own .xlsx export writes the formula back out as the bare token. The entry has been removed from xlfn_map.py, and this file is executed under the plain name.