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

MarkovChain: state_values #173

Open
oyamad opened this issue Sep 18, 2017 · 1 comment
Open

MarkovChain: state_values #173

oyamad opened this issue Sep 18, 2017 · 1 comment

Comments

@oyamad
Copy link
Member

oyamad commented Sep 18, 2017

  • Add a method to set state_values afterwards
    Once mc is created by mc = MarkovChain(p), then the state_values field has type UnitRange. Currently, it is not allowed to change it to, say, an Array of state values. (This is relevant in particular for DPSolveResult.mc.)

  • Allow state_values to be AbstractArray?
    When state values are 2-dimensional for example, the state space may be represented by a Matrix, but it is not accepted, because of TV<:AbstractVector where state_values::TV.

@sglyon
Copy link
Member

sglyon commented Oct 6, 2017

In response to the first point, I would prefer to have the MarkovChain type be immutable. Instead of changing the state values later on, I would encourage users to simply construct a new MarkovChain instance using the original transition matrix and supplying new state values.

I'd be open to allowing the state_values to be an AbstractArray, with the number of elements in the first dimension equaling the number of rows and columns of the transition matrix. We'd have to think carefully (and probably prototype) to make sure that things like simulation are still seamless/natural if we can't make the assumption of AbstractVector anymore. An alternative to using Matrix{T} you could use Vector{NTuple{N,T}} where N is the number of columns the Matrix would have. There are tradeoffs there too...

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

No branches or pull requests

2 participants