I’d totally read it! I think it’d be awesome if there were visualization modules easily plugged in to, to see that one’s own system was working like the real thing as in HTM school. I know that must depend on a lot like what language you’re writing it in, etc. I think it could be a great way for people to learn about HTM and demonstrate their learning at the same time.
I’m in the early experimental stages of writing encoders using numpy, taking sensor data from a collection of sensors with a few output devices as well (intent is to allow system to notice results of its own interaction).
My language of choice, due to experimental speed, is Python3; initial barriers were getting a firm understanding of the bitwise functions, which I hadn’t previously used.
I’m experimenting to see which runs more speedily and practically, using numpy arrays, or straight bitwise operations on ctype binary strings.
I’m a little shy and self conscious to share my fugly code, and wasn’t aware of that other thread either.
I may make a more concerted effort to clean some stuff up and upload to github. Sensor code is running on and written for arduino, with the python communicating through serial to get the incoming data for conversion to SDRs.
I’ll also try to provide some of my diagrams for the flow and components of my processing for what I have, and what I intend.
My end goal is to have all my work open source anyway. The Deep Learning community seems to have benefited most from the open sharing of ideas and architecture designs, and the more we could build that up for HTM, the better.
I’d be curious to hear what sort of data types your sensors are picking up. Are they kinds that don’t already have suitable nupic encoders? And in terms of fugly code I can only speak for me but don’t be shy!..As long as its well commented lol.
Currently debating whether to optimize, modify and work on modifiable implementations of neocortical structure as elaborated in HTM or to build direct implementations of HTM’s core learning algorithms (both implementations considerably completed). For instance, whether to build an implementation with individual SP minicolumn neurons(just define modifiable neurons) or just abstract minicolumns with connections to input space.
The decision will obviously affect the weight and speed of the implementation tremendously. The main reason or choosing the the former paradigm is the ability to try new theoretical approaches and to better visualize cortical tissue. Also, lots of algorithmic implementations out there.
light sensor (analog photo-electric diode)
MPU-6050 (GY-521 MPU-6050 6-axis Accelerometer Gyroscope Sensor Module 16 Bit AD Converter Data Output I2C)
BMP180 ( Barometric Pressure, Temperature and Altitude Sensor )
DHT22 ( Temperature and humidity sensor, higher accuracy than the cheaper DHT11 and possibly above chip)
ELP Stereo camera:
- encoding the rectified, normalized disparity map for depth info
- blurring most of the edge of the images, except for the center core (similar to human eyes), for both right/left camera
Microphone (analog signal)
speaker (with a simple DAC attached … might be overkill and not amount to anything, but might be interesting as well).
I haven’t really dug into whether or not NuPIC has encoders already… I probably won’t for a while anyway. The reason for this, is that when I first got into deep learning, one the first series of exercises was coding neural networks from scratch, using minimal libraries, so that I was forced to understand on the lowest level what each algorithm was doing, how data was being handled, weight distributions were being updated, etc.
I’m looking to do something similar here with HTM, maybe create a jupyter notebook tutorial along the way. I’m also going with the long-term intent of using some of the newer embedded SoCs (such as the STM32 line of chips with 512KB+ memory and 128-256Mhz processors) to do initial sensor SDR encoding and compression, with a more empowered board simply concatenating then processing on that. I might be wrong, but I have some doubts that NuPIC is aiming code at embedded modules, whereas embedded chips are specifically an interest of mine. Also considering using FPGAs as well… those are coming down in price.
I get the general sense that overall processor speed isn’t as important here as having adequate parallel processing and IO. Those aspects are negatively impacting scaling of HTM. One of my assumptions for this is the fact that our eyes are able to believe that relatively slow refresh rates on a television or monitor as really moving objects. This states that even our brain has a certain speed limit in its IO processing, so that it’s the parallel nature as well as low-level prediction/anticipation of input that really empowers us. Pre-processing all that parallel work before sending it to the main computer, I suspect, would go a long way to helping this overall system.
I also want to try to carry over some tricks used by deep learning for efficiency as well (such as storing known pre-computed values and using hashing to route common input combinations into that lookup table/hashmap/dictionary).
Finally, I want to try to keep the maths as simple as possible, both for the sake of computational understanding for newcomers, and reducing number of clock cycles required to compute all this. Only after getting to an efficient place in python, would I bother to implement in C++… might even be worth writing a converter or trying Cython at that point, but that’s down the road.
(I worked with distributed parallel compute systems at a previous job, so I feel familiar with some of the methodologies involved, and think it would be a fun challenge to try this using IoT devices)
I’m thinking along the same lines.
There is a walk-through jupyter notebook that you could look at for starters, it goes through the main components of nupic including several encoders, spatial pooling, temporal memory, model parameters and anomaly scores.
Here’s a link to info on the encoders, including ones that handle scalars, date/times, spatial locations and categories (and variations thereof).
It sounds like at least some of the inputs you mentioned would fit into these categories, I’d imagine the Accelerometers, Barometric pressure, Temp, Altitude and Humidity are essentially scalars, though I don’t think there’s anything in place for audio, camera feed or light. Here are two HTM school videos on encoders as well. I’d check these out to get a clear intuition for what encoders really do. With this understanding its possible to design your own custom encoder for these data types that nupic hasn’t handled yet - something many of us would be very interested to see!
I appreciate that. I’ve watched those videos a few times as well.
Main point is that I’m a slight masochist, and want to get a real feeling for designing the implementation from scratch, to get my hands in the raw dirt, and have a greater understanding from there. I might be re-inventing a wheel, but along the way, I’m getting a better idea on the platonic form of the ‘wheel’ (thinking of Plato’s Cave)… without that, it’s harder to innovate I think.
I spent some time last summer painstaking studying Matt’s video’s and implementing the HTM model in Swift. I read whatever I could find online to support that effort. I spent time optimizing the implementation because I really enjoy the Swift language. I was able to create an interesting visualization of an htm learning user selectable patterns.
It’s not posted on github, but you may contact me privately if you are interested in what I have come up with.
While Matt’s video’s were instrumental, an accompanying guide would have been useful.
I built an HTM model (spatial pooler + sequential memory) in Matlab.
This is an implementation of Numenta’s Hierachical Temporal Machines (HTM) and its testing on the Numenta Anomaly Dataset (NAB). It implements both the spatial pooler (SP) and the sequence memory (SM or temporal memory) modules.
For the encoders and the spatial pooler, I used the pseudocode and description BAMI, http://numenta.com/biological-and-machine-intelligence/
For the temporal memory, I used the description in the paper, “Why Neurons Have Thousands of Synapses, a Theory of Sequence Memory in Neocortex,”
to guide the implementation. The paper describes the guts of the algorithm, but there are several details that need to be nailed down in an implementation, which are not in the paper. I followed the implementation that is sketched out at
I also relied on the information on the slides in
Note the implementation is NOT faithful to the NUPIC implementation. I did not implement the PAM mode or the backtrack mode.
For the anomaly detection and scoring parts, I relied on descriptions in the paper “Real-Time Anomaly Detection for Streaming Analytics,”
I was not able to fully replicate the NUMENTA likelihood algorithm, but was close enough.
I also implemented a bootstraped estimate of the variance of the final scores, so that we can mark differences as being statistically different or not.
Performance achieved with this code, with estimates bounded by plus and minus one standard deviation.
Our Raw Scores + Our Anomaly Likelihood: 60.193 (Bootstrap estimate: 60.165 ± 3.677)
NUPIC Scores + NAB Anomaly Likelihood: 60.979 (Bootstrap estimate: 60.576 ± 3.555)
NUPIC Raw Scores + Our Anomaly Likelihood: 56.171 (Bootstrap estimate: 56.270 ± 3.931)
Random: 7.952 (average over > 100 runs)
I’m not sure if this classifies as a HTM system, but I’ve been working on an SDR library.
There are some jupyter notebooks in there exploring some ideas using SDRs. I found the SDR and SDRMap classes pretty flexible. With a bit more work on the SDRClassifier it could perform spatial pooling. At some point in the future I want to demonstrate first-order temporal memory and variable order temporal memory using the SDR & SDRMap primitives. There is no concept of columns, segments, hebbian learning, etc. It all boils down to SDRs, their operations, and the mapping between SDRs.
All the code was written based on what I’ve learned from Numenta, Cortical.io, T.Kohonen and E.Rolls - each of which describe SDRs from different perspectives.
Some notebooks will have non-sparse representations. This is simply for demonstration as the indices are easier to reason about when they are denser.
Not terribly pretty, and definately a work in progress, but here’s what I have going so far (have so far ignored bitwise operations in favor of imperative iterations instead).
It’s more an SDR system than a HTM system now, and still in progress, but I’ve managed to get something that might work as a video encoder by mimicking the V1.
tests_interactive under pygp_v1 will show the corners of the image, colors representing orientation. It’s effectively turned the image into pose cells. (x,y is pose cell position. hue is orientation, brightness is firing rate, contrast is variance of distribution of neurons firing.)
I’ve read all kinds of papers and articles on the visual system. It was mostly the V1 and retinas, but other systems helped with understanding too. Surprisingly, I was only able to find all the outputs the V1 made through an obscure image somewhere on the web. After the V1, I’m not sure what goes on.
I used Python and OpenCL. OpenCL let me program things with respect to individual neurons, rather than large sets of them. The only matrices so far are in the CPU-only code. Also, it’s fast.
I’m gonna try plugging this into pose cell simulations, then Nupic, sometime soon.
Here’s my work in progress : https://github.com/deric18/HTM/tree/master/HTM
This is small part of the whole system am planning on building , when this is complete It could do some nice things like working on lots of data for classification to grouping or memorise the event last time it happened or recreate a happened event . Right now it doesn’t do much. dericpinto.com
Added to Other HTM projects
If you’re still floating about, you may want to go save your domain.
I’m on my fifth implementation of an HTM system with spatial and temporal pooling. This last iteration includes the classifier layer as described in the latest(?) white paper.
I have read the initial white paper (2012 or thereabouts) and that was what got me started. I have tried to keep track of other Numenta publications, the HTM school and other published articles relating to interconnection between cortical layers and cortical regions together with dendritic morphology and the function of inhibiting cells in the cortical columns.
I have purposefully refrained from looking at any other implementations to make this an as exploratory experience as possible. My main goal has always been to try to recreate the results reported in the Numenta articles and thus, on some level, verify that the theory holds.
I’ve implemented everything in C++ to be able to utilize as many intrinsics as possible and invested in a beefier PC to enable larger scale experiments with as much parallel execution as possible. So far the threading has taken a back seat to exploring the algorithms but my experimenting has been promising. All development is done using emacs with some rudimentary graphical feedback using SDL2 with heat maps and equivalent information.
The source code is a mess of ideas with some focus on type algebra/templated functionality and quite some focus on aggressive compiler optimization which makes it unsuitable for public consumption. I do not have any goals to make it public but it might happen in the future.
As it stands now, I have working spatial and temporal pooling with some of my own ideas added (especially relating to integration functions in dendrites, dendrite activation and prediction density). On top of this I have a working classification layer with my own take on spatial information being part of both training and classification of test objects. The latter pretty much follows what was eluded to in the last article from Numenta regarding attribute aggregation for object detection.
My only wish when it comes to information is cleaner pseudo code and less ambiguities in the description of the algorithms. I’ve spent enough hours trying to decode the descriptions to not wanting to have to do it again with the next publication.
I hear you. I will be creating new pseudocode and another example codebase once I am done with these next few episodes of HTM School. Keep watching this space:
Show me that code and you get a badge!
I’ll keep that in mind.