TINV

Microsoft publishes =TINV(A2,A3) = 1.96 for A2 = 0.05464 and A3 = 60. TINV IS TWO-TAILED -- the page's own description is "Returns the two-tailed inverse of the Student's t-distribution" and its Important box points at "T.INV.2T function or T.INV function", of which only T.INV.2T shares the convention. DERIVATION: solving 2*(1 - F(t)) = 0.05464 at 60 degrees of freedom by root find on the doubly-cross-checked CDF gives 1.960041187127245765323, which is 1.96 at the published precision. Note the probability in the cell is 0.05464, a five-decimal truncation of the 0.05464493 the T.DIST.2T family publishes for t = 1.959999998, so the inverse comes back at 1.96004 rather than at 1.96 exactly -- the two published examples are consistent, just rounded at different points. Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/tinv-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.

Asserted at ten places from the derivation: 1.9600411871. Two published decimals are the loosest assertion anywhere in this batch and could not distinguish TINV from almost anything; this case is what makes the file's headline example meaningful.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 2.228138852 at nine places, not the published 2.28139. Had the published figure been copied, every engine on earth would have been recorded as diverging from Excel here, and the divergence would have been ours.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 1.812461 at six places. It is the pair with the 2.228139 case above that shows the paragraph to be unreliable as a whole rather than carrying one isolated typo.

TINV and T.INV.2T are documented as the same two-tailed inverse. A structural assertion with no derived constant, checking the engine's legacy and modern spellings against each other -- and specifically NOT against T.INV, which is left-tailed and would differ.

The page publishes the relationship in words: "TINV seeks that value x such that TDIST(x, deg_freedom, 2) = probability. Thus, precision of TINV depends on precision of TDIST." This case asserts exactly that sentence as a round trip, with no derived constant.

The Remarks publish: "If probability <= 0 or if probability > 1, TINV returns the #NUM! error value."

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.

Microsoft publishes =TINV(A2,A3) = 1.96 for A2 = 0.05464 and A3 = 60. TINV IS TWO-TAILED -- the page's own description is "Returns the two-tailed inverse of the Student's t-distribution" and its Important box points at "T.INV.2T function or T.INV function", of which only T.INV.2T shares the convention. DERIVATION: solving 2*(1 - F(t)) = 0.05464 at 60 degrees of freedom by root find on the doubly-cross-checked CDF gives 1.960041187127245765323, which is 1.96 at the published precision. Note the probability in the cell is 0.05464, a five-decimal truncation of the 0.05464493 the T.DIST.2T family publishes for t = 1.959999998, so the inverse comes back at 1.96004 rather than at 1.96 exactly -- the two published examples are consistent, just rounded at different points. Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/tinv-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.

Asserted at ten places from the derivation: 1.9600411871. Two published decimals are the loosest assertion anywhere in this batch and could not distinguish TINV from almost anything; this case is what makes the file's headline example meaningful.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 2.228138852 at nine places, not the published 2.28139. Had the published figure been copied, every engine on earth would have been recorded as diverging from Excel here, and the divergence would have been ours.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 1.812461 at six places. It is the pair with the 2.228139 case above that shows the paragraph to be unreliable as a whole rather than carrying one isolated typo.

TINV and T.INV.2T are documented as the same two-tailed inverse. A structural assertion with no derived constant, checking the engine's legacy and modern spellings against each other -- and specifically NOT against T.INV, which is left-tailed and would differ.

The page publishes the relationship in words: "TINV seeks that value x such that TDIST(x, deg_freedom, 2) = probability. Thus, precision of TINV depends on precision of TDIST." This case asserts exactly that sentence as a round trip, with no derived constant.

The Remarks publish: "If probability <= 0 or if probability > 1, TINV returns the #NUM! error value."

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.

Microsoft publishes =TINV(A2,A3) = 1.96 for A2 = 0.05464 and A3 = 60. TINV IS TWO-TAILED -- the page's own description is "Returns the two-tailed inverse of the Student's t-distribution" and its Important box points at "T.INV.2T function or T.INV function", of which only T.INV.2T shares the convention. DERIVATION: solving 2*(1 - F(t)) = 0.05464 at 60 degrees of freedom by root find on the doubly-cross-checked CDF gives 1.960041187127245765323, which is 1.96 at the published precision. Note the probability in the cell is 0.05464, a five-decimal truncation of the 0.05464493 the T.DIST.2T family publishes for t = 1.959999998, so the inverse comes back at 1.96004 rather than at 1.96 exactly -- the two published examples are consistent, just rounded at different points. Microsoft's page was read live on 2026-08-31 at https://support.microsoft.com/en-us/excel/functions/tinv-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.

Asserted at ten places from the derivation: 1.9600411871. Two published decimals are the loosest assertion anywhere in this batch and could not distinguish TINV from almost anything; this case is what makes the file's headline example meaningful.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 2.228138852 at nine places, not the published 2.28139. Had the published figure been copied, every engine on earth would have been recorded as diverging from Excel here, and the divergence would have been ours.

BOTH FIGURES IN MICROSOFT'S REMARK ARE WRONG, AND THE SECOND ONE WAS CAUGHT BY THE ENGINE RATHER THAN BY THE DERIVATION. The paragraph -- identical on the T.INV.2T page and the TINV page -- publishes: "For a probability of 0.05 and degrees of freedom of 10, the two-tailed value is calculated with TINV(0.05,10), which returns 2.28139. The one-tailed value ... TINV(2*0.05,10), which returns 1.812462." FIGURE ONE, 2.28139, IS A TRANSPOSITION: the true value is 2.228138851986274748395, i.e. 2.228139 -- the digits are right and their order is not. FIGURE TWO, 1.812462, IS A LAST-DIGIT ROUNDING ERROR: the true value is 1.812461122811676413626, which correctly rounded to six places is 1.812461, not 1.812462. This corpus originally asserted Microsoft's 1.812462 -- the derivation had been done but the six-place rounding was copied from the page instead of taken from the derived digits -- and ALL FOUR LibreOffice builds returned 1.812461. The engine was right and the citation was wrong; the case now asserts the derived value and this note records why it changed. Every figure here was checked three independent ways: a root find on the regularized-incomplete-beta t CDF, a root find on a NUMERICALLY INTEGRATED t density sharing no code with the first, and scipy.stats.t.ppf -- all agreeing to double precision. The sanity check settles figure one from the other direction too: T.DIST.2T(2.28139, 10) is 0.045678, not 0.05, while T.DIST.2T(2.228139, 10) is 0.0500000 to six places. This case asserts the DERIVED 1.812461 at six places. It is the pair with the 2.228139 case above that shows the paragraph to be unreliable as a whole rather than carrying one isolated typo.

TINV and T.INV.2T are documented as the same two-tailed inverse. A structural assertion with no derived constant, checking the engine's legacy and modern spellings against each other -- and specifically NOT against T.INV, which is left-tailed and would differ.

The page publishes the relationship in words: "TINV seeks that value x such that TDIST(x, deg_freedom, 2) = probability. Thus, precision of TINV depends on precision of TDIST." This case asserts exactly that sentence as a round trip, with no derived constant.

The Remarks publish: "If probability <= 0 or if probability > 1, TINV returns the #NUM! error value."

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.