fix(data): self-consistency corrections for 18 monitor records - #348
Merged
Merged
Conversation
Fill null aspect_ratio derived from each record's own resolution field: 16:9 for 1920x1080/2560x1440/3840x2160, 21:9 for 3440x1440/3840x1600, 32:9 for 3840x1080, 16:10 for 1280x800. Values come only from data already present in the same record; each name is consistent with the derived ratio. Ambiguous records whose resolution and name disagree were left unchanged. Refs #296
Seungpyo1007
force-pushed
the
Seungpyo1007/monitor-derivation
branch
from
September 30, 2026 00:13
0c7f6b6 to
4f6c28a
Compare
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.
Summary
Fills null
aspect_ratioon 18data/monitor/records, deriving each value only from data already present in the same record (itsresolutionfield, cross-checked against the record's ownname). No external sources, no invention.Derivation convention (matches the dataset's existing values):
1920x1080/2560x1440/3840x2160->16:93440x1440/3840x1600->21:9(ultrawide, the label this catalog already uses)3840x1080/5120x1440->32:91280x800->16:10Records fixed (18)
acer-eda343cur-177 (21:9), asus-ve278h-844 (16:9), asus-vg328h1b-653 (16:9), dell-s2240m-802 (16:9), dell-s2316m-868 (16:9), gigabyte-gs34wqc-779 (21:9), innocn-hdr400-218 (32:9), innoview-portable-669 (16:9), lenovo-thinkvision-full-465 (16:9), lenovo-p24h-30-434 (16:9), lg-34bq77qb-637 (21:9), lg-34gp63a-109 (16:9), lg-38bq88c-648 (21:9), lg-digital-signage-444 (16:9), lg-ultragear-46 (16:9), lilliput-ip65-612 (16:10), msi-mp341cqw-377 (21:9), viewsonic-vg2239smh-573 (16:9).
Left unchanged (ambiguous / internally inconsistent)
Records where the
resolutionfield and thenamedisagree, so no single value is safely derivable from the record alone: dell-p3421w-384 and lg-34wl500-578 (name says 21:9 but resolution implies 16:9), the SAMSUNG 49"/34" Dual-QHD/DQHD/4K entries whose resolution is 3440x1440 (g93sc-9, business-59, odyssey-41, viewfinity-383), lg-ultragear-466 (name 27" 1440p vs resolution 5120x1440), kensington-fs240-368 (privacy-screen accessory naming both 16:10 and 16:9), and lilliput-fa1014-767 (name explicitly states 16:9 while resolution is 1280x800). Size differences observed elsewhere are marketing "Class"/nominal vs actual-panel values and were left as-is.Verification
python -m app.validate-> passedintegrity_check.py --strict-> no hard anomaliespython -m app.dump; only the 18 affected monitor detail files changed.Refs #296