/ nengo-loihi Public
Fix keyword spotting example #103
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
@pblouw reported that his keyword spotting demo is broken in v0.3.0, and indeed our keyword spotting example is broken also. He tracked it down to this commit, which seems like it shouldn't even affect the keyword spotting network, but in fact it does.
The reason why that commit affects the keyword spotting network is that it translates all neuron->* connections in which
preis onchip and
postis offchip with
solver=NoSolver(weight.T)connection. This would be fine if those two connections made no difference to how the network behaves, but that is unfortunately not the case, as evidenced by the keyword spotting example failing.
Investigating this issue is made more complicated by the fact that it is impossible to compare the two connection types because
transform=weightsconnections are translated to
NoSolverconnections by the splitter. Commenting out this behavior in the splitter results in obvious differences between the two.
One way we can still investigate this is in looking at neuron->* connections in which
preis offchip and
postis onchip, as this case was not handled in the same way as the reverse of that, so
transform=weightsconnections still act differently from
solver=NoSolverconnections. This is definitely an oversight, but in this case a convenient one as it allowed me to write the
test_n2n_transform_solvertest in this PR.
Running that test with the commit it's introduced in (9042d86) reveals some hard to debug issues. Thanks to the new
allclosechanges, here's the first bunch of failures when comparing a connections with a transform and a NoSolver:
I attempted to fix this in splitter in f2ae792. I was not able to fix it (I find the
HostSendNodestuff quite confusing), but looking at how it fails now gives me some hope:
It looks like the
NoSolvercase might be operating the same as the
transformcase, only 6 timesteps delayed. We should make them the same, but seeing as I tried to do that here, I think I will need help to do that.
Also, even if we fix this case, it doesn't fix the keyword spotting example. However, it might give us a bit of insight into why the switch from the
transformconnection to the
NoSolverconnection made a difference. Does the way we did the connection splitting in 0811e2a have the same weird issue as in 9042d86, or is it simply delayed by some timesteps? My guess is that having several timesteps delay would not cause the keyword spotting example to change in the way that it changed, so I think we need to revisit the change in 0811e2a and ensure that switching the type of connection doesn't change behavior.