Chandan and Marek, Thanks for your inputs.
I agree with Chandan’s point that the objective is really to associate behavior with labels. Having said that, I think if CLA starts generating predictions based on previous anomalous values, it introduces a lot of complications. Anomaly may or may not have a pattern. when CLA take anomalies into account, it messes up the prediction. Will be very interested in your work. Please keep me posted Regards, Tom > > Message: 2 > Date: Thu, 25 Jun 2015 10:42:42 -0700 > From: Chandan Maruthi <[email protected]> > To: "NuPIC general mailing list." <[email protected]> > Subject: Re: Ignore anomalous inputs > Message-ID: > <CAL8ax8x3197a4zfaf9-m89UMraEbhOg8ziufA5ejEYFry5=v...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Tom, > > Good Question, > > An anomaly is something that is not expected. Anomalies lie at the edge of > known behavior\data and unknown\unseen behavior\data. Once an anomaly is > seen it does not stay an anomaly any more. So Anomalies by themselves are > not a tool to use, although thats how Nupic may have been thought of in > early days. > > What you need is association of behavior with labeled patterns, so when > such a behavior\pattern occurs you know what it is, and its assotiation > with labels that are positive or negative or associated with other events . > When you see the downward spikes, it may not result in an anomaly , but > results in an inference of known states. > > I am working on something around this area. > > > Chandan > > > > > > > On Wed, Jun 24, 2015 at 6:49 PM, Marek Otahal <[email protected]> wrote: > >> I think this one would help - supervised metric for anomaly detection: >> https://github.com/numenta/nupic/issues/1830 >> >> I might get to work on it soon, hopefully >> >> On Thu, Jun 25, 2015 at 2:08 AM, Marek Otahal <[email protected]> >> wrote: >> >>> Tom, >>> >>> I've seen similar when working with ECG signal. >>> >>> 1/ I think your HTM is too quick about picking up changes. I think it >>> learned to model/repeat just the last "beat" - that is actually a pretty >>> good strategy and works most of the time! >>> To unlearn this you can try: >>> -reducing #columns (thus giving the network less computational resources, >>> so it has to abstract more) >>> -modify params that effect learning speed (permanence inc/dec, >>> #cells/col, look back steps, ..what else??) >>> -change metric so it has a big penalty for the mistake and drives HTM to >>> unlearn the 1-beat pattern.. >>> >>> 2/ there's some information occurring before the drop and HTM exploited >>> it and is able to detect the "anomaly" faster then you! :) >>> >>> >>> On Thu, Jun 25, 2015 at 1:29 AM, Tom Tan <[email protected]> wrote: >>> >>>> >>>> Hi, >>>> >>>> I tried to use Nupic for anomaly detection over following data set. The >>>> blue line is actual and red line is Nupic prediction. The downward spikes, >>>> such as the one circled out, are anomalies in our case. >>>> >>>> Nupic seems to treat the anomaly as regular pattern and later predicts >>>> such downward spikes. It can be shown that the red spikes later follow the >>>> blue spike. However, downwards spikes are true anomalies and should not >>>> be accounted as norm. Is there a way to suppress such predictions? >>>> >>>> Regards, >>>> Tom >>>> >>>> >>>> >>>> >>>>
