# TSAnalysis: time series analysis and state-space modelling
**URL:** https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672
**Category:** Package Announcements
**Tags:** statistics, time-series, machine-learning
**Created:** [November 4, 2019, 1:04am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672 "2019-11-04T01:04:45Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [January 2, 2020, 10:09pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/21 "2020-01-02T22:09:32Z")
On a related note, state space models serve to model time series, so the name TimeSeries.jl is more conclusive than any name involving state space. If an umbrella package is created for time series, it could contain models for time series that include state space models as well as other models that do not rely on state spaces.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [January 3, 2020, 3:03am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/22 "2020-01-03T03:03:37Z")
I agree 100% with the latest post of @juliohm . Unfortunately, there is a Git project of JuliaStats with this name. I am still out of town, but I suspect that the package might be registered. DependentData.jl could be an alternative. However, I am not sure whether it has a different meaning in other fields.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [January 3, 2020, 3:06am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/23 "2020-01-03T03:06:24Z")
I am not sure about the N4SID algorithm. However, Aoki worked on the same type of models I am implementing on TSAnalysis.jl. I am not sure whether I will code models that use the frequency domain in the near future (e.g., the Wiener - Kolmogorov filter).
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [January 3, 2020, 9:10am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/24 "2020-01-03T09:10:28Z")
DependentData.jl is too general name. I for example deal with dependent data that is not indexed by time but space in GeoStats.jl. Maybe everyone involved with time series research could contact the TimeSeries.jl package and collaborate there.
---
### Author:  [@markushhh](https://discourse.julialang.org/u/markushhh)
#### Post date: [January 3, 2020, 9:41pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/25 "2020-01-03T21:41:47Z")
This looks great! I’ve been working on a GARCH modeling package which I haven’t released yet because I itend to do some breaking changes which would be very confusing in the short run.
I’d love to contribute to a general `TimeSeries.jl` package but I don’t know if I have time for it in the near future. Publishing the package such that all the functions can be copy pasted (and maybe improved if necessary) could be a contribution though. I have hopefully a quite good documentation right now as well.
Moreover, Simon Broda and his `ARCHModeling.jl` package might contribute a lot to this.
`TimeSeries.jl` seems to me to be the perfect fit for a name. My package would only be `GARCH.jl`…
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [January 3, 2020, 11:20pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/26 "2020-01-03T23:20:40Z")
I’ve just checked the TimeSeries.jl package, and it has some nice abstractions already. The type has many features along the lines of GeoStats.jl types. I would just contribute models to that package instead of trying to create a new package for time series.
---
### Author:  [@BLI](https://discourse.julialang.org/u/BLI)
#### Post date: [January 3, 2020, 11:30pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/27 "2020-01-03T23:30:10Z")
I think MATLAB’s N4SID algorithm works as an extension of Aoki’s work, where you find models
x\_{t+1} = Ax\_t + Bu\_t + \Gamma w\_t \\ y\_t = Cx\_t + Du\_t + v\_t
where the algorithm finds (A,B,\Gamma,C,D) as well as the covariance of w\_t when the covariance of v\_t is assumed (?). Here, u\_t is a deterministic input, while w\_t and v\_t are stochastic. Aoki worked with systems without deterministic input u\_t – at least in his 1987 book.
There are a number of algorithms for finding such models – N4SID is just one of many. I seem to recall that `baggepinnen` was working on one such package in Julia.
Such realization methods with deterministic inputs are particularly interesting for control people. Aoki has an example in his 1987 book where he tries to predict the price (?) of calf meat, or something, based on data from some US meat producer (Chicago?). He visited my department when I was a student, and I recall asking him about the possibility to manipulate the price by changing some deterministic inputs.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [January 4, 2020, 2:29am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/28 "2020-01-04T02:29:33Z")
> [@juliohm](#):
>
> I’ve just checked the TimeSeries.jl package, and it has some nice abstractions already. The type has many features along the lines of GeoStats.jl types. I would just contribute models to that package instead of trying to create a new package for time series.
I think we have to agree to disagree on TimeSeries.jl.
Often, regular arrays are enough to estimate time series models and forecast. More complicated structures are nice for EDA, but are superfluous for what I generally do. This is one of the reason why I prefer to have something simpler like TSAnalysis.jl (other reasons are above and [here](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/10)).
> [@markushhh](#):
>
> This looks great! I’ve been working on a GARCH modeling package which I haven’t released yet because I itend to do some breaking changes which would be very confusing in the short run.
> I’d love to contribute to a general `TimeSeries.jl` package but I don’t know if I have time for it in the near future. Publishing the package such that all the functions can be copy pasted (and maybe improved if necessary) could be a contribution though. I have hopefully a quite good documentation right now as well.
> Moreover, Simon Broda and his `ARCHModeling.jl` package might contribute a lot to this.
> `TimeSeries.jl` seems to me to be the perfect fit for a name. My package would only be `GARCH.jl` …
It looks interesting. If you can try to follow a similar style of the ARIMA model in TSAnalysis.jl we could add it to the package. Of course, I perfectly understand if you prefer to keep it separate 🙂
> [@BLI](#):
>
> I think MATLAB’s N4SID algorithm works as an extension of Aoki’s work, where you find models
>
> xt+1=Axt+But+Γwtyt=Cxt+Dut+vt x\_{t+1} = Ax\_t + Bu\_t + \Gamma w\_t \ y\_t = Cx\_t + Du\_t + v\_t
>
> where the algorithm finds (A,B,Γ,C,D)(A,B,\Gamma,C,D) as well as the covariance of wtw\_t when the covariance of vtv\_t is assumed (?). Here, utu\_t is a deterministic input, while wtw\_t and vtv\_t are stochastic. Aoki worked with systems without deterministic input utu\_t – at least in his 1987 book.
It should be relatively easy to add exogenous predictors. I will add it to the to do list! 🙂
---
### Author:  [@BLI](https://discourse.julialang.org/u/BLI)
#### Post date: [January 4, 2020, 9:08am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/29 "2020-01-04T09:08:43Z")
Here is one link to discussion of subspace methods a la N4SID – it is not complete, though. [http://people.duke.edu/~hpgavin/SystemID/References/Qin-SubspaceID-2004.pdf](http://people.duke.edu/~hpgavin/SystemID/References/Qin-SubspaceID-2004.pdf)
… with an extension of the overview in this paper: [An overview of subspace identification - ScienceDirect](https://www.sciencedirect.com/science/article/pii/S009813540600158X?via%3Dihub)
---
### Author:  [@markushhh](https://discourse.julialang.org/u/markushhh)
#### Post date: [January 4, 2020, 11:17am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/30 "2020-01-04T11:17:10Z")
I’d rather adjust your code to my design. The arimasettings are not necessary, and there are other shortcomings due to the maturity of your package.
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [January 4, 2020, 12:06pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/31 "2020-01-04T12:06:09Z")
> [@fipelle](#):
>
> Often, regular arrays are enough to estimate time series models and forecast. More complicated structures are nice for EDA, but are superfluous for what I generally do. This is one of the reason why I prefer to have something simpler like TSAnalysis.jl (other reasons are above and [here](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/10)).
I think you are sub-estimating the power of abstraction in Julia. You can have a custom type like the one in TimeSeries.jl, which is just data indexed with times (metadata), behave like a generic Julia array. It is important to notice that this definition doesn’t constrain users, nor developers, it actually helps a lot. I did similar modeling in GeoStats.jl for spatial types where the indexing is more complicated and requires various domain types as opposed to points in the real line. They are quite convenient to use. More important than having models, is to have a nice abstraction over time series including (1) types (`TimeArray` already implemented in `TimeSeries.jl` that could be renamed to something more general like `TimeSeries`, unfortunately the name of the package would need to change) and (2) a set of verbs for the operations that can be performed with time series like `forecast(ts, newtimes)`, `interpolate(ts, newresolution)`, `simulate(ts, times)`.
In my opinion the work of the community here has to concentrate on item (2). Defining a set of verbs (a.k.a. API) for time series that encompasses all things you can possibly do with time series. After these verbs are defined, then you can start mapping the models out there to a common package, possibly migrating them to a `TimeSeriesModels.jl` package, that would be re-exported by `TimeSeries.jl`. That is how I would do it.
If you want to get some inspiration, check the GeoStats.jl stack, particularly the GeoStatsBase.jl package that contains the abstractions I mentioned.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [January 5, 2020, 4:00am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/32 "2020-01-05T04:00:21Z")
> [@juliohm](#):
>
> They are quite convenient to use.
I think this is where our opinion differs. Having a metadata that keeps track of the data ordering or release dates (e.g., a Date vector) is not necessary to perform most operations. There might be cases where this is adavantageous or necessary. However, within my domain, they are relatively few and they can be easily handled by passing an extra argument to a few functions.
Furthermore, the common ground for most packages is the use of Arrays. In my view, non-experienced Julia developers would find easier to interface multiple packages if the data is all in the same format.
> [@juliohm](#):
>
> More important than having models, is to have a nice abstraction over time series including […] and (2) a set of verbs for the operations that can be performed with time series like `forecast(ts, newtimes)` , `interpolate(ts, newresolution)` , `simulate(ts, times)` .
Point 2 is partially implemented in TSAnalysis.jl. In about two weeks, I will open a new dev branch for the VARIMA models. I am re-using the same structure as for the ARIMAs (which will be a special case of the VARIMAs), including the `forecast` function. `simulate` will follow.
---
### Author:  [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)
#### Post date: [January 5, 2020, 8:01am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/33 "2020-01-05T08:01:19Z")
I implemented some generic methods for Estimation of linear statespace models in [GitHub - baggepinnen/ControlSystemIdentification.jl: System Identification toolbox for LTI systems, compatible with ControlSystems.jl](https://github.com/baggepinnen/ControlSystemIdentification.jl)
I’m not making use of subspace methods like n4sid though.
Edit: `n4sid` is implemented now.
---
### Author:  [@juliohm](https://discourse.julialang.org/u/juliohm)
#### Post date: [January 5, 2020, 10:32am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/34 "2020-01-05T10:32:16Z")
> [@fipelle](#):
>
> I think this is where our opinion differs. Having a metadata that keeps track of the data ordering or release dates (e.g., a Date vector) is not necessary to perform most operations. There might be cases where this is adavantageous or necessary. However, within my domain, they are relatively few and they can be easily handled by passing an extra argument to a few functions.
I think that is precisely where you are underusing the type system. You don’t need to know that there is metadata hanging around, and you should be able to treat a time series type exactly as a default Julia array after you implement the interfaces: [Interfaces · The Julia Language](https://docs.julialang.org/en/v1/manual/interfaces)
> [@fipelle](#):
>
> Furthermore, the common ground for most packages is the use of Arrays. In my view, non-experienced Julia developers would find easier to interface multiple packages if the data is all in the same format.
This is not true. Most packages create their own types to leverage multiple-dispatch in non-trivial ways. Furthermore, when it is appropriate, these same types implement the interfaces above and users won’t be able to tell that they are not Julia arrays unless they print the type on the screen.
> [@fipelle](#):
>
> Point 2 is partially implemented in TSAnalysis.jl. In about two weeks, I will open a new dev branch for the VARIMA models.
Can you point out which verbs are implemented? What is your vision for what can be possibly done with time series data? If that vision is not clearly externalized and made explicit with an interface, people won’t have clarity about where things should go in terms of research and development.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [January 5, 2020, 2:30pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/35 "2020-01-05T14:30:16Z")
> [@baggepinnen](#):
>
> I implemented some generic methods for Estimation of linear statespace models in [https://github.com/baggepinnen/ControlSystemIdentification.jl](https://github.com/baggepinnen/ControlSystemIdentification.jl)
> I’m not making use of subspace methods like n4sid though.
I will definitely take a look. I think that it would be interesting to benchmark ControlSystemIdentification.jl as well with [guilhermebodin](https://discourse.julialang.org/u/guilhermebodin)’s StateSpaceModels.jl and TSAnalysis.jl. I am not suggesting we should merge them, but it would be interesting to understand what is the most efficient way to implement these methods - at least, at their simplest form.
> [@juliohm](#):
>
> Can you point out which verbs are implemented? What is your vision for what can be possibly done with time series data? If that vision is not clearly externalized and made explicit with an interface, people won’t have clarity about where things should go in terms of research and development.
I will release more details with the new version - soon 🙂
---
### Author:  [@mthelm85](https://discourse.julialang.org/u/mthelm85)
#### Post date: [January 22, 2020, 1:06am UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/36 "2020-01-22T01:06:29Z")
> ¹ TimeSeries.jl is a very nice name, but I fear that there might be already a git project with this name. I will check the register when I come back from the break. I thought about TimeSeriesAnalysis.jl when I started the project, but it sounded a bit too long for my taste. I am open to suggestions though 🙂
I, too, vote for TimeSeriesAnalysis.jl 🙂
---
### Author:  [@h.smith](https://discourse.julialang.org/u/h.smith)
#### Post date: [January 24, 2020, 2:04pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/37 "2020-01-24T14:04:47Z")
I don’t think that TimeSeriesAnalysis.jl is all that long - it is very clear as to what it ia aimed at, it seems to me.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [February 14, 2020, 8:36pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/38 "2020-02-14T20:36:19Z")
A small update. I released a [separate package](https://github.com/fipelle/ElasticNetVAR.jl) for penalised vector autoregressions compatible with incomplete data. This is a replication code for the empirical application of a new paper of mine (linked in the Git page). This new package is not registered and it probably never will. Over time, I will merge some of the new features in `TSAnalysis.jl`.
I will soon start again updating `TSAnalysis.jl`. I plan to rename it either at the next update or at the following one.
---
### Author:  [@BLI](https://discourse.julialang.org/u/BLI)
#### Post date: [February 14, 2020, 9:35pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/39 "2020-02-14T21:35:45Z")
Did you decide on a name for the package?
In electrical engineering (and probably other fields), a distinction is made between signals and systems, where a system essentially is a transformation between two sets of signals.
“Time Series” sounds like the focus is on signals. In systems theory and control engineering, the focus is more on systems, hence “Systems Identification” and similar phrases are more common.
Even when there is only one signal/an input signal, one might think of the signal as generated from some stochastic signal which is unknown. Thus, control engineers tend to even consider a time series (a signal) to be a system.
In any way, the choice of package name probably reflects the field of the developer/the history of her/his field.
---
### Author:  [@fipelle](https://discourse.julialang.org/u/fipelle)
#### Post date: [February 15, 2020, 4:31pm UTC](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672/40 "2020-02-15T16:31:31Z")
> [@BLI](#):
>
> In any way, the choice of package name probably reflects the field of the developer/the history of her/his field.
I am undecided between a few names, including TimeSeriesAnalysis. I suppose I will choose on the spot and on the basis of the development plan. Maybe it would be wise to limit a bit the scope of the project to an area of time series, rather than having a package for all possible models.
However, I would really like to have “time series” in the name, as an indication of my field.
[Previous page](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672.md?page=1)
[Next page](https://discourse.julialang.org/t/tsanalysis-time-series-analysis-and-state-space-modelling/30672.md?page=3)