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://www.examsupport.ie>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
