diff --git a/benchmark/operator1x1x0.cpp b/benchmark/operator1x1x0.cpp index 4765f07ed..9a81452b3 100644 --- a/benchmark/operator1x1x0.cpp +++ b/benchmark/operator1x1x0.cpp @@ -52,7 +52,7 @@ namespace void operator1x1x0(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; ::benchmark::ClobberMemory(); diff --git a/benchmark/operator1x1x1.cpp b/benchmark/operator1x1x1.cpp index 09630c605..b28e5aba1 100644 --- a/benchmark/operator1x1x1.cpp +++ b/benchmark/operator1x1x1.cpp @@ -52,7 +52,7 @@ namespace void operator1x1x1(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; ::benchmark::ClobberMemory(); diff --git a/benchmark/predict1x1x0.cpp b/benchmark/predict1x1x0.cpp index ab559d088..276da6357 100644 --- a/benchmark/predict1x1x0.cpp +++ b/benchmark/predict1x1x0.cpp @@ -52,7 +52,7 @@ namespace void predict1x1x0(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; ::benchmark::ClobberMemory(); diff --git a/benchmark/predict1x1x1.cpp b/benchmark/predict1x1x1.cpp index 2cd446905..693384b33 100644 --- a/benchmark/predict1x1x1.cpp +++ b/benchmark/predict1x1x1.cpp @@ -52,7 +52,7 @@ namespace void predict1x1x1(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; ::benchmark::ClobberMemory(); diff --git a/benchmark/update1x1x0.cpp b/benchmark/update1x1x0.cpp index 9c1e6626d..066d70389 100644 --- a/benchmark/update1x1x0.cpp +++ b/benchmark/update1x1x0.cpp @@ -52,7 +52,7 @@ namespace void update1x1x0(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; ::benchmark::ClobberMemory(); diff --git a/benchmark/update1x1x1.cpp b/benchmark/update1x1x1.cpp index bc4cb15d5..99d5c521a 100644 --- a/benchmark/update1x1x1.cpp +++ b/benchmark/update1x1x1.cpp @@ -52,7 +52,7 @@ namespace void update1x1x1(::benchmark::State &state) { for (auto _ : state) { - using kalman = fcarouge::kalman; + using kalman = fcarouge::kalman; kalman k; const float input{ 0. }; diff --git a/include/fcarouge/kalman.hpp b/include/fcarouge/kalman.hpp index 9c23142b3..4a97110c3 100644 --- a/include/fcarouge/kalman.hpp +++ b/include/fcarouge/kalman.hpp @@ -789,51 +789,43 @@ class kalman //! @name Public Filtering Member Functions //! @{ - //! @brief Runs a step of the filter. - //! - //! @details Predicts and updates the estimates per prediction arguments, - //! control input, and measurement output. + //! @brief Produces estimates of the state variables and uncertainties. //! - //! @tparam InputTypes The template parameter pack types passed in the - //! `arguments` parameters after the update arguments and before the output - //! arguments. `InputTypes` must be compatible with the `Input` type template - //! parameter of the control u. + //! @details Implements the total probability theorem. //! - //! @param arguments The prediction, update, input, and output parameters of + //! @param arguments The prediction and input parameters of //! the filter, in that order. The arguments need to be compatible with the //! filter types. The prediction parameters convertible to the //! `PredictionTypes` template pack types are passed through for computations - //! of prediction matrices. The update parameters convertible to the - //! `UpdateTypes` template pack types are passed through for computations of - //! update matrices. The control parameter pack types convertible to the - //! `Input` template type. The observation parameter pack types convertible to - //! the `Output` template type. The update and prediction types are explicitly - //! defined with the class definition and the observation parameter pack types - //! are always deduced per the greedy matching rule. However the control - //! parameter pack types must always be explicitly defined per the fair - //! matching rule. - //! - //! @note Called as `k(...);` with prediction values and output values when - //! the filter has no input parameters. The input type list is explicitly - //! empty. Otherwise can be called as `k.template operator()(...);` with prediction values, input values, and output - //! values. The input type list being explicitly specified per the fair - //! matching rule. A lambda can come in handy to reduce the verbose call - //! `const auto kf{ [&k](const auto - //! &...args) { k.template operator()(args...); } };` then called as `kf(...);`. + //! of prediction matrices. The control parameter pack types convertible to + //! the `Input` template type. The prediction types are explicitly defined + //! with the class definition. //! + //! @todo Consider whether this method needs to exist or if the operator() is + //! sufficient for all clients? //! @todo Consider if returning the state column vector X would be preferable? //! Or fluent interface? Would be compatible with an ES-EKF implementation? - //! @todo Understand why the implementation cannot be moved out of the class. - //! @todo What should be the order of the parameters? Update first? - template - inline constexpr void operator()(const auto &...arguments); + //! @todo Can the parameter pack of `PredictionTypes` be explicit in the + //! method declaration for user clarity? + inline constexpr void predict(const auto &...arguments); + + //! @brief Returns the Nth prediction argument. + //! + //! @details Convenience access to the last used prediction arguments. + //! + //! @tparam The non-type template parameter index position of the prediction + //! argument types. + //! + //! @return The prediction argument corresponding to the Nth position of the + //! parameter pack of the tuple-like `PredictionTypes` class template type. + //! + //! @complexity Constant. + template inline constexpr auto predict() const; //! @brief Updates the estimates with the outcome of a measurement. //! - //! @details Implements the Bayes' theorem. Combine one measurement and the - //! prior estimate. + //! @details Also known as the observation or correction step. Implements the + //! Bayes' theorem. Combine one measurement and the prior estimate. //! //! @param arguments The update and output parameters of //! the filter, in that order. The arguments need to be compatible with the @@ -864,38 +856,46 @@ class kalman //! @complexity Constant. template inline constexpr auto update() const; - //! @brief Produces estimates of the state variables and uncertainties. + //! @brief Runs a full step of the filter. //! - //! @details Implements the total probability theorem. + //! @details Predicts and updates the estimates per arguments, + //! control input, and measurement output. //! - //! @param arguments The prediction and input parameters of + //! @tparam InputTypes The template parameter pack types passed in the + //! `arguments` parameters after the update arguments and before the output + //! arguments. `InputTypes` must be compatible with the `Input` type template + //! parameter of the control u. + //! + //! @param arguments The prediction, update, input, and output parameters of //! the filter, in that order. The arguments need to be compatible with the //! filter types. The prediction parameters convertible to the //! `PredictionTypes` template pack types are passed through for computations - //! of prediction matrices. The control parameter pack types convertible to - //! the `Input` template type. The prediction types are explicitly defined - //! with the class definition. + //! of prediction matrices. The update parameters convertible to the + //! `UpdateTypes` template pack types are passed through for computations of + //! update matrices. The control parameter pack types convertible to the + //! `Input` template type. The observation parameter pack types convertible to + //! the `Output` template type. The update and prediction types are explicitly + //! defined with the class definition and the observation parameter pack types + //! are always deduced per the greedy matching rule. However the control + //! parameter pack types must always be explicitly defined per the fair + //! matching rule. + //! + //! @note Called as `k(...);` with prediction values and output values when + //! the filter has no input parameters. The input type list is explicitly + //! empty. Otherwise can be called as `k.template operator()(...);` with prediction values, input values, and output + //! values. The input type list being explicitly specified per the fair + //! matching rule. A lambda can come in handy to reduce the verbose call + //! `const auto kf{ [&k](const auto + //! &...args) { k.template operator()(args...); } };` then called as `kf(...);`. //! - //! @todo Consider whether this method needs to exist or if the operator() is - //! sufficient for all clients? //! @todo Consider if returning the state column vector X would be preferable? //! Or fluent interface? Would be compatible with an ES-EKF implementation? - //! @todo Can the parameter pack of `PredictionTypes` be explicit in the - //! method declaration for user clarity? - inline constexpr void predict(const auto &...arguments); - - //! @brief Returns the Nth prediction argument. - //! - //! @details Convenience access to the last used prediction arguments. - //! - //! @tparam The non-type template parameter index position of the prediction - //! argument types. - //! - //! @return The prediction argument corresponding to the Nth position of the - //! parameter pack of the tuple-like `PredictionTypes` class template type. - //! - //! @complexity Constant. - template inline constexpr auto predict() const; + //! @todo Understand why the implementation cannot be moved out of the class. + //! @todo What should be the order of the parameters? Update first? + template + inline constexpr void operator()(const auto &...arguments); //! @} };