Plan for next features

[JoseKling]

What I have

Models

Each with the methods: simulate, estimate, intensity, rescale. If I understood correctly, these correspond to Base.rand, StatsAPI.fit, intensity and time_change in PointProcesses.jl, respectively.

• Homogeneous Poisson
• Standard Hawkes processes
• Renewal models
• Two-stage model
• Additive inhomogeneous Poisson
  $$\lambda(t; \mu, \gamma) = \mu + \gamma f(t), ~f ~\text{some fixed function} $$
• Multiplicative inhomogeneous Poisson
  $$\lambda(t; \mu, \gamma) = \mu e^{\gamma f(t)}$$
• Inhomogeneous Hawkes
  $$\lambda(t; \mu, \gamma, \alpha, \beta) = \mu + \gamma f(t) + \sum_{t_i < t} \alpha e^{-\beta(t - t_i)},~ t_i ~ \text{are the events}$$

Statsitics

• KS distance exponential - ecdf of re-scaled interarrivals X cdf of exponential distribution
• KS distance uniform - ecdf of re-scaled events X cdf of uniform distribution
• $L^2$ distance Laplace - empirical Laplace transform of re-scaled interarrivals X Laplace transform of exponential distribution

Goodness-of-fit tests

• Bootstrap-based
• Standard (explanation in the same link above)
• Subsampling (adaptated to only one trial available)

Immediate next steps

1. Implement the Standard Hawkes process
2. Implement the KS distance exponential statistic
3. Implement the Bootstrap-based goodnessof-fit test

Then, having all this well structured and working properly, it should be straightforward to add the other stuff.

Step 1

I will create a src/hawkes folder. For now, there will be no abstract type, just a concrete type Hawkes.

Step 2

The way I did it is to have an abstract Statistic type, with different singleton types KSExponential, KSUniform, LPExponential for the method statistic to dispatch on (can be seen here).

For the file structure. Create a abstract_statistic.jl file in src defining the AbstractStatistic type and a folder src/statistics with the concrete types and corresponding methods?

Step 3

Could use the same design as above, with a AbstractGoFTest type (or something like this) and concrete types Bootstrap, Standard, Subsampling. Maybe it makes more sense then having three different functions, like I did here

[jucheval]

Some remarks regarding the steps :
2/ Good idea. I would have expected that some standard statistics packages already have this kind of abstract type Statistic but I did not find any (for instance it does not appear in StatsAPI.jl).
3/ Here, I would say that your AbstractGoFTest type should be replaced by HypothesisTest from StatsAPI.jl.

[JoseKling]

Agreed.

I was just looking at StatsAPI, and there is also the type StatisticalModel, which might make sense to be a supertype of AbstractPointProcess?

[jucheval]

I was also wondering about this ‘StatisticalModel’ type. I think it is intended for more « standard » models. For instance I think that ‘Timeseries.jl’ does not use it.

[rsenne]

Hey Jose and Julien! Just wondering if there is anything I can start contributing? I could potentially start building out the inhomogeneous architecture, work on implementing some GOF as in the mentioned step 2, documentation etc.

[JoseKling]

Hello @rsenne,

what I was thinking right now is to have a more clear structure of the project. For example, while working on the Hawkes process in PR #59 this issue with Base.rand (#58) came up. I guess it would make sense to refactor this before moving on to other processes? Or include checks, type parameters and maybe some better interface for non-marked History (#57)?

I just submitted a draft PR with some GoF tests. You could also include the standard tests based on HypothesisTest, although I guess we should define some more or less common structure for the tests?

Well, these are my thoughts on it, but you can also suggest something else. And, of course, you can also participate in the discussions in the open PRs.

[JoseKling]

I was also wondering about this ‘StatisticalModel’ type. I think it is intended for more « standard » models. For instance I think that ‘Timeseries.jl’ does not use it.

But TimeSeries.jl does not define any kind of model, or does it?

Anyway, I guess you are right. But still, it probably makes sense to follow it, no? We already use fit, but could at least use params and loglikelihood. We might consider dof and aic.

[jucheval]

But TimeSeries.jl does not define any kind of model, or does it?
You are right, they do not.

I looked for packages that define subtypes of StatisticalModel and came across GLM.jl. It seems that their "models" encapsulates the observations, which sounds weird from our point of view, no ?
One such example is their LinearModel LmResp which in turn contains the observations...
Moreover, the "default" signature of (e.g.) aic, it is aic(model) which implicitly means that the observations are included in the model.

Hence I would say that it is relevant to overload some functions of StatsAPI.jl like the ones you listed but it may be confusing to define AbstractPointProcess as a subtype of StatisticalModel.