Survey: Features & API-Compatibility

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

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

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

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

@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

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)?

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

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

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.

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

2 Likes

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

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

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

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

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

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

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

Hi @breznak,

We kept absolute parity with all of the discrete algorithms. This has been tested very thoroughly for bit level output which is exact throughout the full life of a running program. This is achieved by replacing the Random Number Generator in both the Python/C++ code base and the HTM.Java codebase with a “Universal” RNG (which is also tested extremely thoroughly); and running them side-by-side comparing the output, dendritic composition, and synaptic values.

  1. Yes, HTM.Java’s NetworkAPI is very well documented (see the wiki). (And for examples of the many variations you can use, see the tests in the network package)

  2. HTM.Java’s NetworkAPI is a total design departure emphasizing Streaming and functional operations (using RxJava) in order to allow combining networks (and network sub-components) as a functional term in a functional statement which can then have operations execute on it - in whatever desired combination of software - as an enhanced capability. It also emphasizes ease of setup and comprehension due to the “fluent” styled API offering…

For example, this is all you need to get a fully operational HTM system up and running in HTM.Java:

Parameters p = NetworkDemoHarness.getParameters(); // "Default" test parameters (you will need to tweak)
p = p.union(NetworkDemoHarness.getNetworkDemoTestEncoderParams()); // Combine "default" encoder parameters.

Network network = Network.create("Network API Demo", p)         // Name the Network whatever you wish...
    .add(Network.createRegion("Region 1")                       // Name the Region whatever you wish...
        .add(Network.createLayer("Layer 2/3", p)                // Name the Layer whatever you wish...
            .alterParameter(KEY.AUTO_CLASSIFY, Boolean.TRUE)    // (Optional) Add a CLAClassifier
            .add(Anomaly.create())                              // (Optional) Add an Anomaly detector
            .add(new TemporalMemory())                          // Core Component but also it's "optional"
            .add(new SpatialPooler())                           // Core Component, but also "optional"
            .add(Sensor.create(FileSensor::create, SensorParams.create(
                Keys::path, "", ResourceLocator.path("rec-center-hourly.csv"))))));  // Sensors automatically connect to your source data, but you may omit this and pump data direction in!

network.start();

However, the tested output is EXACTLY the same as the output you would get in a similar setup using NuPIC. (Versions at the time of development, being equal)

I have comments I would like to make about this… (down below)

Compatibility depends on a unified vision & direction for the code. Added “nice-to-haves” and experimentation is all well and good - BUT - without agreements as to what the overall end goal is going to be, it could eventually branch off to become something nice to use but too much of a departure from the “canonical” direction of a code body which is aligned with established research direction.

This is what worries me… I have been waiting for the next rally of “official” NuPIC code once Numenta’s prime directive of research has development of a reference implementation rejoined with it. Until this happens, or, until the “research” repository is officially sanctioned - I really don’t have an opinion.

We are all excited for the expansion of an HTM (canonical/proper) code base, but without Numenta’s commitment of “research” code as canonical, what can you do except play around and experiment? Maybe I have it put together wrong, but this is why I’ve been sitting around on the sidelines - because until things go into NuPIC proper, I have no idea what constitutes forward progression and what constitutes enthusiastic idle ramblings? :stuck_out_tongue: (in terms of the codebase in the research repository).

Then again, we are all hungry for progress - and we love to build things, so… This could be a great outlet… (a.k.a a good “guide” or source of feedback to Numenta as to the preferences of the HTM Community - and what they’d like to see in the future in an “official” API expansion)

2 Likes

Follow Up

I want to thank everyone who voted and left comments. We, the active developers of the community fork, have agreed on an agenda which we’d like to share with you. These are tentative goals for the next release of this project:

  • An HTM which is accessible in C++ and Python

    • Will be implemented in C++, with bindings to python language.
    • Loose API compatibility with previous versions of Nupic. We will change the API to improve the implementation and the usability of the algorithms, while trying not to diverge too much from the original API.
  • The NetworkAPI

    • Strong API compatibility with previous versions of Nupic
    • To support: Python, stand-alone C++, and C# interfaces.
    • Access to more built-in algorithms and encoders (C++ and do not require Python)
    • Multi-threading; parallel execution of regions when possible.
  • Ongoing Research:

    • HTM theory is still being researched, and as new models are made and tested, we can polish them and bring them into this repository.

Code Organization

  • We will endeavour to deliver a single code repository which contains the necessary tools in both C++ & Python.

    • However we won’t copy the entire python repository into the C++ repository. Instead we will copy files when they’re needed and ready (meaning they pass a code review).
    • Not on this agenda: supporting duplicate algorithms in both C++ & Python.
    • Merging the unit-tests is our priority here, since they can be used to verify API compatibility

We are happy to welcome new testers and developers. Here is our github page where you can get started.

1 Like

Follow up,
we’re discussing dropping support for old features, which will allow us to work better with modern TM and friends.
Have a look,