Survey: Features & API-Compatibility

Engineering NuPIC Community Fork
,
1

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.

Desired Features

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

0 voters

API-Compatibility:

This project started as a clone of Nupic and so it inherited Nupic’s API, which is documented at: http://nupic.docs.numenta.org/stable/api/index.html . Please check ONE of the following:

  • Strict API-Compatibility - Community fork should be a drop in replacement for numenta’s nupic.
  • Moderate API-Compatibility - Minor API changes are okay, as long as they’re done for good reason, are well documented, and cause minimal disruption.
  • Loose API-Compatibility - Improve Nupic as much as possible. My existing applications can be modified to work with a substantially changed API.

0 voters

Code Organization

Currently the code base is split into two repositories, and there has been some discussion around merging them into one repository. Please check ONE of the following:

  • All one repository - Ease of use, better continuous integration, will maintain strict separation between C++, Python, and Python Bindings for C++.
  • Separate C++ & Python repositories - I don’t want anything to change.
  • I’m interested in C++ only

0 voters

Thank you for your response.

4 Likes
3

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.

6 Likes
4

Thanks Matt!
I like what you suggest, keeping API and providing bindings ONLY at the level of NetworkAPI would give us flexibility in development and make a stable base where HTM community can unite.

Would be really great if you have some time to poke around with the repo, for your cpp requirements the repo should already suffice.

2 Likes
5

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.

Do most other people feel the same way?

1 Like
6

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.

1 Like
7

Some changes will make the lives of heavy C++ users a lot easier.

  1. Build as shared library. Linking against nupic takes forever and uses lots of RAM.
  2. Put building tests and examples into an option (Reducing build time)
  3. install to system directory by default.

I don’t know why the decisions are made in NuPIC the other way. But they get into the way sometime.

2 Likes
8

@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.

2 Likes
9

Slightly OT, @rhyolight do I remember correctly that some users may consume this forum as a weekly digest by mail? When does the mail arrive (Sundays)?

10

Everyone can set their email settings differently. Many don’t get emails, some get daily emails, some get a digest. I can’t really control it much.

1 Like
11

I’d like to ask for some experience the biggest, non-original language fork: numenta/htm.java
(OT: are you guys under numenta, a community, or a separate company?)

What level of API compatibility do you guys keep?

  • all public method signatures (from nupic.core / nupic (py) ?)
  • at NetworkAPI level? (did you have to make changes, do you have them documented?)
  • else?

I guess one of the benefits of Java for you is the platform independence, would a cpp backend be useful for you for speedups in some scenarios?

Some other advice you can give us on how to balance new developement, and keep compatibility with APIs and making code usable for the community?

@cogmission Another David to the party! :wink:

1 Like
12

I think that @ryholight is referring to the pure python implementations, not the C++/python bindings? Removing the pure python algorithms would also make our job a alot easier too.

13

I just want python bindings to the Network API. Everything can be implemented in C++ AFAIC.

2 Likes
14

I agree. For example, I found the following incomprehensible line in the ColumnPooler code (line 635). permanences is a sparse matrix.

permanences.setRandomZerosOnOuter(
    activeCells, growthCandidateInput, maxNewByCell, initialPermanence, rng)

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?

1 Like
15

Connections class would be very useful including its Python bindings, however I’m not sure if it should be a high priority item.

2 Likes
16

Thank you everyone who has voted or left a comment. We will collect the results of this survey and begin planning no sooner than Friday February 8th.

This survey will remain open for latecomers who wish to be heard. If you vote after the 8th please add a comment as well so that we are notified of your vote.

1 Like
17

I see there is a separate CUDA implementation of the SP and TM on the community Github. Has there been any thought of combining similar functionality into nupic.cpp baseline?

1 Like
18

I’m aware of SP CUDA: https://github.com/htm-community/htm.cuda

And yes, we would be interested to include CUDA SP as bindings into the nupic.cpp


If you have some experience with CUDA, please join the effort

19

@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…

20

I’m sorry, but I don’t quite understand what you are asking me, can you restate the question?