Conversation
breznak
left a comment
There was a problem hiding this comment.
I really like the new research this brings in.
And the throughout tests 👍
A few nits to the implementation.
But I don't see this actually used anywhere. Can you add a bool toggle to the SP,TM to actually make use of the new feature? Ideally show it in the MNIST exeriment?
| void Connections::synapseCompetition( | ||
| const Segment segment, | ||
| const SynapseIdx minimumSynapses, | ||
| const SynapseIdx maximumSynapses) |
There was a problem hiding this comment.
do we also have something like Connections' minConnectedSynapsesPerSegment ? If so, please also check against that
There was a problem hiding this comment.
We have a method Connections::raisePermanencesToThreshold. What about it?
There was a problem hiding this comment.
not a method, constants. Whether connections have in itself defined some limits, in the meaning of what minimumSynapses are.
I have integrated it into the MNIST experiment on the branch |
yes, and as this is useful general-purpose and could conceptually be useful in SP/TM as well. Where should it be called?
|
I don't know about the TM, I haven't tested this at all. The TM uses different methods to control the number of synapses in its potential pool; it add synapses when it wants more, and it does not add more synapses than it needs.
I don't think that inhibitory cells have anything to do with controlling the number of synapses. I also think that competition is more descriptive - it states what it does, not how it does it. |
can you add your experiment as an example? If we can visualize synapse utilization in SP on the MNIST task, we can compare with using this feature and potentialy make it default.
that's right 👍 |
This is done by saving the connections to file (which the MNIST example already does), and calling |
oh, I forgot about that script! Will try it out |
sort directly by permanences instead of indirectly by synapses
breznak
left a comment
There was a problem hiding this comment.
A really nice feature! and great tests 👍
- a number of, but small, nits; soon we're ready to go
- please link the doc/motivation you've posted somewhere
- can you add the python script with histogram if permanences?
- and most importantly, ok if this is to be used for ColumnPooler, but I'd love to see at least experiment using it with current SP,TM. (if works well either as default, or with a toggle)
Thanks 🆒
| // Sort the potential pool by permanence values, and look for the synapse with | ||
| // the N'th greatest permanence, where N is the desired number of connected | ||
| // synapses. Then calculate how much to change the N'th synapses permance by | ||
| // such that it becomes a connected synapse. After that there will be exactly |
There was a problem hiding this comment.
how much to change the N'th synapses permance by such that it becomes a connected synapse
Unrelated to acceptance of this PR, but: what is the biological mechanism for this? I am doing some work on at SP now and realized I "dont like" raisePermanencesToThreshold. The biological synapse cannot have this, and grow bit by bit (synPermActiveInc).
There was a problem hiding this comment.
@ctrl-z-9000-times ping on this PR, I'm looking forward to have it merge, when you have time to integrated the feedback 👼
Still thinking about this PR:
-
- please make it used in SP, TM.
-
- consider the following:
- instead of
bumpSegmentthat puts all misperforming synapses in line (to min/max-desired) - have them die out.
- if too few synapses on segment, create a random new. Or create each time one is removed/dead.
| emptySegment.ncon = 0; | ||
| emptySegment.min = 3; | ||
| emptySegment.max = 100; | ||
| emptySegment.dont_check = true; |
There was a problem hiding this comment.
can we create a new synapse on an empty seg, if needed, rather than failing?
There was a problem hiding this comment.
The synapse competition method does not have access to the current inputs. The call would need to specify which presynapses to use.
|
Breznak, I did everything except to actually use it in the SpatialPooler. |
the new test is feiling with Debug.
that's a pity, but fine, I'll try this later.
|
|
Thanks for approving!
Yes, the SP could use this. The TM should not need it, I don't think this is applicable to the TM's segments.
Your right: this does not need to be called too often.
Call after each call to |
breznak
left a comment
There was a problem hiding this comment.
Thank you @ctrl-z-9000-times for this new functionality! Looking forward for seeing it used.
As discussed on the forum: https://discourse.numenta.org/t/synapse-competition/5957