nx_ansur_regress.nx

nx_ansur_regress.nx -- DOES HUMAN PROPORTION CHANGE WITH STATURE? Regress a landmark ratio on stature over the ANSUR II sample and let the SLOPE answer. WHY. nx_skelgen stores every segment as PER-MILLE OF STATURE, and its own docstring states the consequence as a feature: "so the same rules generate a child, an adult or a giant". Measured, femur/stature is 0.2411 at 1750 mm and 0.2407/0.2411 at 1400/1900 -- CONSTANT BY CONSTRUCTION. It is not emergent; it is the storage format. A rig that only scales is a doll at every size. The fix is mechanical because ANSUR measures nx_skelgen's OWN landmarks: acromialheight/stature <-> BP_ACROMION = 818 per-mille trochanterionheight/stature <-> BP_TROCH = 530 per-mille Regress (landmark_height / stature) ON stature. A NON-ZERO SLOPE IS THE MISSING PROPORTION CHANGE, and the slope itself is the correction term. nx_ansur_regress <ansur.csv> <landmark_column_name> COLUMNS ARE RESOLVED BY NAME FROM THE HEADER ROW AT RUNTIME, never by a hardcoded index: ANSUR's columns are alphabetical and the male and female files must both parse, so an index literal would be a magic number that silently reads the wrong measure if either file differs. THE THREE TRAPS, QUOTED FROM THE PUBLISHER, ALL OF WHICH BITE THIS COMPUTATION: 1. Units are millimetres EXCEPT MASS, WHICH IS HECTOGRAMS DESPITE ITS COLUMN BEING NAMED weightkg -- a 10x error waiting. This organ touches no mass column, and refuses any column whose name contains "weight" so the trap cannot be walked into later. 2. The trailing Heightin / Weightlbs columns are SELF-REPORTED and DISAGREE with the official measures. This organ uses `stature`, never Heightin, and refuses those names by name. 3. The sample is military including reservists and the publisher states it "is still not an approximation of the US Civilian population". THAT BOUND TRAVELS WITH EVERY NUMBER THIS ORGAN PRINTS, so it is printed WITH them rather than left in a doc nobody reads. ARITHMETIC. Integer-only, and mean-centred ON PURPOSE: the raw cross-products (n*Sxy - Sx*Sy) reach ~5.7e12 and multiplying by a precision scale would approach the i64 ceiling. Centring first keeps every term small (dx ~ +/-100, dy ~ +/-30), so the scaled slope cannot overflow. Two passes, no floats -- NishiLang has no float type and this needs none. license_tier: ORIGINAL expect_exit: 0