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
I have a different (competing) design for this. The TM class should keep an exponential moving average (EMA) of the anomaly, as well as an EMA of the variance (aka standard deviation squared) of the anomaly.
This would introduce a new parameter to the TM for the window size / time-scale of the EMA.
I have a different (competing) design for this. The TM class should keep an exponential moving average (EMA) of the anomaly, as well as an EMA of the variance (aka standard deviation squared) of the anomaly.
I won't be against if it's just a few lines of code, but I'm not a huge fan of cramming more (unrelated) code to TM. TM's job is to make predictions for T+1. Even that we added TM.anomaly was compromising its logical integrity for convenience.
the advantage of your (2 EMAs) solution would be much simpler implementation 👍
disadvantage: peer-review: We'll probably still need AnomalyLikelihood for comparisons with Numenta's benchmarks.
I'd prefer suggested solution with a virtual float TM::getAnomalyScore() which you could override with the new implementation without needing to add new code to TM.
(but these comments are probably for a PR/issue with your suggested design)
as our cpp Likelihood is likely broken and untested, #124
py/
where pure python code resides.This will be used for running NAB #205
The text was updated successfully, but these errors were encountered: