Skip to content

Commit

Permalink
more typos
Browse files Browse the repository at this point in the history
  • Loading branch information
tbrown122387 committed Oct 7, 2020
1 parent 01793c1 commit e5f9366
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions paper/paper.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ bibliography: paper.bib

# Summary

The ``PF`` library provides **class and function templates** that offer fast implementations for a variety of particle filtering algorithms. Each of these algorithms are useful for a wide range of time series models.
The ``PF`` library provides **class and function templates** that offer fast implementations for a variety of particle filtering algorithms. Each of these algorithms is useful for a wide range of time series models.

In this library, each available particle filtering algorithm is provided as an abstract base class template. Once the data analyst has a specific state-space or hidden Markov model in mind, she will pick which type(s) of particle filtering algorithm(s) to associate with that model by including the appropriate header file. For each model-particle filter pair, she will write a class template for her model that inherits from the particle filter's base class template.

Expand All @@ -35,25 +35,25 @@ p(x_t \mid y_t, y_{t-1}, \ldots, y_1).

Unfortunately, it takes time and effort to implement different particle filters well, and this is true for two reasons. First, the mathematical notation used to describe them can be complex. The second reason is that, even if they are correctly implemented, they can be quite slow, limiting the number of tasks that they would be feasible for. This library attempts to provide speed and abstraction to mitigate these two difficulties.

Additionally, this software is designed in an object-oriented manner. This allows for individual particle filters to be used in isolation, and it also facilitates the implementation of more complicated algorithms that update many particle filters through many iterations in a stateful way, possibly in parallel. For this second class of algorithms, there are usually two necessary loops: the "outer" loop that loops over time, and the "inner" loop that iterates over each distinct particle filter. Without an object-oriented design, there would be a third loop, which loops over all particle samples in each particle filter. Some examples of algorithms that run many particle filter within the overall algorithm are are particle filters with parallelized resampling schemes [@1453776,1309.2918], particle Markov chain Monte Carlo algorithms [@pmcmc], importance sampling "squared" [@issquared], and the particle swarm algorithm [@pswarm].
Additionally, this software is designed in an object-oriented manner. This allows for individual particle filters to be used in isolation, and it also facilitates the implementation of more complicated algorithms that update many particle filters through many iterations in a stateful way, possibly in parallel. For this second class of algorithms, there are usually two necessary loops: the "outer" loop that loops over time, and the "inner" loop that iterates over each distinct particle filter. Without an object-oriented design, there would be a third loop, which loops over all particle samples in each particle filter. Some examples of algorithms that run many particle filters within the overall algorithm are particle filters with parallelized resampling schemes [@1453776,1309.2918], particle Markov chain Monte Carlo algorithms [@pmcmc], importance sampling "squared" [@issquared], and the particle swarm algorithm [@pswarm].

Finally, this library is "header-only." This will allow some users to build their own ``C++`` project by `#include`-ing relevant headers from this library and pointing the compiler at the `include/pf/` directory (this is "Option 2" described in the [`README.md`](https://github.com/tbrown122387/pf/blob/master/README.md) file). On the other hand, other uses will prefer to use the `CMake` build procedure (this is "Option 1" in the `README.md` file), as this will help build the included unit tests and more closely follows the style of the provided example code projects.

# Examples

A fully-worked example is provided along with this software available in the `examples/` directory in the Github repository. This example considers modeling a financial time series with a simple stochastic volatility model [@taylor82] with three parameters: $\beta, \phi$ and $\sigma$. For this model, the observable rate of return $y_t$ is normally distributed after conditioning on the contemporaneous state random variable $x_t$. The mean parameter of this normal distribution will remain fixed at $0$. However, the scale of this distribution will vary with the evolving $x_t$. When $x_t$ is relatively high, the returns will have a high conditional variance and be "volatile." When $x_t$ is low, the returns will be much less volatile.
A fully-worked example is provided with this software and is made available in the `examples/` directory in the Github repository. This example considers modeling a financial time series with a simple stochastic volatility model [@taylor82] with three parameters: $\beta, \phi$ and $\sigma$. For this model, the observable rate of return $y_t$ is normally distributed after conditioning on the contemporaneous state random variable $x_t$. The mean parameter of this normal distribution will remain fixed at $0$. However, the scale of this distribution will vary with the evolving $x_t$. When $x_t$ is relatively high, the returns will have a high conditional variance and be "volatile." When $x_t$ is low, the returns will be much less volatile.

The observation equation is
\begin{eqnarray}
y_t = \beta e^{x_t/2} z_t
\end{eqnarray}
where $\{z_t\}_{t=0}^T$ are independent and identically distributed (iid) normal random variates.
where $\{z_t\}_{t=1}^T$ are independent and identically distributed (iid) normal random variates.

The state evolves randomly through time as an autoregressive process of order one:
\begin{eqnarray}
x_t = \phi x_{t-1} + \sigma z'_t.
\end{eqnarray}
The collection $\{z'_t\}_{t=1}^T$ are also assumed to be iid normal random variates. At time $1$, we assume the first state follows a mean zero normal distribution with $\sigma^2/(1-\phi^2)$. For simplicity, all of our proposal distributions are chosen to be the same as the state transitions.
The collection $\{z'_t\}_{t=1}^T$ are also assumed to be iid normal random variates. At time $1$, we assume the first state follows a mean zero normal distribution: $x_1 = sigma/\sqrt{1-\phi^2}z_1'$. For simplicity, all of our proposal distributions are chosen to be the same as the state transitions.

The file [`examples/svol_sisr.h`](https://github.com/tbrown122387/pf/blob/master/examples/svol_sisr.h) provides an example of writing a class template called `svol_sisr` for this model-algorithm pair. Any model-algorithm pair will make use of a resampler type (found in `include/pf/resamplers.h`), sampler functions (found in `include/pf/rv_samp.h`), and density evaluator functions (found in `include/pf/rv_eval.h`). Because you are writing a class template instead of a class, the decision of what to pass in as template parameters will be pushed back to the instantiation site. These template parameters are often changed quite frequently, so this design allows them to be changed only in one location of the project.
Instantiating an object after the class template has been written is much easier than writing the class template itself. Just provide the template parameters and the constructor parameters in the correct order. For example,
Expand All @@ -68,7 +68,7 @@ As (possibly real-time, streaming) data becomes available, updating the model is
sisrsvol.filter(yt);
```

The repository also provides an implementation of the "almost constant velocity model" that is comparable to the one described in section 5.1 of [@Johansen:2009:JSSOBK:v30i06]. This can be found in `smctc_comparison_example/` directory. Comparing the two implementations, ours makes use of more modern and higher-level `C++` types and features, and is slightly faster at first glance. Our implementation is written to match as many aspects of the one provided in SMCTC sample code: both use a boostrap filter proposal distribution, both only retain the most particles instead of the entire particle trajectory, both use the same parameters, both iterate across the same data set, and both use $100,000$ particles. Both programs were run on Ubuntu 18.04 with an Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz chip. Ours ran in 2.883 seconds, while the SMCTC-provided implementation ran in 5.605 seconds. However, this test is far from conclusive: these packages make use of different random number generators, different data-reading functions, and different build procedures.
The repository also provides an implementation of the "almost constant velocity model" that is comparable to the one described in section 5.1 of [@Johansen:2009:JSSOBK:v30i06]. This can be found in the `smctc_comparison_example/` directory. Comparing the two implementations, ours makes use of more modern and higher-level `C++` types and features and is slightly faster at first glance. Our implementation is written to match as many aspects of the one provided in SMCTC sample code as possible: both use a bootstrap filter proposal distribution, both only retain the most recent particles instead of the entire particle trajectory, both use the same parameters, both iterate across the same data set, and both use $100,000$ particles. Both programs were run on Ubuntu 18.04 with an Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz chip. Ours ran in 2.883 seconds, while the SMCTC-provided implementation ran in 5.605 seconds. However, this test is far from conclusive: these packages make use of different random number generators, different data-reading functions, and different build procedures.

# References

0 comments on commit e5f9366

Please sign in to comment.