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+1and 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!
Contrary to the original ambition, the
Chronologyis among the ugliest elements of DAPPER.HMM.DynandHMM.Obs(operators) should takek(orko) as parameter, nott.K(andKo) from "last index" (which we get with-1anyway) to "length of array". Fixes the current heavy use ofK+1andKo+1. This issue is a hangover from when I started I was used to Matlab/Fortran (1-based indexing).0? This would be nice coz thenlen(tto) == len(tt)whendko = 1. But the 0th cycle would then have two obs-times instead of one...dkoof aChronologywithout it raising an exception nor having the desired effect. BUG!