Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting rid of the LinearStateSpace argument in Kalman #354

Open
natashawatkins opened this issue Oct 20, 2017 · 8 comments
Open

Getting rid of the LinearStateSpace argument in Kalman #354

natashawatkins opened this issue Oct 20, 2017 · 8 comments
Assignees

Comments

@natashawatkins
Copy link
Member

natashawatkins commented Oct 20, 2017

Wouldn't it be easier to just have the arguments that a LinearStateSpace object takes available when creating a Kalman object? It's somewhat cumbersome to first create the LSS object and then put that into Kalman (you also need to import two classes).

We could just create a LSS object using the arguments in Kalman.

@jstac

@natashawatkins natashawatkins assigned jstac and unassigned jstac Oct 20, 2017
@jstac
Copy link
Contributor

jstac commented Oct 22, 2017

Yeah, fair point. I had a look at the code and the Kalman class never actually uses any of the functionality of the LinearStateSpace class internally. So from a coding perspective there's no advantage linking them.

Plus, as you say, if we do need such functionality down the road we can always build an instance of LSS inside the class.

Could you please put together a PR that closes this issue? We'll also need to coordinate on changing the lecture. Although that shouldn't happen until the next release of the library. (CC @mmcky )

@mmcky
Copy link
Contributor

mmcky commented Oct 22, 2017

Thanks @jstac and @natashawatkins.
I was thinking of putting a release together but I will do so after this is resolved.

@cc7768
Copy link
Member

cc7768 commented Oct 23, 2017

I also think this is a reasonable thing to do.

If you wanted to make sure you going from LSS to Kalman was low cost then one natural thing to do would be to add a method to LSS that created a Kalman object.

@thomassargent30
Copy link
Contributor

thomassargent30 commented Oct 23, 2017 via email

@jstac
Copy link
Contributor

jstac commented Oct 23, 2017

Hi @thomassargent30, I think @natashawatkins has a good point here: To build an instance of Kalman you need to know about LinearStateSpace. This makes sense on a mathematical level but forms a barrier to entry when coding, since users need to look up the documentation for two classes.

If in the future we need to use the functionality of LinearStateSpace inside Kalman, we can build an instance of LinearStateSpace inside Kalman, rather than outside.

So on balance I support the change proposed by @natashawatkins.

@thomassargent30
Copy link
Contributor

thomassargent30 commented Oct 24, 2017 via email

@mmcky
Copy link
Contributor

mmcky commented Oct 24, 2017

We might be able to use a decorator to keep backward compatibility. If an LSS object is passed we could then unwrap the object and pass in the data (from LSS). Working out the interface will need some thought. @natashawatkins would you intend for A, C, G, H=None, mu_0=None, Sigma_0=None to be passed into Kalman instead?

@jstac
Copy link
Contributor

jstac commented Oct 24, 2017

@mmcky Thanks, great suggestion.

@thomassargent30 This is a neat suggestion that will allow us to initialize the class with either the A, B, C matrices (for ease of use) or a corresponding LinearStateSpace instance (to exploit the fact that Kalman filters build on linear state space models). With such an approach there will be no negative equilibrium effects for notebooks in the pipeline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants