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