Hi Mark, That's great stuff. To be honest, I'd go for the more radical solution and dump the classes in favour of vectors. The synapses should really be modelled as sparse matrices anyway, as you'd get both memory and CPU boosts that way. You could always use utility functions which would emulate the synapses. Look to the SP for how to do all that - it uses a big matrix instead of synapses and dendrites to model essentially the same thing.
I reckon as long as we're following the CLA in principle (ie the signal propagation between inputs and cells, and predictive signals among cells), it doesn't matter how it's implemented in detail. We can always synthesise the "classes" if we want to. Regards, Fergal Byrne On Thu, Nov 14, 2013 at 8:15 PM, Marek Otahal <[email protected]> wrote: > CEO summary: > 1/ drop InSynapse, move to map[] ? > 2/ drop unlimited synapses per Seg, set activation treshold automatically? > ---------------------------------------------------------- > > > This work started as a memory-reduction, but leads to how we want to > represent the abstract structures.. Classic tradeoff between readability > and speed. > > I want to run huge (human like) regions, which is unbearable with current > demands. So for optimization, I started with InSynapse which is lowest in > the hierarchy, thus brings highest gains (#cols * #cells * #segments * > #synapses). > > My first uptake is in https://github.com/numenta/nupic/pull/343 > it consists of removing 2 (out of 4) fields from InSynapse, thus dealing > (observable, will publish results later*) mem reduction (about half mem > consumed). > > The second solution, and my first question, is more drastical. It removes > InSynapse class completely and stores values in a map[srcCellIdx]=perm. > > Drawback: code doesnt 100% fit the whitepaper, separate synapse class was > intuitive (although it only holds a few values). > > Advantage: > further mem reduction-no need for class and struck objects (btw, how much > mem does a class and a struct take in c++, I fiddled w/ it in Java?) > > code is simpler > good for future optimisations by the GPGPU guys. > > So, what do you think about it? > > > > > The other question is about how to handle segmentActivationTreshold ? > > it's defined as a fixed #of ON synapses, while I find it biologically > accurate, as neurons also have membrane potential, that when reaches a > certain level, the synapses open. My problem is you have to set both > #synapses per segment, and activationTr., it's a big difference a 6active > out of 16, and out of 60. Could we find some reasonable default (nature > inspired?) and make one of these params dependant on the other? (set > #synapses per Seg, and active treshold is 0.3 of that) thus removing this > knowledge from the user. Or is there a usecase where it'd be of an > advantage to set both of these? > > It becomes even worse when you allow "unlimited synapse #" per seg. You > can start with 6 out of 10, and end up with 6 out of 100, what's the > meaning? > > There's comments in the code that this unlimited synapses (-1 on OPF) > should be removed, do you agree? > > Thanks to Subutai for first discussion on this! > > > > Mark > > -- > Marek Otahal :o) > > _______________________________________________ > 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
