LOGNORMDIST

Microsoft publishes '=LOGNORMDIST(A2,A3,A4)' with the result 0.0390836 -- the same figure its modern replacement LOGNORM.DIST publishes for the same three arguments, since LOGNORMDIST is the cumulative form only and takes no cumulative flag. DERIVATION, along a different path from the published figure. The lognormal CDF is documented on the LOGNORM.DIST page as NORM.S.DIST((ln(x)-mu)/sigma), so with x = 4, mu = 3.5 and sigma = 1.2 the standardised argument is z = (ln 4 - 3.5)/1.2 = (1.3862943611198906188 - 3.5)/1.2 = -1.7614213657334244843. This corpus does not call any statistics library's normal CDF: it evaluates Phi(z) = erfc(-z/sqrt(2))/2 with mpmath at 50 digits, giving 0.039083555706800473296. The density is computed from its own closed form, exp(-(ln x - mu)^2/(2 sigma^2)) / (x sigma sqrt(2 pi)) = 0.017617596681819223728. The inverse is obtained by ROOT-FINDING on that same erfc-based CDF rather than by any inverse-normal routine: solving Phi(z) = 0.039084 gives z = -1.7613003288..., and exp(mu + sigma z) = 4.0000252186806350759 -- note the probability Microsoft feeds back in, 0.039084, is its own published CDF figure ROUNDED to six places, which is exactly why the inverse lands on 4.0000252 rather than on 4.

0.039083555706800473296 at ten places. The legacy alias must agree with the modern spelling here to ten places, which is the point of asserting both: this corpus has already found several cases (GAMMADIST vs GAMMA.DIST in batch D, FTEST vs F.TEST in batches C and D) where the legacy name and its replacement disagree about the same documented behaviour.

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. EXECUTED RESULT -- A SILENT WRONG ANSWER: all four LibreOffice builds return the NUMBER 0 here instead of the documented #NUM!. Zero is a perfectly plausible value for a cumulative distribution, so a column of non-positive inputs comes back as a column of zeros rather than a visible column of errors -- the same shape batch C found in EXPON.DIST and batch D in GAMMADIST. Both spellings, the legacy LOGNORMDIST and the modern LOGNORM.DIST, do it, so unlike batch D's GAMMADIST/GAMMA.DIST split there is no correct sibling to fall back on.

The same documented sentence, asserted away from the boundary so that an engine guarding only the exact value zero is caught. EXECUTED RESULT: 0 on all four builds, the same silent zero as at x = 0 -- so the guard is not merely mis-set at the boundary, it is absent. ln(x) does not exist here at all.

Excel documents: "If x <= 0 or if Standard_dev <= 0, LOGNORMDIST returns the #NUM! error value."

Excel documents: "If any argument is non-numeric, LOGNORMDIST returns the #VALUE! error value."

Microsoft publishes '=LOGNORMDIST(A2,A3,A4)' with the result 0.0390836 -- the same figure its modern replacement LOGNORM.DIST publishes for the same three arguments, since LOGNORMDIST is the cumulative form only and takes no cumulative flag. DERIVATION, along a different path from the published figure. The lognormal CDF is documented on the LOGNORM.DIST page as NORM.S.DIST((ln(x)-mu)/sigma), so with x = 4, mu = 3.5 and sigma = 1.2 the standardised argument is z = (ln 4 - 3.5)/1.2 = (1.3862943611198906188 - 3.5)/1.2 = -1.7614213657334244843. This corpus does not call any statistics library's normal CDF: it evaluates Phi(z) = erfc(-z/sqrt(2))/2 with mpmath at 50 digits, giving 0.039083555706800473296. The density is computed from its own closed form, exp(-(ln x - mu)^2/(2 sigma^2)) / (x sigma sqrt(2 pi)) = 0.017617596681819223728. The inverse is obtained by ROOT-FINDING on that same erfc-based CDF rather than by any inverse-normal routine: solving Phi(z) = 0.039084 gives z = -1.7613003288..., and exp(mu + sigma z) = 4.0000252186806350759 -- note the probability Microsoft feeds back in, 0.039084, is its own published CDF figure ROUNDED to six places, which is exactly why the inverse lands on 4.0000252 rather than on 4.

0.039083555706800473296 at ten places. The legacy alias must agree with the modern spelling here to ten places, which is the point of asserting both: this corpus has already found several cases (GAMMADIST vs GAMMA.DIST in batch D, FTEST vs F.TEST in batches C and D) where the legacy name and its replacement disagree about the same documented behaviour.

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. EXECUTED RESULT -- A SILENT WRONG ANSWER: all four LibreOffice builds return the NUMBER 0 here instead of the documented #NUM!. Zero is a perfectly plausible value for a cumulative distribution, so a column of non-positive inputs comes back as a column of zeros rather than a visible column of errors -- the same shape batch C found in EXPON.DIST and batch D in GAMMADIST. Both spellings, the legacy LOGNORMDIST and the modern LOGNORM.DIST, do it, so unlike batch D's GAMMADIST/GAMMA.DIST split there is no correct sibling to fall back on.

The same documented sentence, asserted away from the boundary so that an engine guarding only the exact value zero is caught. EXECUTED RESULT: 0 on all four builds, the same silent zero as at x = 0 -- so the guard is not merely mis-set at the boundary, it is absent. ln(x) does not exist here at all.

Excel documents: "If x <= 0 or if Standard_dev <= 0, LOGNORMDIST returns the #NUM! error value."

Excel documents: "If any argument is non-numeric, LOGNORMDIST returns the #VALUE! error value."

Microsoft publishes '=LOGNORMDIST(A2,A3,A4)' with the result 0.0390836 -- the same figure its modern replacement LOGNORM.DIST publishes for the same three arguments, since LOGNORMDIST is the cumulative form only and takes no cumulative flag. DERIVATION, along a different path from the published figure. The lognormal CDF is documented on the LOGNORM.DIST page as NORM.S.DIST((ln(x)-mu)/sigma), so with x = 4, mu = 3.5 and sigma = 1.2 the standardised argument is z = (ln 4 - 3.5)/1.2 = (1.3862943611198906188 - 3.5)/1.2 = -1.7614213657334244843. This corpus does not call any statistics library's normal CDF: it evaluates Phi(z) = erfc(-z/sqrt(2))/2 with mpmath at 50 digits, giving 0.039083555706800473296. The density is computed from its own closed form, exp(-(ln x - mu)^2/(2 sigma^2)) / (x sigma sqrt(2 pi)) = 0.017617596681819223728. The inverse is obtained by ROOT-FINDING on that same erfc-based CDF rather than by any inverse-normal routine: solving Phi(z) = 0.039084 gives z = -1.7613003288..., and exp(mu + sigma z) = 4.0000252186806350759 -- note the probability Microsoft feeds back in, 0.039084, is its own published CDF figure ROUNDED to six places, which is exactly why the inverse lands on 4.0000252 rather than on 4.

0.039083555706800473296 at ten places. The legacy alias must agree with the modern spelling here to ten places, which is the point of asserting both: this corpus has already found several cases (GAMMADIST vs GAMMA.DIST in batch D, FTEST vs F.TEST in batches C and D) where the legacy name and its replacement disagree about the same documented behaviour.

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. EXECUTED RESULT -- A SILENT WRONG ANSWER: all four LibreOffice builds return the NUMBER 0 here instead of the documented #NUM!. Zero is a perfectly plausible value for a cumulative distribution, so a column of non-positive inputs comes back as a column of zeros rather than a visible column of errors -- the same shape batch C found in EXPON.DIST and batch D in GAMMADIST. Both spellings, the legacy LOGNORMDIST and the modern LOGNORM.DIST, do it, so unlike batch D's GAMMADIST/GAMMA.DIST split there is no correct sibling to fall back on.

The same documented sentence, asserted away from the boundary so that an engine guarding only the exact value zero is caught. EXECUTED RESULT: 0 on all four builds, the same silent zero as at x = 0 -- so the guard is not merely mis-set at the boundary, it is absent. ln(x) does not exist here at all.

Excel documents: "If x <= 0 or if Standard_dev <= 0, LOGNORMDIST returns the #NUM! error value."

Excel documents: "If any argument is non-numeric, LOGNORMDIST returns the #VALUE! error value."