Conversation
The screen's guard `if (any(!is.finite(yv)) || any(yv <= 0)) return(1)` treated NA/NaN (missing data) as disqualifying, so ANY gap forced lambda = 1 -- e.g. pts(AirPassengers-with-NA, "ZZZ") gave PTS(1,N,N) instead of the log fit PTS(0,L,T). But NA is not a Box-Cox domain problem (only non-positive values are), and the rest of the screen is already NA-safe: msdecompose imputes the gaps and the block statistics use na.rm / nan-aware reductions. Disqualify only on non-positive *finite* values now (filter to finite first -- `NA <= 0` is NA, which would error inside `if`). Applied identically in R (.pts_guerrero_decomp_lambda) and Python (guerrero_decomp_lambda). Verified: the NA series now screens to lambda ~= 4.84e-5 (log), matching the gap-free series, in both languages. Tests added: - R tests/testthat/test_stress.R: NA-injected AirPassengers screens to the same lambda as the clean series (not collapsed to 1). - Python tests/test_functionality.py: NaN-injected multiplicative series keeps the screen's lambda (smooth-guarded). R golden master unchanged (the NA path was uncovered before); full R suite, Python functionality suite, ruff and mypy all green. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
New ZZZ_na spec: AirPassengers with NA at positions 41-43 (matched 0-based in Python), confirming R<->Python agree on the full output for a gapped series -- lambda, model, coef, logLik, ICs, nobs, nParam, sigma, and fitted/residuals (NaN at the 3 missing positions agreeing). Matches to 2.6e-9, so msdecompose imputation + the engine's NA handling line up across the two front-ends. Test plumbing: - dump_pts_reference.R: per-spec NA injection; na = "null" so NA serialises to JSON null. - test_pts_parity.py: NA_POS applies the gaps to the data; _to_float_array maps null/"NA" -> nan; vdiff compares fitted/residuals NaN-aware over the common length. The common-length comparison also absorbs a separate, pre-existing quirk: R's fitted/residuals occasionally carry one extra trailing element across sessions (a latent comp/fitted off-by-one in the R engine; Python is always nobs-long). Flagged for separate investigation -- it does not affect the values. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The 145-vs-144 fitted/residuals "nondeterminism" was a harness bug, not an engine bug: dump_pts_reference.R used sp$na, which partial-matches the list's "name" element for specs with no na field. That made the NA branch run as yi[<model-string>] <- NA, appending a named NA and growing the series 144->145. Use exact [["na"]]. The engine and pts() were always deterministic at 144; drop the ±1-length tolerance from vdiff accordingly. Also fix the verbose=TRUE footnote: '*' marks lambda held fixed (not jointly estimated), not "snapped to a fixed anchor" -- snapping no longer occurs in the normal R-side-screen flow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The python-check job recompiled the Armadillo-heavy C++ engine from scratch every run. scikit-build-core uses a fresh build dir, so CMake's incremental build can't persist -- but ccache caches at the object level and survives across runs. Add hendrikmuhs/ccache-action and route the build through it via cmake.define.CMAKE_CXX_COMPILER_LAUNCHER=ccache. Also enable setup-python's pip cache keyed on pyproject.toml. (R-CMD-check already caches its library via setup-r-dependencies.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Distribution name only; the import name stays `muse` (wheel.packages = ["src/muse"]). Updates pyproject, README install instructions, and the release/wheel workflows (Trusted Publishing project + environment URL). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cibuildwheel's CIBW_BEFORE_ALL_MACOS does `brew install armadillo`, but Homebrew installs headers under its own prefix (/opt/homebrew on Apple Silicon, /usr/local on Intel), which Clang does not search by default -- so the compile failed with "'armadillo' file not found". Linux worked only because libarmadillo-dev lands in /usr/include. Add an APPLE-only block to CMakeLists that queries `brew --prefix` (with /opt/homebrew and /usr/local fallbacks) and adds <prefix>/include when the Armadillo header is present. BLAS/LAPACK still resolve via Accelerate. Fix is self-contained in CMake, so local Mac builds work too. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.