No we are not committed to the OPF at all. It is an outdated interface. I think there is a place for something like the OPF, but it should be re-thought from scratch for a particular domain problem.
That is a valuable information! THanks for clarifying.
Agreed, although I cannot say if Iām happy to hear.
Are there plans at Numenta to putting some resources to change that and develop a new API? Iām asking for projects like NAB (maybe htm.research too?) that depend on it. And Iād like for community to be able to participate.
PS: could you separate this discussion in a new thread maybe?
TL;DR: Will the OPF be replaced? Yes, eventually, but with something completely different. We donāt even know what it looks like yet.
Our research is clearly moving towards building sensorimotor models. The OPF is too simple to accommodate these scenarios, so it is time to rethink what we really need.
We are now in the realm of agency in environments, and Iām afraid that encoding in these environments will be very specific and customized. I think of an environment as set of rules that establish how knowledge is located, and a movement profile. We can create virtual 3D physical environments, for example, that can be defined in cartesian coordinates, with features at different coordinates. Other environments might be defined in more abstract ways, like a network protocol, a graph, or a data schema. In any case, an agent must have agency in the environment. It must be able to move from place to place in some way, and get feature data at each location. The movements in one environment must be consistent, hence a āmovement profileā.
HTM needs to define reference frames in every environment given sensory data. Sensory data must have a movement profile through the environment in order to create a stable reference frame.
These are the terms weāre starting to think in. The future APIs for this type of system is still undefined.
3 Likes
This raises the broader question of what approach Numenta currently recommends, or will recommend in the future.
Obviously the OPF isnāt recommended. Is the Network API going that way too? Or is a lower level approach better? Is Python expected to be maintained as a primary language for working with HTM or is C++ likely to be preferred in the future?
3 Likes
NAB is being updated to run in Python 3, but the NuPIC contenders will remain in Pythonn 2. We want to keep the benchmark up to date with python, but we have no plans of updating the current numenta detectors. We might add more detectors in the future, but this is not a priority.
htmresearch-core will be updated with the smallest amount of python bindings we can get away with to keep current experiments working (live streaming this tomorrow). The htmresearch repo is still 2.7 and has been archived, along with htmresearch-core (c++). The new primary research repo is at GitHub - numenta/nupic.research: Experimental algorithms. Unsupported., and it is written in Python 3. It currently has no C++. But if we need to use C++, we will put it here with bindings.
If the community wants to build a framework like the OPF that helps create common types of models, I suggest this be built from scratch in Python 3 using nupic.cpp. I would support this effort as much as possible. We need a decent Python 3 HTM framework, and it doesnāt have to be a reference framework. I think you should convert nupic.py into the new OPF and pull out all the algorithms (leave them in nupic.cpp). Build the framework you want in nupic.py. I think I can find some time to help with this as a part of my ācommunity projectsā twitch schedule.
Then rename where XXX is whatever you decide to name your new OPF.
nupic.py==>htm.xxxnupic.cpp==>htm.cpp
1 Like
This is an open discussion, even here amongst us. I donāt see it going away anytime soon, but some researchers are not using it.
1 Like
So many strategical information in this threadā¦ 
and
Agreed, I also prefer to use directly the algorithm API. You mentioned different/sensory-motor experiment,agents etc. Thatās ok, but that is an experiment description framework. Another part of OPF was running, evaluating the model and tuning its parameters. And this boils down to optimizing the low level params (of SP, TM etc). That need is going to stay.
and
I have a question about this too. Is there a Py3 implementation Numenta, and htm.research will switch to? As it seems to me that thereās not enough activity at that front, and the python3 compatible nupic.cpp will not be officially endorsed.
Iāve seen a new repo nupic.pytorch which would make sense for a new rewrite and tensorflow acceleration. This would make nupic.cpp quite obsoleted, as programing in cpp is not as convenient as in python, but can give you the speed. Thatās why we all use c++ nupic.
Iām not worried about python2/3 but the OPF framework, which NAB requires. So it seems I need to support that to be able to benchmark.
Iām not personaly interested in OPF, I only need swarming/param.optimization, for which weāll then support different approach in nupic.cpp.
There could be htm.OPF, or htm.models repos. For nupic.py Iād like to stay as pure-python HTM implementation (that is py3 compat), I donāt know of any complete that is compatible?
IF you only want python3 support, nupic.cpp should be your best bet, as weāre improving the python bindings, and import the missing python code.
2 Likes
That is a good point. Swarming and the OPF go hand-in-hand. If you drop OPF, you also drop swarming. IMO the right thing is to decouple the two concepts, but then you need something like the OPF to provide an interface for parameter optimization. With regards to ongoing Numenta research, I see no need for swarming in the future (if there is, it will be highly specialized for some particular environment).
Numenta needs to run core algorithms in C++ in Python 3. Our plan is to create as few bindings as possible, with as small an API as possible, in htmresearch-core. That will be the Python 3 API for htmresearch. This is not expected to be the āofficial python 3ā version, it is just for research. Of course anyone may try using it, but weāll continue treating it like research.
The long and short answer is that Numenta will not be providing an āofficialā Python 3 version of HTM. The default Python 3 version will be whatever happens with the community fork. I would like to see it evolve as I described above.
We are splitting up NAB into two repos, one with the scoring logic and leaderboards, and the other with the detectors. The main repo with the scoring logic will be updated to Python 3. The repo with all the detectors has different runtimes (potentially one for each detector). See Does the current community version fully support NAB in Python 3.6? - #8 by rhyolight for details.
1 Like
Conceptually, parameter optimization requires two things:
- The parameters
- Must be in a machine readable format
- Must be accessible to the parameter optimization program as well as the experiment being optimized
- A function which accepts the parameters and returns a score.
- This is (or should call) the
mainfunction for the experiment being optimized
- This is (or should call) the
The parameter optimization program does not need to be specific to HTMs.
1 Like
A correction to a previous post:
Including a vision for the future.
Hi Matt,
Thanks for sharing your vision for the future.
I can not officially bless nupic.cpp
Thatās fine. I agree that nupic.cpp can become the defacto standard through us informally promoting it on this forum. Also, by not updating the old nupic versions you help the community version gain steam.
The current status of nupic.cpp is as follows:
-
The algorithms and user interfaces are much improved. The code runs a lot faster, and we redesigned many of the algorithms APIs for ease of use. This area of work is (by my assessment) mostly done. The biggest outstanding tasks here are documentation and code examples. You can help us with this! Try using our library and code examples and communicate to us any questions or problems you have.
-
About OPF: I donāt think that OPF will be included in nupic.cpp. There was a little discussion (*) but I donāt think that anyone is going to volunteer the time to make it happen. In place of OPF, we are recommending users try out the NetworkAPI which David Keeney has been working on. I donāt know the working status of the NetworkAPI.
1 Like
The NetworkAPI is operational. I have tried to maintain a consistent API for the NetworkAPI even though the algorithm API has evolved. I have also ported TMRegion and SPRegion into C++. This means a lot of the Python code used for NetworkAPI has been replaced with ābuilt-inā regions. In fact, it is now possible to write most if not all of a system in C++ without using any Python.
The next big step is to change the nupic namespace to htm and this will probably include changing the directory paths as well. That means that NetworkAPI will have to change the names used in the API but everything else should remain the same. As part of this step we may change the name of the repository to something like htm.core.
1 Like
Let me know if you need any assistance with this.
renamed to htm.core (former nupic.cpp, community continuation of nupic.core) and using namespace htm::.
nupic ā¢ is all yours (Numenta) now.
@rhyolight you have have some spare time for the community repo, I would need your help with āpublishing binary releases on GHā, please. All is set up, but I can never make it work with the git tags. It seems it worked in the past somewhatā¦