ChakataStat
Download

Verify this Installation

Help → Verify this Installation (Ctrl+F1, or Verify this Installation in the command palette) runs a built-in check of the copy of ChakataStat you are using, and prints a report you can keep, print, export or hand to a reviewer. It takes well under a minute and needs no dataset open — you can run it on a fresh installation before you load anything.

What it does

ChakataStat ships with a small set of reference datasets and, for each, a list of statistics whose correct values were computed independently — by SciPy and statsmodels, by R's survey package, and, for the linear regression suite, by the U.S. National Institute of Standards and Technology, whose Statistical Reference Datasets publish certified values to fifteen significant digits. The check loads each dataset into the engine that is actually installed on your computer, runs the analyses exactly as the menus would, and compares every result with its reference value.

This is the same evidence the developers run on every change (see the validation methodology), reduced to a subset that covers every family of tools — descriptives, comparing means, correlation, regression and generalized linear models, nonparametric tests, survival analysis, meta-analysis, time series, scale reduction and classification, complex samples — plus all eleven NIST linear least-squares datasets. The difference is where it runs: on your machine, your operating system, your build, not on the developer's.

Reading the report

The report appears in the Output view as three ordinary result tables, so it prints, copies and exports (File → Export Output…) like any other result.

Installation Verification is the verdict and its provenance: PASS or FAIL, how many checks passed, the application and engine versions, the operating system, when the run started and how long it took.

Verification Datasets lists each bundled dataset with its size and the SHA-256 of the file as shipped, so a reader can tie the report to the exact bytes that were checked.

Verification Checks has one row per statistic:

  • Expected — the reference value, and Reference — where it came from (the exact SciPy, statsmodels or R call, or the NIST certification).
  • Computed — what this installation produced, printed at full precision.
  • Digits agreed — the number of significant digits on which the two agree (the log relative error of McCullough 1998, the convention used to score statistical software against NIST). 15 is the most a double-precision reference can show.
  • Criterion — what counts as a pass: for a package-referenced statistic, the same tolerance the developer suite pins it to; for a NIST statistic, the minimum digits of agreement for that dataset's published difficulty grade.
  • Result — pass, or FAIL with both values named.

A fully passing report says: this installed binary reproduces every reference value in the manifest, on this platform, to the recorded precision.

From the command line

The same check runs with no window:

ChakataStat --verify
ChakataStat --verify --out verification.html

The report goes to standard output as Markdown, or to --out in the format its extension names (HTML, Markdown or LaTeX); progress and the verdict go to standard error. The exit status is 0 only on a full pass — 1 when any check failed, 2 when the check could not be set up — so a script or a deployment pipeline can gate on it. This is how the release process qualifies each package before it ships.

What it proves, and what it does not

It does prove that the copy of ChakataStat installed on this machine — this build, this operating system, this processor — computes the checked statistics correctly against independent references. In regulated settings that is an installation qualification: evidence that the software works here, not just where it was built.

It does not validate your own analysis. A passing report says nothing about whether the procedure you chose is appropriate for your data, whether your variables are coded the way you think, or whether your conclusions follow. It also checks the shipped subset, not every statistic the application can print; the full suite behind it, and how the subset was chosen, are documented in the validation methodology.

If a check fails on your machine, the row names the statistic and both values. That is worth reporting (see Help → About for the contact address) together with the report, the Platform line in particular: a result that passes on the developer's platform and fails on yours is exactly the kind of difference this check exists to catch.

  • The reproducibility bundle — the same verifier turned on a particular result: --verify <bundle> <data> re-runs an author's journal and compares every output.
  • Reproducibility — the syntax console, headless batch runs (--run) and exporting the output log.
  • Direct Engine Access — the engine diagnostics panel.