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://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
>
>
--
Marek Otahal :o)
_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
