hi Fergal,
yes, that would be ideal solution. It would require some programming:
add id field to each {sensor/sp/tp/class ...} field, define list of inputs,
outputs and a dict of linkage.
This linear thing could be a first step, as it's almost no-brainer with no
visible changes to the code.
On Fri, Nov 22, 2013 at 7:06 PM, Fergal Byrne
<[email protected]>wrote:
> Hi Marek,
>
> I would generalise that further, by allowing a description.py to specify
> the entire Network description, using a dict structure to encode Subutai's
> example from the API thread. This would be easy to program and give you the
> full power of the API.
> —
> Sent from Mailbox <https://www.dropbox.com/mailbox> for iPhone
>
>
> On Fri, Nov 22, 2013 at 5:57 PM, Marek Otahal <[email protected]>wrote:
>
>> the description.py file tells (in OPF format) the model factory
>> how to set up a region.
>>
>> It consists of the following :
>>
>> Encoder --> (optional) SP --> (opt) TP --> Classifier
>>
>>
>> The format is something like JSON:
>> {
>> {sensor: 'encoder': 'ScalarEncoder' ,...}
>> {SP: ...}
>> {TP: ...}
>> {Classifier: ...}
>> }
>>
>> I think adding support for "linear hierarchy" wouldn't be much pain and
>> will be easy gain.
>>
>> By linear hierarchy I mean stacking multiple SPs and TPs upon each other.
>> ( encoder->SP->TP->SP-TP->Classifier).
>>
>> By non-linear hierarchy I would mean :
>>
>> C
>> / \
>> A B
>>
>> This linear hierarchy would be easy for users to set up, just write more
>> Sp,TP entries in the description.py (it should respect the order added).
>>
>> Advantage would be forming of more stable patterns which come with higher
>> hierarchy layers.
>>
>>
>>
>> --
>> Marek Otahal :o)
>>
>
>
> _______________________________________________
> 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
