[davidhbernstein]

Six entry points reported a NaN standard error with no signal at all

zsfm(), lcsfm(), copsfm(), ivsfm(), selsfm() and psfm() each took
their standard errors as one line:

st_err <- if (isTRUE(as.numeric(sum(colMeans(opt$hessian))) == 0)) {
  rep(NA, length(opt$par))
} else {
  suppressWarnings(sqrt(diag(solve(opt$hessian))))
}

Two defects sit in it.

1. A NaN standard error is reported with nothing said about it. On an
   indefinite Hessian the negative-variance coordinates give NaN, and
   suppressWarnings() discards R's own "NaNs produced" — the only signal
   there was. Nothing sets a flag, print() and summary() say nothing beyond
   printing NaN in the cells, and the convergence code reads 0.
2. solve() was unguarded. The sum(colMeans(h)) == 0 test catches only an
   all-zero Hessian. A Hessian that is singular but not zero made solve()
   error outright, throwing away a fit that had already run — minutes of one for
   copsfm() and selsfm(), which are simulated ML.

This is exactly the state ttsfm() was in before #63; that PR fixed one entry
point and left these five.

Reachable, and cheap to reach

zsfm(model_name = "ZISF") on data_gen_cs(N = 25, rand = 8, sig_u = 1, sig_v = .3, cons = .5, beta1 = .5, beta2 = .5, mu = .5, a = 5) — half a second
to fit:

                    par       st_err    t-val
gamma       1.811390145 0.4535683134 3.993643
sigv        0.003811299 0.0007880277 4.836503
sigu        1.056846362 0.1624906521 6.504044
(Intercept) 1.687709155          NaN      NaN
x1          0.012246013 0.0045458758 2.693873
x2          0.497720716          NaN      NaN

Hessian eigenvalues: 3479000, 1059000, 21990, 37.87, 4.861, -1474
negative diagonal entries of the inverse: 2 of 6
convergence: 0        warnings emitted: 0        flags set: none

One of the two parameters that lost its standard error is the slope x2,
whose true value is 0.5. Over 80 fits of that design (N in 25, 40, 60, 100
× seeds 1–20) two show this; the rest are healthy, with min eigenvalues of 37–65.

The change

All five now call .se_missing_report() — the model-agnostic helper #63 added,
which needed nothing TTHN-specific — on the reported standard errors and
names, so copsfm()'s and ivsfm()'s delta-method scales carry through
correctly and ivsfm("IVLIML")'s count is of what it reports rather than what
it estimates. The result is named in a warning() and recorded in
$se_unresolved, which print() and summary() already carry for any
sfareg object via .sfa_report_boundary() — so no change was needed there,
and the flag survives saveRDS() where a warning does not.

$se_unresolved is appended to each results list rather than re-listed
against its name vector: re-listing twenty-one values against twenty-one names
to add one field is how a misalignment gets introduced. solve() is wrapped in
tryCatch at all five sites.

lcsfm() has two such sites (LCM_CN, and LCM/LCM_Z) and both are done.

Tests

tests/testthat/test-a65-missing-se-everywhere.R. On main it gives 3
failures — no warning is emitted, and $se_unresolved is NULL; on this
branch 17 of 17 pass. It asserts the parameter names, that
min_eigenvalue < 0 < max_eigenvalue, that the message declines to choose
between "not a maximum" and "boundary solution", and that print() carries the
note. It also carries a false-positive guard: the same design at N = 300
must stay silent, set no flag, and report six finite standard errors.

What has NOT been run, and why

The full local suite was not run. This Mac is at load 92 with several
multi-worker R jobs of David's, so a suite run would be neither quick nor
trustworthy. Per the project's own practice when the Mac is saturated, CI's
five platforms are the gate here rather than a local run. What was run
locally: the new test file against both builds (17/17 on the branch, 3 failures
on main), parse() on all five changed files, and the 80-fit scan above.

Of the five entry points, only zsfm() has a reproduction. The other four are
wired identically and are covered by the existing suite only for not
regressing on healthy fits — finding a design that drives each of them to an
indefinite Hessian is its own piece of work, and A65's entry says so rather
than assuming the TTHN or ZISF seeds carry over.

psfm() was added after review began — it has seven sites and a third spelling

The scope note below said psfm() was a sixth site this PR did not cover. It is
now covered, and the count in that note was wrong: psfm() has seven
Hessian-diagonal sites, covering GTRE and TRE (which share one), GTRE_Z,
TRE_Z, GTRE_FML, TFE_WMLE, TFE and FD. Four of the seven left the
inverse unguarded, so a singular but non-zero Hessian discarded a finished
panel fit — the most expensive kind this package produces.

The seventh is FD, which spells the same quantity

sqrt(diag(qr.solve(opt$hessian)))        # qr.solve, and unclamped

so it is invisible to A64's sweep (sqrt(pmax(diag(solve(...)), 0))), to this
PR's first pass (sqrt(diag(solve(...)))) and to the
.sfa_se_from_var(diag(solve(...))) pattern that found the other six. It
surfaced only because a replace-all asserted 4 occurrences and got 5. The sweep
was then redone on $hessian itself, spelling-agnostically, which is what
should have happened first.

Deliberately excluded after that sweep: psfm()'s two other Hessian inversions
(the sandwich H_inv, the delta-method vc). Both already guard solve() and
take their standard errors through a Jacobian, so the report's eigenvalue
narrative does not map onto them as directly.

$se_unresolved is appended at eight assemblies — GTRE and TRE share a
site but keep separate results lists — and the insertion was scoped to each
enclosing if (model_name ...) block so it could not leak into
GTRE_SEQ1/SSFE/PL80/GTRE_SEQ2, where .sm does not exist and the line
would have thrown at runtime.

The existing suite produced two more instances, and one was mine

The full local run's warning count moved 48 → 50, and the two were different
things:

• psfm("FD") at test-psfm.R:23 is genuine — 3 of 5 standard errors
  missing, smallest Hessian eigenvalue −0.00119 against a largest of 17400.
  The site every sweep missed is reachable in the package's own test suite,
  and had been reporting three unexplained NAs there all along.
• lcsfm("LCM_CN") at test-a52-opt-shape.R:91 was a false positive I
  introduced. That call passes optHessian = FALSE: no Hessian by request,
  and my report fired claiming none could be read, for 6 of 6 parameters.
  LCM_CN is the one branch of the seven whose standard-error test does not
  mention optHessian, so it was the single place the guard was missing. Fixed.

Testing

psfm("GTRE_FML") on A64's own design — data_gen_p(t = 5, N = 40, rand = 1, ...), 3 seconds, three of seven parameters with a negative variance estimate —
so no search was needed. Gated on the regime from the start this time.

Full local suite on the final code, which the earlier revision of this PR did
not have: pass 5556, fail 0, warn 49, skip 9, against a
48-warning baseline — the single addition being the genuine FD report. The
five-platform CI run is still the gate.

🤖 Generated with Claude Code

[davidhbernstein]

Scope note, found after opening this PR: psfm() is a sixth site and this PR does not cover it.

A65 was scoped with grep "sqrt(diag(solve(", but #62 had already rewritten psfm()'s idiom to .sfa_se_from_var(diag(solve(opt$hessian))), so the grep could not see it. On main at 5163c44 psfm() has six such sites — 651, 1347, 1787, 2000, 2199, 2374 — of which 651, 1787 and 2199 leave solve() unguarded, and none of the six reports a missing standard error. A singular-but-nonzero Hessian at those three errors and discards a finished panel fit, the most expensive kind the package produces.

I have not folded it in here: this branch was cut before #62 landed, so its R/psfm.R is the pre-A64 version, and enlarging a PR already in CI would mean a main merge, a NEWS.md conflict and full re-verification on a machine at load 92. It is recorded in the A65 entry as the follow-up to this PR.

Also worth noting: psfm()'s guard is a different test from the five here — any(opt$hessian == 0) | optHessian == FALSE, where a single exact zero anywhere blanks every standard error. That is over-cautious rather than wrong, and is not this defect.

[davidhbernstein]

CI caught this, and it was a platform-dependent landing point again — the fix is pushed as 66e0e9f and e291023.

What actually failed. Four of five platforms failed on one expectation, expect_identical(f$opt$convergence, 0L): the fit reports 52 there and 0 on my machine. ubuntu oldrel-1 failed four, starting with the expect_warning() itself — that platform's fit does not reach an indefinite Hessian at all.

So the run established something the local run could not. On macOS, ubuntu devel, ubuntu release and windows the warning fired — the only failing expectation was the convergence code — so the regime is reached, and the fix works, on four of the five platforms. Only oldrel-1 misses it.

The fix. Every expectation is now derived from the fit in front of it: the reported parameters must be exactly those whose standard error is non-finite, n_missing that count, n_par the length of the vector, and indefinite true iff a negative eigenvalue was read. The regime is a skip condition in both directions — the first test skips where every standard error is finite, since there is then nothing for the report to say, and the false-positive guard skips where the N = 300 fit is not itself healthy. expect_silent() is gone: demanding total silence from a fit is a stronger claim than the test needs. 12 of 12 against the branch build, 2 of 4 failing against main, so it still discriminates.

One claim corrected in NEWS (e291023): conv 0 was the headline and it is machine-specific. The zero-warnings part is the defect and holds; the convergence code is 52 on all five CI platforms, where it does carry a signal and only the missing standard errors go unexplained.

This is the same mistake #62 made a few days ago, and I had written the rule down after it. Noted again, less abstractly: it is not enough to avoid pinning the parameter values — the convergence code is part of the landing point too.

The scope note above still stands: psfm() is a sixth site and is not covered here.