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.
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?
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 https://github.com/numenta/nupic.research, 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.
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.
So many strategical information in this thread…
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.
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.
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? for details.
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.
A correction to a previous post:
Including a vision for the future.