When initializing a trajectory via EMRIInspiral, if no additional_args are passed, a default [0.0] is injected into the trajectory function's arguments instead of the intended None.
This causes unexpected behaviour when users subclass the base trajectory class to add custom modifications.
To reproduce:
from few.trajectory.inspiral import EMRIInspiral
traj = EMRIInspiral(func='PN5')
# execute a standard vacuum-GR trajectory with no additional arguments
_ = traj(1e6, 1e1, 0.0, 10.0, 0.0, 1.0, T=0.1)
print(traj.func.additional_args, traj.func.num_add_args)
Expected output: Because no additional arguments were passed, I expected None 0 (consistent with how additional_args are initialized in the add_fixed_parameters function of trajectory.ode.base.ODEBase.
Actual output: [0.0] 1
Because of this discrepancy, the logic breaks when building custom trajectories, because it is standard to check if additional_args is None. But this condition will currently always return False. While the user can handle this with more careful type handling to catch the discrepancy, it should be simple to fix internally for code consistency.
When initializing a trajectory via
EMRIInspiral, if noadditional_argsare passed, a default[0.0]is injected into the trajectory function's arguments instead of the intendedNone.This causes unexpected behaviour when users subclass the base trajectory class to add custom modifications.
To reproduce:
Expected output: Because no additional arguments were passed, I expected
None 0(consistent with how additional_args are initialized in theadd_fixed_parametersfunction oftrajectory.ode.base.ODEBase.Actual output:
[0.0] 1Because of this discrepancy, the logic breaks when building custom trajectories, because it is standard to check
if additional_args is None. But this condition will currently always returnFalse. While the user can handle this with more careful type handling to catch the discrepancy, it should be simple to fix internally for code consistency.