Repository navigation
BUG: setting a declared eccentricity back to None leaves the old distribution in place #1171
Description
What happens
add_cp_eccentricity and add_thrust_eccentricity accept None to mean an input is not randomized, and their docstrings document x and y as optional. Passing None after a distribution was configured does not remove the earlier one, so the next reseed brings it back.
stochastic = StochasticRocket(rocket=calisto, radius=0.0127 / 2)
stochastic.add_cp_eccentricity(x=0.001)
stochastic.add_cp_eccentricity(x=None)
stochastic._set_stochastic(7)On develop at 7822ab1d:
after the None call, still declared: True
after the reseed, the attribute: (0, 0.001, Generator.normal)
in the generated dict: True
The caller asked for the uncertainty to go away and it is still being drawn.
Why
StochasticModel._declare_stochastic_input returns early on None rather than removing the entry:
if input_value is None:
return
self.__stochastic_dict[input_name] = input_valuedict_generator walks __stochastic_dict, so the stale declaration reaches the draw. The early return is right for the case it was written for, which is add_cp_eccentricity(x=0.001) with no y, where None means "was never given" rather than "take it away". The two meanings are not distinguished.
Fix
Removing the entry instead of returning early covers the second meaning, and leaves the first alone as long as removal only happens for a name that is being configured. #1169 adds _reconfigure_stochastic_input, which already owns the replacement half of this, so the removal fits there in about a line.
Worth a test for each meaning: add_cp_eccentricity(x=0.001) with no y must not declare y, and add_cp_eccentricity(x=None) after x=0.001 must remove x.
Where it came from
The behaviour arrived with #1167, which declared these inputs so a fixed seed could reproduce them. Reconfiguration was not part of that change. Raised separately rather than folded into #1169, which fixes the other half of the same lifecycle and is under review.
Activity
BUG: take a late input away when it is configured to None
BUG: take a late input away when it is configured to None
BUG: record a draw after the subclass that adjusts it, not before
BUG: stop an omitted axis from taking away what was declared
thc1006 commentedon Aug 16, 2026
Worth recording what this costs, because I tried folding it into #1169 and took it back out.
add_cp_eccentricityandadd_thrust_eccentricityboth defaultxandytoNone, so an omitted axis and an explicitNonearrive identically. Removing onNonetherefore takes away an axis the caller never mentioned:On
developthe second call leavesyalone, which is what anything already written depends on.So removal needs an argument that omission cannot supply. A private sentinel as the default distinguishes the two readings:
That fixes it, and it is a signature change on a public method.
inspect.signaturestops reportingNone, the documented default changes, and a caller who currently writesy=Nonebecause it computed to nothing would start losing their declaration rather than keeping it. None of that is wrong, but it is a decision about the public API rather than a bug fix, which is why it does not belong inside a change about nominal ownership.#1169 keeps
develop's behaviour and has a regression test for the omitted axis, so nothing here gets worse in the meantime.DOC: say what a second add_cp_eccentricity call does
BUG: take a late input away when it is configured to None
BUG: record a draw after the subclass that adjusts it, not before
BUG: stop an omitted axis from taking away what was declared
DOC: say what a second add_cp_eccentricity call does
BUG: keep stochastic nominal values stable across reseeds (#1169)