# Alternative HTM library?

**URL:** <https://discourse.numenta.org/t/alternative-htm-library/7176>\
**Category:** Implementations\
**Tags:** question\
**Created:** [February 12, 2020, 4:14pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176 "2020-02-12T16:14:39Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dan\_Stromberg](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/dan_stromberg/32/4171_2.png) [@Dan\_Stromberg](https://discourse.numenta.org/u/Dan_Stromberg)\
**Post date:** [February 12, 2020, 4:14pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/1 "2020-02-12T16:14:39Z")

</div>

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/](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!

---

<div class="post-metadata">

**Author:** ![rhyolight](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/rhyolight/32/3922_2.png) [@rhyolight](https://discourse.numenta.org/u/rhyolight)\
**Post date:** [February 12, 2020, 4:26pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/2 "2020-02-12T16:26:28Z")

</div>

Use [htm.core](https://github.com/htm-community/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.

---

<div class="post-metadata">

**Author:** ![Dan\_Stromberg](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/dan_stromberg/32/4171_2.png) [@Dan\_Stromberg](https://discourse.numenta.org/u/Dan_Stromberg)\
**Post date:** [February 12, 2020, 4:54pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/3 "2020-02-12T16:54:25Z")

</div>

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:

> <https://opensource.stackexchange.com/questions/4083/does-accessing-the-rest-interface-of-a-agpl-licensed-server-make-the-client-a-de>

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

---

<div class="post-metadata">

**Author:** ![rhyolight](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/rhyolight/32/3922_2.png) [@rhyolight](https://discourse.numenta.org/u/rhyolight)\
**Post date:** [February 12, 2020, 5:11pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/4 "2020-02-12T17:11:37Z")

</div>

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](https://github.com/htm-community/hitc), but this pretty old code.

---

<div class="post-metadata">

**Author:** ![Dan\_Stromberg](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/dan_stromberg/32/4171_2.png) [@Dan\_Stromberg](https://discourse.numenta.org/u/Dan_Stromberg)\
**Post date:** [February 12, 2020, 8:10pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/5 "2020-02-12T20:10:09Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Paul\_Lamb](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/paul_lamb/32/2725_2.png) [@Paul\_Lamb](https://discourse.numenta.org/u/Paul_Lamb)\
**Post date:** [February 12, 2020, 9:54pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/6 "2020-02-12T21:54:38Z")

</div>

> [@Dan\_Stromberg](#):
>
> I’m hearing that this part of our code is too performance-sensitive to add REST calls in place of Python function/method calls

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

---

<div class="post-metadata">

**Author:** ![David\_Keeney](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/david_keeney/32/1616_2.png) [@David\_Keeney](https://discourse.numenta.org/u/David_Keeney)\
**Post date:** [February 12, 2020, 9:59pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/7 "2020-02-12T21:59:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Dan\_Stromberg](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/dan_stromberg/32/4171_2.png) [@Dan\_Stromberg](https://discourse.numenta.org/u/Dan_Stromberg)\
**Post date:** [February 12, 2020, 10:01pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/8 "2020-02-12T22:01:10Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![David\_Keeney](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/david_keeney/32/1616_2.png) [@David\_Keeney](https://discourse.numenta.org/u/David_Keeney)\
**Post date:** [February 12, 2020, 10:03pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/9 "2020-02-12T22:03:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![David\_Keeney](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/david_keeney/32/1616_2.png) [@David\_Keeney](https://discourse.numenta.org/u/David_Keeney)\
**Post date:** [February 12, 2020, 10:12pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/10 "2020-02-12T22:12:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![marty1885](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/marty1885/32/1891_2.png) [@marty1885](https://discourse.numenta.org/u/marty1885)\
**Post date:** [February 13, 2020, 1:19pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/11 "2020-02-13T13:19:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Dan\_Stromberg](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.numenta.org/dan_stromberg/32/4171_2.png) [@Dan\_Stromberg](https://discourse.numenta.org/u/Dan_Stromberg)\
**Post date:** [February 13, 2020, 4:24pm UTC](https://discourse.numenta.org/t/alternative-htm-library/7176/12 "2020-02-13T16:24:25Z")

</div>

Hi Marty.

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

Thanks.