Alternative HTM library?

Engineering Implementations
1

Hi folks.

Does anyone know of opensource and/or commercial code that would allow the replacement of functionality related to the following nupic.py imports?

  1. from nupic.frameworks.opf.htm_prediction_model import HTMPredictionModel
  2. from nupic.algorithms.anomaly_likelihood import AnomalyLikelihood
  3. from nupic.frameworks.opf.common_models.cluster_params import getScalarMetricWithTimeOfDayAnomalyParams
  4. from nupic.frameworks.opf.model_factory import ModelFactory

We’re aware of htm.core, but its license disallows us from using it, said license effectively being AGPL.

I’m thinking a drop-in replacement would be too much to hope for, but maybe something is out there that would work with some hard work?

I think Python 3 would probably be ideal, but does it help if we’re willing to rewrite in another language? Java, C++, Golang, Clojure: they all sound interesting, and I do not mean to limit the discussion to these five.

I see the four implementations at https://numenta.org/implementations/ , but this page seems a bit dated; it does not include Etaler and it doesn’t point out that nupic.py only runs on an outdated version of Python. Also, I’m afraid I don’t know enough about HTM to tell if these implementations can do something similar to imports 1 through 4 above.

Please advise?

Thanks!

1 Like
2

Use htm.core which has python 3 bindings. I’ve used it and it worked for me so far. It is the primary HTM being developed by this community right now.

3

We’re aware of htm.core, and it’d be an attractive option for us if it weren’t for the project’s (effectively) AGPL license.

I wonder, though, if we could put together a microservice REST interface for just those four parts we need using htm.core, and then give away just that microservice. Does AGPL allow something like that? It might prove too slow, but still seems like an option to keep in mind.

Here’s a link on REST and AGPL:


But I’m not sure if the respondents are lawyers.

4

You can create an HTTP server that hosts an HTM service that is AGPL. That HTTP server code must also be AGPL, but it allows you to create clients to that service that can be whatever license you like. We have experimented with this here, but this pretty old code.

1 Like
5

I’m hearing that this part of our code is too performance-sensitive to add REST calls in place of Python function/method calls.

So the question remains: Are there any HTM libraries available that can do the equivalent of imports 1-4 (above) other than htm.core?

6

Personally, I would just address that by creating higher-level REST services rather than wrapping the low-level functions directly.

1 Like
7

As one of the maintainers of htm.core let me offer another alternative. The NetworkAPI facilities in htm.core are constructed such that there is a plugin (which we call a Region) for each algorithm. During execution, data flow passes from plugin to plugin according to your app. We have regions written in C++ as well as Python. The plugins constructed for the algorithms such as encoders, SP, TM, anomaly_likelihood and prediction do access the common library and the license applies to them.

However, you can write the main app and any other plugins you like that can be compiled separately in any language. Since they are linked at runtime these extra modules can be any license as long as they don’t link with the core library…and they would not need to. So, you pass your data to an encoder using a REST or whatever, the NetworkAPI passes that data through the algorithms arranged any way you would like and passes the data to one of your plugins where you could do what you want with it.

Each invocation of NetworkAPI could be at a higher level REST as Paul suggests.

Your list includes OPF components. We did not think any one was still using that so we did not port that to C++ as plugins. But the old OPF just called the lower level algorithms which we do include.

2 Likes
8

That’s a good thought, but in this case it would require us to give away too much of our code, because it would become a large derivative work.

9

No, as long as your plugins don’t link with the core library you don’t have to give away anything.
Your plugins are not compiled with our plugins.

10

If this approach interests you, PM me and I am sure we can work out a design where you don’t need to give away anything.

1 Like
11

Seeing Etaler mentioned.
Unfortunately Etaler isn’t a drop in replacement of NuPIC nor support OPF. A considerable rewired of your code base will be needed. Think like switching from TensorFlow to PyTorch. They do the same thing, but you’ll have to express what you want to do in a different way.

12

Hi Marty.

We don’t necessarily need a drop-in replacement - just something with similar functionality for those 4 imports.

Thanks.