The paper says C++11 but the README says C++17 - which one is it?

This is bad:

You have to write that a little longer

a lot of the abstract base classes have conflicting pure virtual methods. All particle filter classes and FutureSimulator and ForwardMod templates might need to be organized to gel better with each other. Ideally the methods would be defined once, and would support inheriting from multiple classes.

The weight update formulas for many of the particle filters might be assuming that the resampling is beign conducted at every time point. For instance, the weights are usually updated from $1$ to $fg/q$. But if they don't start at $1$, then you can't just set the weight equal to $fg/q$, you have to multiply by it. And of course we do this in the log space...

Should I make pure virtual methods const? The sampling functions as well as the evaluator functions?

Instead of UnitTest++, might want to switch unit testing to catch2. At the very least, the new unit testing framework should support testing explicit function template specializations. Right now, unittest++ doens't seem to like those with their macros.

Closed form filters might benefit from some compile-time checks to optimize filtering for special-cases.

Closed form filters might benefit from some compile-time checks to optimize filtering for special-cases. Also, the template parameter debug could allow more testing for more conditions (e.g. things that trigger NaNs) in the non-closed-form filters.

Hi ! first of all, thank you for the work put in developing this repository.

In the Ideas List it is mentioned that : "... there is another example related to tracking ...".

1. However, in the "examples" directory I can't find this tracking example. They are all about stochastic volatility. Am I missing something?
2. Also what is the state-space model used in this tracking example ? (state dynamic and observation model)

Thanks !

(btw it seems i can't add a label to the issue myself, therefore i added it in the title)

u_sampler doesn't need to be recreated in every resample() call

overload filter() with a version that takes only one argument, so that it doesn't constructor empty std::vectors at every time point.

Users will want to be able to set seeds to check reproducibility. That should be added as a capability in the rbase base class template.

If we had (nontrivial) deterministic resamplers and samplers, we could check every particle throughout every step of the filtering process in unit tests.

For an example of resamplers, always pick the current index, always pick the first, always pick the last. For an example of samplers, always increment by 1.0.

inference in hidden markov models has a nice section (section 7.4, page 241) on describing alternative algorithms that take advantage of pre-sorted uniform variates.

Design: keep the class templates and their methods where they are. Just add one new method to each.

The instructions in the README ask the user to install a few libraries (boost, eigen3, catch2). However, the requirement on catch2 is not explained well:

1. Catch2's homepage explains that the package can be installed by just copying only the header file;
2. People running any Ubuntu-based distribution will likely install it using sudo apt install catch;
3. OTOH, the CMakeLists.txt provided by this package expects a few *.cmake files from the Catch2 distribution, which means that it requires Catch2 to be installed using a non-standard procedure. (No, apt install does not install these files where cmake can find them`.)

I see a few possible solutions:

1. Include a copy of the Catch2 header file in the source (possible if Catch2's license is compatible with this one: IANAL, so I cannot give advice here). This would be the easiest and cleanest solution;

2. Enable cmake to detect the presence of the Catch2 header file when the *.cmake files are not found

3. Explain in the README the expected way to install Catch2.

(This issue was raised while carrying on the review for JOSS: openjournals/joss-reviews#2599.)

Investigate potential modest speed improvements resulting from using a curiously recurring template pattern instead of pure virtual functions in particle filter base classes.

This idea is largely motivated by this thread here: https://codereview.stackexchange.com/questions/236425/abstract-base-classes-versus-the-curiously-recurring-template-pattern?noredirect=1#comment463461_236425

hmms should request log densities. working on a problem right now where all p(yt|xt) are zero and it messes everything up.

Consider rewriting filter() so that it makes use of two public functions: one to perform mutation and rewrighting, and the other to perform resampling. This added level of control would be useful for latency-sensitive applications that only need to make use of the results from the first stage. After that, resampling could be performed while there is plenty of downtime.

A challenge would be to ensure that a.) one cannot use both schemes simultaneously, and that if one opted for the more involved scheme, that errors would be thrown when the ordering was broken.

Or perhaps this would best be done with two separate class templates.

In a HMM model, with the filtering updates, should the log-probabilities be retained instead of probabilities? We're not exponentiating anything, but should I still be worried about numerical underflow?

add speed comparison example to demonstrate that it's faster than other libraries

Make the same type aliases available in every particle filter base class. E.g.

• ssv
• osv
• float_t

Also, there are template parameters that aren't types but hsould also be available as the same name every time

• dimx
• dimy
• nparts

in the Kalman filter, you can change the order of the prior update and posterior update, so that the state priors will be available for forecasting. Right now, there are redundant, double computations if you're calling the forecast updates

boost random number generators are probably going to be better than mine quite often. Begin phasing these in.

not sure how to do this...

statistically, these pure virtual methods need to allow for the requested arguments. The compiler warnings do get annoying though.

How can we override pure virtual functions? It would request that only one "version" of the function be defined?

I tried to build "pf" in VisualStudio and met "division by zero" errors due to the following line:
float_t maxOldLogUnNormWts(-1.0/0.0);
which can be found in bootstrap_filter.h and sisr_filter.h.