You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
Contrary to the original ambition, the
Chronology
is among the ugliest elements of DAPPER.HMM.Dyn
andHMM.Obs
(operators) should takek
(orko
) as parameter, nott
.K
(andKo
) from "last index" (which we get with-1
anyway) to "length of array". Fixes the current heavy use ofK+1
andKo+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...dko
of aChronology
without it raising an exception nor having the desired effect. BUG!The text was updated successfully, but these errors were encountered: