Kalman.jl
Kalman.jl copied to clipboard
Roadmap to Package registering
Contributions, comments and feature requests are most welcome.
I will settle for an interface which combines an Observation model and a Evolution model with a Filter method, so e.g.
"""
LinearObservation(H, R)
Observe `y = Hx + v` where ``v ~ N(0, R)``
"""
struct LinearObservation{TH, TR} <: AbstractObservation
H::TH # dxd
R::TR # d
end
can be combined with
struct JosephForm <: FilterMethod
end
The new interface is mostly implemented, I'll do a pull request which relocates the old "LinearHomogSystem" in a less prominent place.
Any comments?
@cstjean @yakir12 Anybody using this? I am going to change things now to publish the package.
We're not using it anymore.
Any change you dim fit and better is welcomed. I\ll try and adapt after you.
Do you know yet when you are going to update to 0.7./1.0 and register the package?
Nice to see interest. I just figured out how I want to organise this. The plan is to get https://github.com/mschauer/DynamicIterators.jl working and I am doing this right now. Then I use DynamicIterators in Kalman as engine and will get something nice.
@BenjaminBorn What is your use case to keep that in mind?
Thanks for asking. The use case is likelihood based estimation of a state-space model with potentially large-ish state space. Think of a type of Metropolis Hastings.
Some progress. Next steps:
- [x] Register DynamicIterators 0.2
- [ ] Test backward sampling
- [x] Add some more documentation
- [x] Register Kalman 0.1
@mschauer I played around with the implementation so far and I have a question of how to efficiently use it for my application.
The objective is to estimate some of the parameters of the state space model, i.e. some entries in Φ
, Q
, H
, and R
, using a likelihood based approach. That means that the Kalman Filter is sitting in a loop and will be called possibly a million times. In each iteration some of the parameters in Φ
, Q
, H
, and R
are changed and the Kalman Filter is used to compute a new log likelihood. Will that be efficient in your implementation? Most importantly, do I need to reinitialise the state-space model with the new parameters or can I somehow update it in place?
Can you give me a test system and data of the size you are thinking about? Some matrices
Φ, Q, H, and R
and a vector Y
which might be realistic in your setting?
I went ahead and registered the package. There are still things to do but from my side with changes of more incremental nature.
https://github.com/mschauer/Trajectories.jl/issues/10#issuecomment-596079868
@JuliaRegistrator register
Registration pull request created: JuliaRegistries/General/10668
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.2 -m "<description of version>" d570688394b39fa126fa8420a27dd363b8c5dee4
git push origin v0.1.2
@JuliaRegistrator register
Registration pull request created: JuliaRegistries/General/12784
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.3 -m "<description of version>" ff81474832ad6841991b3f6943e1d822e98ea72c
git push origin v0.1.3
@JuliaRegistrator register
Registration pull request created: JuliaRegistries/General/17019
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.4 -m "<description of version>" bac495f90aa95412c421ba39e07fa312ebdb6365
git push origin v0.1.4