Looks like we forgot to put that in. We used to have it in our old internal version, but we neglected to put it back in for the current release. We’ll put it back in as soon as we can.
A hack-ish workaround would be to add a reset code, kind of like a newline or EOF character. This would indicate the end and start of a new signal and would nicely break up your sequences and prevent them from stitching together.
This encoding has to be completely different and has no overlap with all other inputs you would receive. That should get you moving forward until we put in the fix. Actually, it would help if you put this in as an issue on our github page.
I wouldn’t use time as an input unless your waveforms are consistently occurring at the same times. Otherwise, use the PersistenceEncoder.
I’m looking to test out BrainBlocks on my 16 channel EEG data as @marty1885 suggested on HTM on EEG data. Firstly on the raw signal, then on the high dimensional cross channel features.
I’m kinda bad at reading pure C code. And I need more time to understand the details. As far as I see, it seems not too hard to add TBB support. Adding OpenCL support will likely need a huge rewrite. Also I think it is possible for BrainBlocks to share Etaler’s backend given we both have some rewrite. If that’s something you want. I’m working on improving the backend design currently. Maybe we could discuss this over PM or mail?
I’d like to see some unit tests for BrainBlocks. The current test only prints value so I have no idea if they are working correctly on my machine. See Etaler’s tests.
Also is there a design reason behind using C’s rand function? It is a bad random function even though it’s fast-ish. All values it produces fall on a 4D plane. It might cause weird edge cases and cause learning to fail.
The python versions of the tests use pytest and will flag errors if they exist. We didn’t have any experience with writing unit tests in C/C++ so we don’t have a framework for them.
I have been playing with BrainBlocks (v0.7) and am enjoying its differences and relative simplicity vis à vis nupic to help clarify my thinking around HTM. I do have a couple of questions, though, and I hope this is the right place to ask them. If you would prefer I ask as issues on the github repository, I am happy to do so. Also, it has been a while since the last post in this thread and BrainBlocks has released a new version (0.7), so I apoligise if this should be a new thread (admins, feel free to move it).
Question 1: differences between ContextLearner and SequenceLearner
From my understanding of Nupic, a context learner (temporal memory used in object detection) is just a generic case of a sequence learner (temporal memory used in sequence/anomaly detection). Or, rather, the sequence learner is a specific case of the context learner where the context input is the learner’s output from the previous timestep. This plays out in the similarity between the context_learner.cpp and sequence_learner.cpp source. As expected the init functions differ, with the latter adding the output at t - 1 as a child to the context’s input. But there is also a difference in the surprise method. the sequence learner includes the following code which is absent in the context learner:
// For each statelet on the active column
for (uint32_t s = s_beg; s <= s_end; s++) {
// Check if it is a historical statelet
// - statelet is not the random statelet
// - statelet has at least 1 dendrite
//if(s != s_rand ) {
if(s != s_rand && next_sd[s] > 0) {
// Activate historical statelet
output.state.set_bit(s);
// Activate historical statelet's next available dendrite
set_next_available_dendrite(s);
}
}
If there a reason why the sequence learner requires this additional activation but the context learner does not?
Question 2: nupic punishes incorrect predictions, brain blocks does not. why is it not needed?
Both libraries reinforce the active connections based on the active output of the learner. The nupic implementation goes a step further punishes matching synapses on the context inputs that led to an incorrect predicted (depolarised) cell. The BrainBlocks code does not punish these. Was there a reason to skip this punishment?
Thanks for checking out our code. Your questions are very astute!
You are correct that the ContextLearner is the more general form. The SequenceLearner is a special case of the ContextLearner, where the distal context comes from the t-1 statelet activations.
As for the extra activation code, this is a trick we learned to make a more efficient use of statelets in the SequenceLearner for time-series data. We may add this same code to the ContextLearner as well, since I see no reason why it can’t be used.
Basically it does this: whenever there is a “surprise” activation of a minicolumn, we do not activate all of the statelets on this minicolumn. Instead, we activate all of the statelets that have been active before in the past to make connections to all previous context states, and we activate a single random new statelet that acts as a new hypothesized context state. This makes an efficient use of statelets as a resource, and only uses them up as they are needed. The previous approach for a minicolumn “bursting” is to activate all neurons on the minicolumn to hypothesize all possible context states. This makes learning much slower. This new efficient approach makes sequence learning super fast.
Again, another good question and with an interesting answer. By default, we do not punish incorrect predictions, but will give the option to do both. So what’s the difference? I suppose it depends on your intended application.
If you want to make predictions of the t+1 state, punishment should be used because you are trying to find the best answer for the next step. You want to punish poor predictions and reward good ones. However, if you are trying to do anomaly detection, punishing poor predictions isn’t nearly as important. Without punishment, the next step prediction represents the entire space of possible next states that have been seen in the past. So this gives you a large envelope of possible trajectories that have been seen in the past which you can use as your “normal” behavior. Any next steps that deviate from all these possible trajectories represents your “abnormal” behavior and makes a really good anomaly detection approach.
Thanks for checking out BrainBlocks and your comments! Looking forward to hear more from you.
@Mark_Springer We’ve mostly worked on time-series anomaly detection and standard classification tasks.
I think we’re quite competitive with other approaches on abnormality detection results. Our classification results for feature vectors are “on par” with other approaches, but we haven’t extended it to image classification yet. You can see a side-by-side comparison here.
You can see a big difference from the other approaches is that it only expresses an opinion on the area of the learned experience. BrainBlocks will give a solid “I-don’t-know” answer when encountering novel inputs. This gives you a simultaneous classification and outlier detection capability.
It took us a while to figure out what the distinguishing features of BrainBlocks actually are and why you would use it for an application. They are the following:
few training inputs required: will often learn in one-shot
robust to novel inputs: flags a novel input as an outlier and can find a semantically similar learned input if it exists
explainable results: internal representation and output can be communicated to the user with a trained translator network. This is similar HTM’s time-series prediction but more generalized for an arbitrary language
The first two are “baked-in” with BrainBlocks. The 3rd requires some effort and isn’t something we’ve released yet.
Other than that, we use BrainBlocks to create experimental cognitive architectures that do things like sensorimotor learning and object recognition, similar to the HTM experiments. Does that answer your question?
