F1: fertility-rate predictor inconcistency between estimation and Java implementation
@dariaple がすでに取り組んでいます。
2026年10月23日 から。
評価
この issue はまだ評価されていません。
説明
The UK F1 equation is estimated using a national annual fertility-rate series, but Java evaluates the coefficient using a regional measure derived from population projections. This mismatch remains in develop at commit 971d050, checked on 23 October 2026.
Estimation
The UID construction assigns dukfr by calendar year only, with the label "UK General fertility rate (ONS)": 02_create_UKHLS_variables.do, lines 1846–1867.
The regression preparation then sets fertilityRate = dukfr (variable_update.do, lines 679–680), and the active F1 probit includes fertilityRate. Thus all observations in the same year receive the same national rate, irrespective of region.
Java implementation
For ordinary simulated persons, the FertilityRate getter instead calls getFertilityRateByRegionYear(getRegion(), getYear()). The lower-case fertilityRate getter delegates to it (lines 4016–4018).
Parameters.java, lines 1932–1960 constructs this as the projected number of children aged zero in the region divided by the projected number of women between the maternity-age limits, currently 18–49 (constants). The getter multiplies this by 1,000.
The coefficient is therefore applied to a different predictor from the one used in estimation: both the geographical variation and the construction differ. This is not a missing per-1,000 conversion, and switching fertility alignment on or off does not make the two predictor definitions consistent. The size of the effect on validation results needs to be assessed after the intended definition is agreed.
Question and proposed resolution
Should F1 be re-estimated using a consistently defined regional fertility-rate series, as suggested in the meeting, or should Java instead use a national predictor consistent with estimation?
Would it make sense to agree on a common definition for estimation and simulation, including the geographical coverage, age range and timing? If this involves changing the predictor used in estimation, I imagine we would also need to re-estimate F1. I would be happy to help check the resulting consistency between Stata and Java.
- 主要言語
- Java
- スター
- 26
- フォーク
- 38
- 平均マージ
- 13時間 5分
- マージ済み PR（30日）
- 7
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
simpaths/SimPaths のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 89/100
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
H2: should dlltsd01 be set to zero for retirees?対応中かも @Kolndre が 5 日前に担当しました。 オープン
simpaths/SimPaths の issue をすべて見る
似ている issue
-
Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
protobuf
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
FasterXML/jackson-dataformats-binary#874 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
HexaHexes/infinite-dungeon-spawn-safety#17 ·
メンテナーはふだん 1 日以内に返信