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
