Fix issue: #3532: Disconnect issue with CompressedSpikes:ON/Off #3536
Conversation
med-ayssar
changed the title
gtrensch
added
T: Bug
heplesser
added
S: High
|
@med-ayssar Thanks for your detective work and the PR! I will look at it in detail asap. |
There was a problem hiding this comment.
@med-ayssar Thanks for the PR! I am not entirely sure I follow the logic around nth_equal(), see comments below.
I also wonder if, for the uncompressed case, we should not take a different approach. In that case, I believe, we simply need to run through all connections of a given synapse type linearly and disconnect the first one for which source and target match, and which has not yet been disconnected. I guess that means parallel iteration through source and target tables. The split into find_first_source() and find_first_target() does not make sense in that case.
We also need some tests, including tests where there are multiple connections between the same source-target pair and we delete one at a time.
| return lcid; | ||
| } | ||
| ++pos; | ||
| res = nth_equal( std::next( res.second ), end, value, pos ); |
There was a problem hiding this comment.
I don't get your logic here with counting pos up and then doing pos rounds in nth_equal(). Since you call nth_equal() with first == std::next( res.second ), aren't you already looking for the next occurence of value?
There was a problem hiding this comment.
You are right, I was thinking to put the nth_equal function in some different namespace or file. The idea was just to make it too general, trying to find thenth element equal to val.
There was a problem hiding this comment.
I will try applying your suggestion and let you know ASAP!
| }; | ||
| size_t pos = 0; | ||
| auto res = nth_equal( begin, end, value, pos ); | ||
| if ( !res.first ) |
There was a problem hiding this comment.
According to NEST coding standards, please write out not, and, or. A bit surprised that our CI setup didn't detect his, @terhorstd.
github-project-automation
bot
moved this from In progress
to PRs pending approval
in Kernel
Fix for #3532