You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current design of SigmaPointTransform, makes it quite uncomfortable to implement a continuous-time variants of the sigma-point transforms, which require the function evaluation process to be replaced with the solution of the ODE.
That is, instead of "pushing" points through the nonlinearity, like so
# push sigma-points through non-linearityfx=np.apply_along_axis(f, 0, x, fcn_pars)
one has to "flow" the points through nonlinearity for a given period of time (t0, t1) using and ODE solver, like so
t0, t1=tf_pars['t0'], tf_pars['t1']
dim_out=f(0, mean).shape[0]
num_points=self.unit_sp.shape[1]
fx=np.empty((dim_out, num_points))
foriinrange(num_points):
# TODO: how to ensure function signature f(t, x)?fx[:, i] =solve_ivp(f, (t0, t1), x[:, i], t_eval=(t1, ), method='RK45', rtol=1e-5).y.squeeze()
That is to say, each sigma-point is used as initial condition in an initial value problem (IVP).
When inheriting from SigmaPointTransform, several difficulties follow:
apply() method is largely the same, only the function evaluation is replaced
there is no way to determine the output dimensionality of the function f, other than the obtuse way. Which is to feed in a dummy input and read off the dimensionality from .shape.
no way to guarantee that the solve_ivp receives function signature with proper argument order (i.e. time t as first arg and y as second arg).
Conclusion SigmaPointTransform would benefit from rewriting, where the nonlinearity evaluation process is separated out into a dedicated function (very much akin, if not the same, to what is in the BQTransform. This solves the first point and makes it easier to reuse the SigmaPointTransform machinery for potential inclusion of the continuous-time variants.
The last two points, however, still remain an issue. One could just pass in the TransitionModel, which carries with it all the nonlinearity parameters (including the output dimensionality).
The text was updated successfully, but these errors were encountered:
Current design of
SigmaPointTransform
, makes it quite uncomfortable to implement a continuous-time variants of the sigma-point transforms, which require the function evaluation process to be replaced with the solution of the ODE.That is, instead of "pushing" points through the nonlinearity, like so
one has to "flow" the points through nonlinearity for a given period of time
(t0, t1)
using and ODE solver, like soThat is to say, each sigma-point is used as initial condition in an initial value problem (IVP).
When inheriting from
SigmaPointTransform
, several difficulties follow:apply()
method is largely the same, only the function evaluation is replacedf
, other than the obtuse way. Which is to feed in a dummy input and read off the dimensionality from.shape
.solve_ivp
receives function signature with proper argument order (i.e. timet
as first arg andy
as second arg).Conclusion
SigmaPointTransform
would benefit from rewriting, where the nonlinearity evaluation process is separated out into a dedicated function (very much akin, if not the same, to what is in theBQTransform
. This solves the first point and makes it easier to reuse theSigmaPointTransform
machinery for potential inclusion of the continuous-time variants.The last two points, however, still remain an issue. One could just pass in the
TransitionModel
, which carries with it all the nonlinearity parameters (including the output dimensionality).The text was updated successfully, but these errors were encountered: