This survey is about the htm-community fork of Numenta’s Nupic code repository. The purpose of this survey is to determine the overall goals and direction for this project. We are trying to make plans for what to do with this code and we want to hear from all of you.
I encourage all prospective users to respond. We will leave this survey open indefinitely. Comments & feedback are welcome.
We have an implementation of all of these things which originated in the Numenta repository. Currently none of these things fully work, some are outright broken. This is a work in progress, and we don’t know how long this will take. Please check as many of the features as you’d like:
Algorithms in C++ - Fast and production ready.
C++/Python bindings - Fast, production ready, and easy to use.
Algorithms in Python (no C++) - Good for experimentation
NetworkAPI (Regions, Links, Engine)
OPF framework, Swarming, and other parameter optimization techniques
Other - Write feature requests in reply to this thread
Honestly I am a potential user of this library so I voted too!
I wanted to explain some of my answers. I don’t want the OPF, and I don’t care of the python version of the algorithms. I just want a fast C++ core with a simple Network API that allows all the flexibility we have today with the NuPIC Network API. I would love to see python bindings for the Network API so we could easily build networks in Python.
I don’t care of the python version of the algorithms
Cool, that would make our job a LOT easier. We just keep the .py bindings for NetworkAPI and remove the algorithm bindings.
We would however need to port RegionSP and RegionTM to C++ in order for that to work since currently the SP and TM algorithms in C++ can only be accessed by NetworkAPI by calling back into python. I have most of that work done already we just need to drop it in and adjust to recent changes.
I’m only a moderate user of nupic but I voted anyways. I’m a python and a c/c++ developer and I’m alright with “production-ready” c++ algorithms core code. Even without python versions of these algorithms (no c++ just py bindings) I’m ok with it as long as we don’t lose the ease of introspecting python objects in python code. This is very important for experimentation. For example, I’d like to easily introspect synapse values and work on them 90% of the time for experimentation purposes. Today this is possible in nupic but it is not straightforward and intuitive to do in python at least in my view.
@marty1885 Thanks for the feedback! Please do open these as separate issues in our bugtracker, we’ll look into it together.
1 - I think we tried, considered shared lib (not sure if/why it ended up as static)
2 - easily doable
3 - that requires admin access, and is as easily doable now
…but let’s keep the discussion of the details to the bugtracker, not in this thread.
One of the technical goals for this project is to replace all of the matrices. We’re replacing them with the Connections class, which is a C++ module which deals with synapses and dendritic segments, and does them well.
It has a well designed API. It has data-structures for cells, segments, synapses, and methods to control them all.
It can apply inputs to the synapses and calculate the resulting overlap at each segment.
It can do Hebbian learning.
It is currently used for the C++ Spatial Pooler & C++ Temporal Memory
It’s faster than the current sparse matrix implementation.
I’d like to eventually write python bindings for the connections class. However, this is a low priority. Do you think that bindings for the Connections class should be a high priority item?
@rhyolight speaking about forks, how’s the status of the community around Numenta’s nupic.core / nupic?
I remember it was very lively, has everybody moved to separate projects? I see buzz on the forums here, but not in a centric repo or so…