How do I install the Pyfixest Cupy64 Absorbed Regressors skill?

Run npx skillmds@latest add kennethkhoocy/pyfixest-cupy64-absorbed-regressors in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pyfixest Cupy64 Absorbed Regressors safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pyfixest Cupy64 Absorbed Regressors?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pyfixest Cupy64 Absorbed Regressors free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pyfixest Cupy64 Absorbed Regressors?

kennethkhoocy (@kennethkhoocy) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pyfixest Cupy64 Absorbed Regressors by kennethkhoocy

Name: Pyfixest Cupy64 Absorbed Regressors
Author: kennethkhoocy

Pyfixest Cupy64 Absorbed Regressors

pyfixest demeaner_backend="cupy64" (including its CPU fallback when cupy is absent) is NOT numerically identical to the default numba backend and does NOT drop fully-absorbed/collinear regressors the same way. Use when: (1) adding demeaner_backend="cupy64" to existing pf.feols/fepois calls changes the printed coefficient table, (2) a regression report suddenly gains rows with absurd estimates (e.g. coef 435.8, SE 7106) for controls absorbed by the fixed effects, (3) diffing outputs before/after a backend change, or (4) anything parses a pyfixest text report by line position.

kennethkhoocy Updated Sep 17, 2026

File contents

pyfixest cupy64 backend: absorbed regressors survive, reports change shape

Problem

Adding demeaner_backend="cupy64" to an existing pf.feols() call is treated as a pure performance switch, but it changes the output: regressors with zero within-FE identifying variation (fully absorbed by the fixed effects) that the default numba backend silently drops are RETAINED by the cupy64 path (also in its scipy/CPU fallback when cupy is not installed). They appear in the coefficient table as non-identified garbage (huge coefficient, huge SE).

Context / Trigger Conditions

Observed 2026-07-18 (Specialist Directors US, H5 re-baseline audit): adding the kwarg to 4 feols sites left the headline triple stable to 4 decimals (B1 diff 1.45e-6, SE diff 9.9e-6) but the text report grew from 366 to 390 lines — 24 new rows for absorbed controls (e.g. event_x_lrisk = 435.8059, SE 7106.3365) under firm-year + director FE, where firm-year-level variables have no identifying variation.

Solution

Treat a backend change as a POTENTIALLY OUTPUT-CHANGING edit: diff the report and expect schema changes, not byte equality. Verify the coefficients of interest at ~4-decimal precision instead.
Never interpret retained absorbed-regressor rows as estimates; check within-FE variation before reading nuisance coefficients.
Never parse pyfixest text reports by line position; anchor on the variable name of the coefficient you need.
When byte-stable reports matter (regression-tested pipelines), pin the backend consistently everywhere rather than mixing backends across runs.

Verification

Re-run one model with and without the kwarg; compare: headline coef equal to ~1e-6, coefficient-row sets DIFFERENT (absorbed regressors present only under cupy64). That asymmetry confirms this behavior rather than a data change.

Notes

Applies even with no GPU: the fail-open CPU fallback shows the same retention behavior, so "cupy isn't installed" does not make the kwarg inert.
The headline inference (identified coefficients, clustered SEs) agrees to reporting precision; this is a report-shape/nuisance-row issue, not a correctness issue for identified estimates.

---name: pyfixest-cupy64-absorbed-regressorsdescription: pyfixest demeaner_backend="cupy64" (including its CPU fallback when cupy is absent) is NOT numerically identical to the default numba backend and does NOT drop fully-absorbed/collinear regressors the same way. Use when: (1) adding demeaner_backend="cupy64" to existing pf.feols/fepois calls changes the printed coefficient table, (2) a regression report suddenly gains rows with absurd estimates (e.g. coef 435.8, SE 7106) for controls absorbed by the fixed effects, (3) diffing outputs before/after a backend change, or (4) anything parses a pyfixest text report by line position.---# pyfixest cupy64 backend: absorbed regressors survive, reports change shape## ProblemAdding `demeaner_backend="cupy64"` to an existing `pf.feols()` call is treatedas a pure performance switch, but it changes the output: regressors with zerowithin-FE identifying variation (fully absorbed by the fixed effects) that thedefault numba backend silently drops are RETAINED by the cupy64 path (also inits scipy/CPU fallback when cupy is not installed). They appear in thecoefficient table as non-identified garbage (huge coefficient, huge SE).## Context / Trigger ConditionsObserved 2026-07-18 (Specialist Directors US, H5 re-baseline audit): addingthe kwarg to 4 feols sites left the headline triple stable to 4 decimals(B1 diff 1.45e-6, SE diff 9.9e-6) but the text report grew from 366 to 390lines — 24 new rows for absorbed controls (e.g. `event_x_lrisk = 435.8059`,SE `7106.3365`) under firm-year + director FE, where firm-year-levelvariables have no identifying variation.## Solution1. Treat a backend change as a POTENTIALLY OUTPUT-CHANGING edit: diff the report and expect schema changes, not byte equality. Verify the coefficients of interest at ~4-decimal precision instead.2. Never interpret retained absorbed-regressor rows as estimates; check within-FE variation before reading nuisance coefficients.3. Never parse pyfixest text reports by line position; anchor on the variable name of the coefficient you need.4. When byte-stable reports matter (regression-tested pipelines), pin the backend consistently everywhere rather than mixing backends across runs.## VerificationRe-run one model with and without the kwarg; compare: headline coef equal to~1e-6, coefficient-row sets DIFFERENT (absorbed regressors present only undercupy64). That asymmetry confirms this behavior rather than a data change.## Notes- Applies even with no GPU: the fail-open CPU fallback shows the same retention behavior, so "cupy isn't installed" does not make the kwarg inert.- The headline inference (identified coefficients, clustered SEs) agrees to reporting precision; this is a report-shape/nuisance-row issue, not a correctness issue for identified estimates.

Frequently asked questions