Survey: Features & API-Compatibility

[cogmission]

Hi @breznak,

@breznak

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?

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.

@breznak

at NetworkAPI level? (did you have to make changes, do you have them documented?)

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)

@breznak

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?

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

@breznak

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?

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

[dmac]

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.

[breznak]

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,

Biological Constraints

In the C++ community fork, we’re considering dropping support for several features which are not biologically plausible, but which may be useful nonetheless. Summary of the features in question: BacktrackingTM This is a variant of the Temporal Memory algorithm. It is specialized for anomaly detection, and on the Numenta Anomaly Benchmark it scores approximately 5% higher than the regular Temporal Memory. It is not biologically plausible. Numenta has stopped working on it in favor of the regul…