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

Fix and simplify Chronology #83

Open
6 tasks
patnr opened this issue Sep 14, 2021 · 0 comments
Open
6 tasks

Fix and simplify Chronology #83

patnr opened this issue Sep 14, 2021 · 0 comments
Assignees

Comments

@patnr
Copy link
Collaborator

patnr commented Sep 14, 2021

Contrary to the original ambition, the Chronology is among the ugliest elements of DAPPER.

  • The ticker should be oriented around obs-analysis-cycles. The intermediate forecast times should be provided by a sub-loop/ticker.
  • HMM.Dyn and HMM.Obs (operators) should take k (or ko) as parameter, not t.
  • Should change the meaning of K (and Ko) from "last index" (which we get with -1 anyway) to "length of array". Fixes the current heavy use of K+1 and Ko+1. This issue is a hangover from when I started I was used to Matlab/Fortran (1-based indexing).
  • Should have observation time 0 ? This would be nice coz then len(tto) == len(tt) when dko = 1. But the 0th cycle would then have two obs-times instead of one...
  • BurnIn complicates everything. Simplify? Provide automatic averaging for custom-length time series?
  • Last I checked I could change the dko of a Chronology without it raising an exception nor having the desired effect. BUG!
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

1 participant