[davidhbernstein]

A negative variance estimate was reported as a standard error of exactly zero

Standard errors were taken as sqrt(pmax(diag(V), 0)) at 21 places in R/.
The clamp means a parameter whose estimated variance came back negative --
which is exactly what an indefinite Hessian gives -- was reported as
st_err = 0 and t-val = par/0 = Inf: an infinitely precise estimate for the
one direction the covariance machinery has nothing to say about. The oldest of
those sites dates to CRAN 1.0.4 (2026-02-04).

Reachable on the first seed tried, on this machine

psfm(model_name = "GTRE_FML") on A55's own design -- data_gen_p(t = 5, N = 40, rand = 1, sig_u = 1, sig_v = 0.3, sig_r = 0.2, sig_h = 0.4, cons = 0.5, beta1 = 0.5, beta2 = 0.5, eta = 0.1), 3.1 seconds to fit:

              (Intercept)        x1         x2        sigr       sigv       sigh      sigu
par              0.413756  0.542644   0.475742  5.2403e-08   0.409347   0.567744  0.841880
diag(solve(H))  1.006e-05 -2.83e-06  8.535e-06     4.0e-18  -3.869e-04 -3.762e-04 1.403e-05
st_err           0.003171  0.000000   0.002921     2.0e-09   0.000000   0.000000  0.003745
t-val             130.474       Inf    162.843     26.2017        Inf        Inf   224.800

Three of seven parameters, one an ordinary slope (x1 = 0.5426), reported with
a standard error of zero. Over seeds 1-10 of that design: 1 shows this, 4
return all-NA standard errors because solve() fails outright (already
handled), 5 are ordinary. It is not rare arithmetic -- it is what an indefinite
Hessian always produces.

The change

.sfa_se_from_var() (R/matrix_utils.R) reports a negative or non-finite
variance estimate as NA and takes the square root otherwise. All 21 sites
call it: psfm (10), panel_classical and uhet_test (2 each), and one each
in sfm, esfm, het, kss, selsfm_kts, robust_divergence and
matrix_utils. On seed 1 the three negative coordinates become NA, the
other four standard errors are unchanged to every digit, and no Inf
t-value survives. This is what the unclamped entry points (ttsfm, zsfm,
lcsfm, copsfm, ivsfm, selsfm) already did by taking the square root of
the negative value directly.

vcov()'s singular-Hessian fallback builds a diagonal from the reported
standard errors (R/sfareg_methods.R:209), so it now carries NA for those
parameters instead of a zero variance. Its !all(is.na(...)) guard is
unaffected.

Deliberately left alone

• Quantities that are not a parameter's standard error. sfm()'s per-firm
  posterior spread sd_exp_u_hat is sqrt(pmax(E[exp(-2u)] - E[exp(-u)]^2, 0))
  by quadrature, where a small negative is rounding on a genuinely near-zero
  variance and 0 is the right report; changing it would blank the column for
  well-behaved firms. Likewise the 1e-3 curvature floor and the
  double.xmin density floor, which are not variances.
• An exactly-zero variance, which keeps reporting 0. The defect is the
  clamp manufacturing zeros out of negatives.
• sigr in the table above, at 5.24e-08 with variance 4e-18, standard
  error 2e-09 and t-value 26.2 -- a collapsed parameter reported as
  comfortably significant. That is A55's open territory (name the parameter
  that died), it survives this change untouched, and it is arguably more
  misleading than the Inf because it looks like an ordinary number.

Tests

tests/testthat/test-a64-negative-variance-se.R, 14 assertions: the helper's
contract, that a t-value built on it is NA rather than Inf, and the
end-to-end GTRE_FML fit above. On main the file gives 7 failures
(4 errors for the missing helper, plus the three end-to-end assertions:
se == 0 count, infinite-t count, and NA on exactly the negative
coordinates); on this branch 14 pass, 0 fail on macOS.

The end-to-end case is platform-dependent, and the first CI run proved it.
It originally asserted expect_gt(sum(v < 0), 0) -- that this design really
does reach a negative variance estimate. It does here (3 of 7 parameters) and
on none of CI's five platforms, so all five jobs failed on that one
assertion and nothing else (FAIL 1 each, 44m-2h06m) while the fix itself was
correct. Which point the 3-stage minimiser lands on, and the sign of a small
eigenvalue there, is BLAS-dependent arithmetic; the fixed seed makes the data
identical everywhere, not the fit. That premise is now gated on
skip_if_not(any(v < 0), ...) with the solve() wrapped in tryCatch, so the
clause skips off this Mac. The invariant stays unconditional -- no finite
standard error of exactly 0, no infinite t-value -- and the helper's four
deterministic unit tests, whose input is constructed rather than optimised to,
carry the proof of the fix.

Full local suite against the merged branch build, after #63 landed and this
branch took main (macOS, load_package = "installed", NOT_CRAN=true,
TESTTHAT_CPUS=2): pass 5531, fail 0, warn 48, skip 9. For the record, CI's
warning counts on the pre-merge branch ranged 182-225 across the five platforms
against identical code, which is why 48 is reported rather than compared.

The merge with main, and one thing it fixes

NEWS.md conflicted as expected -- both entries kept, A53's first since it is
already on main. R/matrix_utils.R conflicted because both branches inserted
their helper at the same place: between .log_nr_g's three-line comment and
.log_nr_g itself, so each had silently orphaned that comment onto its own
function, and main carries the same wart from #63. The merge puts
.sfa_se_from_var() and .se_missing_report() above the comment and
re-attaches it, so landing this also fixes that on main.
There is no same-invocation main baseline for the warning count this round,
so 48 is reported rather than compared; the change cannot add warnings, since
.sfa_se_from_var() emits none and sqrt() of NA is silent where
sqrt() of a negative was not.

Found while scoping A53 item 5, which claimed sqrt(diag(solve(h))) "destroys
every one of them together" and prescribed per-parameter reporting. R's
sqrt() is already element-wise (sqrt(c(4, -1, 9)) is 2 NaN 3), so that
item is refuted and recorded as such; the clamped sibling expression is the
real defect.

🤖 Generated with Claude Code