That is, but without OPF, you're on your own, only with spatial pooler, temporal p. and encoders. Yesterday I learned that OPF (through some component) does some tricks for better results eg in multistep inference -> it keeps marks when probabilities are uncertain, and when then 5 steps further results are bad, backtracks and tries the other way.
It would be good to collect what useful functionality OPF provides and that would be hard to implement manually in every project. On Fri, Nov 15, 2013 at 12:37 AM, Erik Blas <[email protected]> wrote: > I concur that the API != OPF. As you said, the OPF is merely an > implementation of the API and should be considered as such. Perhaps someone > can deconstruct the OPF modules and provide documentation for implementing > one's own client? > > > On Thu, Nov 14, 2013 at 3:02 PM, Matthew Taylor <[email protected]> wrote: > >> Since this is off the topic of releasing and versioning, I'm changing >> the subject, which should make it a new thread in the mailing list. >> See Marek's initial post below for context for my message. >> >> I think the API should be defined without the OPF. The OPF is an >> example of an NuPIC API client. The documentation and hardening needs >> to happen beneath the OPF. >> >> --------- >> Matt Taylor >> OS Community Flag-Bearer >> Numenta >> >> >> On Thu, Nov 14, 2013 at 2:45 PM, Marek Otahal <[email protected]> >> wrote: >> > Guys, sorry for jumping on this thread, so please disregard if OT. >> > >> > What I don't like on the OPF is the "magic", another layer between >> TP/SP and >> > the application. Recently I wanted to change something and couldn't find >> > where it's set. >> > >> > So to make any format future-proof, we must find some generic solution. >> One >> > idea could be using API getXXX(), setXXX(vvv) methods. so you can have >> > format { CLA { XXX1: 5}} and it'll call eval(set{XXX1}, 5) this way, new >> > functionality can be extended w/o breaking the format. >> > >> > Any ideas? >> > >> > >> > >> > On Thu, Nov 14, 2013 at 11:23 PM, Fergal Byrne < >> [email protected]> >> > wrote: >> >> >> >> Cheers Matt, >> >> >> >> Really good responses there. Regarding the API, I think we need to >> harden >> >> our language about what we mean. Fortunately and unfortunately the >> >> configuration API is high-dimensional and opaque as you say, but there >> will >> >> be a way to perform a separation of concerns on that, in order to >> simplify >> >> it and then codify it in a way which makes sense to everyone. (That's >> one of >> >> the reasons I included tools for creating description.py as a needed >> >> product). >> >> >> >> May I take a stab at this? (all items are just a subset of the configs >> in >> >> each set) >> >> >> >> == CLA Size Config == >> >> - region width/height in columns >> >> - cells per column >> >> - dendrite segments per cell >> >> ... >> >> >> >> == Sensory Config == >> >> - topological/global potential pool >> >> - potential pool size >> >> ... >> >> >> >> == Algorithmic Config == >> >> - SP class >> >> - TP class >> >> - Classifier class >> >> - Injected functionality? >> >> >> >> == Spatial Pooler Config == >> >> - local/global inhibition >> >> ... >> >> >> >> == Temporal Pooler Config == >> >> ... >> >> >> >> == Inference Config == >> >> ... >> >> >> >> == Output Config == >> >> ... >> >> >> >> and so on. >> >> >> >> >> >> >> >> >> >> On Thu, Nov 14, 2013 at 9:42 PM, Matthew Taylor <[email protected]> >> wrote: >> >>> >> >>> On Thu, Nov 14, 2013 at 11:54 AM, Fergal Byrne >> >>> <[email protected]> wrote: >> >>> > we should perhaps create a >> >>> > design for what NuPIC is going to be when it grows up, and that will >> >>> > illuminate the discussion about how it's released and stabilised. >> >>> >> >>> Yes, and I think it's my job to create a draft of this on the wiki to >> >>> kick of the conversation. I have a Road Map, but it is already out of >> >>> date and does not envision far enough into the future. I'll be working >> >>> on this, and it will be a starting point for a community conversation. >> >>> I'll take the options you listed and put something together so we can >> >>> prioritize them. >> >>> >> >>> > I agree with Stewart that we may not need v1.2.3 style releases for >> the >> >>> > core >> >>> > NuPIC software. If we have to make a change to the core API of >> NuPIC, >> >>> > then >> >>> > we should make a release which provides the old API for those who >> >>> > depend on >> >>> > it. >> >>> >> >>> This is also an argument for establishing at least an initial beta >> >>> release very soon, no matter what method we decide to use in order to >> >>> do it. >> >>> >> >>> > I can't really envisage how this would happen at all often, because >> the >> >>> > core API is very solid. >> >>> >> >>> I disagree. The API is extremely broad and ill-documented. The >> >>> functions may be well-established, but the configuration options and >> >>> parameters are plenty, largely opaque, and still subject to additions >> >>> and changes. Because of NuPIC's flexibility, there are many ways to >> >>> implement a solution to a problem, and currently the only way of doing >> >>> this is by stumbling through the example applications or reading wiki >> >>> pages. >> >>> >> >>> The API will not be solid until it is documented and marked with a >> >>> version number. IMO, this should be the #1 priority for the future >> >>> welfare of our project. I agree with Stewart, we cannot create a >> >>> release without solidifying the API, and that means documenting the >> >>> entire surface area. I think a concerted effort to do this will expose >> >>> just how pock-marked our API is. >> >>> >> >>> --------- >> >>> Matt Taylor >> >>> OS Community Flag-Bearer >> >>> Numenta >> >>> >> >>> _______________________________________________ >> >>> nupic mailing list >> >>> [email protected] >> >>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Fergal Byrne, Brenter IT >> >> >> >> http://inbits.com - Better Living through Thoughtful Technology >> >> >> >> e:[email protected] t:+353 83 4214179 >> >> Formerly of Adnet [email protected] http://www.adnet.ie >> >> >> >> _______________________________________________ >> >> nupic mailing list >> >> [email protected] >> >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> >> > >> > >> > >> > -- >> > Marek Otahal :o) >> > >> > _______________________________________________ >> > nupic mailing list >> > [email protected] >> > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> > >> >> _______________________________________________ >> nupic mailing list >> [email protected] >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> > > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > > -- Marek Otahal :o)
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
