I’m confused about picking the best parameters for the columnCount (both temporal and spatial) and cellsPerColumn (in the model_parameters.py).
I know Numenta has commercial products, and there is also NAB…does that use the default parameters; i.e., 2048 columnCount, and 32 CellsPerColumn?
After doing some anomaly prediction on EKG, I found that having 128 columnCount and 12 CellsPerColumn is a good. With the original parameters, the model was too sensitive and it would spike unnecessarily high – even on data from a healthy patient… I’ve used HTM Studio on this data, it seems to be even less sensitive then my 128ColumnCount-12CellsPerColumn setup, which makes me think that it could be using even smaller parameters.
I suspect that the high sensitivity of the model might be related to resolution of the encoder. If the resolution of the encoder is too high, each data record will be treated as a distinct input. Could you describe parameters for the encoder or the spatial pooler?
I’m just using a Scalar Encoder. The parameters were determined by swarming (I ran a large swarm over the first 1000 values). By the way, I tried various n and w values but it was still giving me a noisy anomaly pattern, that’s why I turned to using different ColumnCount and CellsPerColumn values.
I am not sure what n/w combinations you have tried. I would suggest to try decreasing the encoder resolution (increasing w and/or decreasing n). The reason anomaly scores are noisy is usually because the model hasn’t fully learned the data yet. The higher the resolution, the longer it may take to fully learn the sequence. Decreasing the column count could also give you lower resolution, but that is not the right way to do it as the resulting model no longer use sparse representations.
I ran my data and there wasn’t much difference between running the large swarm on 1k values or 20k values. The original from the medium swarm on 1k values actually had less noise than the original from the large swarm over 20k values. Although the large swarm and medium swarm on the same n and w values proved to be different (the large swarm had less noise with n=235, w=81). However, comparing the large swarm that was run over 1k values and 20k values wasn’t that much different. Besides, Matt keeps telling me that swarming is not even needed for anomaly detection over scalar values…so I’m not sure what you mean by saying that the model hasn’t fully learned the data yet. How would I make it fully learn it? Do you think I should be using bigger data?
I think I was trying out the wrong combinations, but what you suggested seemed to work.
So my next question is, is there a way to somehow generalize this? For example, by changing the columnCount and CellsPerColumn (to the specific number I mentioned above) I was able to get this kind of stable input every time I ran it, but is there a way to make the computer do it? And one that is being used right now…Does Grok use this sort of system?
By the way, does what kind of parameters does Grok use? I’m sure there must be a system for filtering out this noise or setting the correct values.
I wasn’t referring to the swarming process here. HTM learns in a continuous streaming scenario. Each data record is processed sequentially. Therefore the algorithm generally has better performance on the later part of the data than the beginning of the data. There are a few things you could try besides using longer data streams. The time it takes for HTM to learn a temporal pattern is proportional to the length of the pattern. You could try smooth or aggregate your data to speed up learning.
It’s good to hear that the suggestion works. We usually don’t tune the columnCount and CellsPerColumn at all. I believe we used 2048 columns and 32 cells per column in Grok and in NAB. We tune the encoder resolution instead. This can be done through swarming. @rhyolight Is this correct?
Is that really so bad? I mean, will I get wrong results? I’m only applying this to anomaly detection.
It’s just that that swarming never gives me the output that I want…As you can see from the first post, the values from the swarming always give me huge anomaly spikes. By the way, Grok and HTM Studio doesn’t just give you huge anomalies everywhere…it only gives you an anomaly when it’s clear. So is it filtering the anomalies it got or what is it doing?
I’m a bit confused. So I’m supposed to instead somehow constrain the swarm? Right now I’m only using one input…so I should add another one?
There’s no filter, but both of those apps are using “anomaly likelihoods” not just raw anomaly scores.
No, no… that conversation was called about how to use a lower level swarming interface that allows users to choose the exact parameters they would like the swarm to evaluate. I was hinting that you could use that interface to include the columnCount and cellsPerColumn in the swarming.
I’ve tried using data with hundreds of thousands of data points and it seems to work nice, I think…Just takes a really long time to run.
There’s something I don’t understand. I tried running the same data but I deleted most of latter points. For some reason they look different even though they’re both using same parameters and they’re both describing the same data…I even swarmed them over the same first 2000 points, but maybe the swarm came out with different n and w values, I don’t remember.
Take a look:
I didn’t really see anything in permutations.py that could help me (am I supposed to add something there?) but I tried modifying description.py but it didn’t seem to do anything for me. I think when I do swarming again, it over wrote what I did, or it just didn’t use it.
So I’m still puzzled why the same data gave me different results…
I ran the same data but one of the files had longer records than the other. Although I then compare them over the same points (the first 20k), but for some reason they look different.
