Summary
In src/features/greeks.py, GreeksCalculator normalizes its Greeks for neural-network input, but calculate_gamma scales in the opposite direction from calculate_theta and calculate_vega. The gamma docstring also contradicts the code.
Evidence
# calculate_gamma (line ~80)
gamma = norm.pdf(d1) / (S * sigma * math.sqrt(T))
return float(gamma * S) # multiplies by S
# calculate_theta (line ~116)
daily_theta = theta / 365.0 / S # divides by S
return float(daily_theta)
# calculate_vega (line ~142)
return float(vega / S / 100) # divides by S
The gamma docstring says: "Gamma value normalized by underlying price" and the inline comment says "Normalize by underlying price to get relative gamma" — but the code multiplies by S, which is the opposite of dividing by the underlying price. Theta and vega both divide by S.
Why it matters
These values feed the position feature vector / neural network, where consistent scaling across Greeks matters. As written:
gamma * S = norm.pdf(d1) / (sigma * sqrt(T)), which grows with the dollar price level rather than being normalized by it.- theta and vega are per-dollar normalized.
A high-priced underlying will produce a gamma feature on a very different scale from its theta/vega features, and from the gamma of a low-priced underlying — undermining the normalization the module says it provides.
Open question / fix direction
Decide the intended convention and make all three consistent:
- If "normalized by underlying price" is intended (matching theta/vega), gamma should divide by
S (e.g. gamma / S or the standard gamma * S**2 / 100 for dollar gamma per 1% move — pick one and document it).
- If
gamma * S ("percent gamma") is intentional, update the docstring/comment and reconcile it with theta/vega so the feature scales are comparable.
Flagging for the maintainer to confirm intent rather than asserting a single correct form.
Summary
In
src/features/greeks.py,GreeksCalculatornormalizes its Greeks for neural-network input, butcalculate_gammascales in the opposite direction fromcalculate_thetaandcalculate_vega. The gamma docstring also contradicts the code.Evidence
The gamma docstring says: "Gamma value normalized by underlying price" and the inline comment says "Normalize by underlying price to get relative gamma" — but the code multiplies by
S, which is the opposite of dividing by the underlying price. Theta and vega both divide byS.Why it matters
These values feed the position feature vector / neural network, where consistent scaling across Greeks matters. As written:
gamma * S=norm.pdf(d1) / (sigma * sqrt(T)), which grows with the dollar price level rather than being normalized by it.A high-priced underlying will produce a gamma feature on a very different scale from its theta/vega features, and from the gamma of a low-priced underlying — undermining the normalization the module says it provides.
Open question / fix direction
Decide the intended convention and make all three consistent:
S(e.g.gamma / Sor the standardgamma * S**2 / 100for dollar gamma per 1% move — pick one and document it).gamma * S("percent gamma") is intentional, update the docstring/comment and reconcile it with theta/vega so the feature scales are comparable.Flagging for the maintainer to confirm intent rather than asserting a single correct form.