ioam / topographica

A general-purpose neural simulator focusing on topographic maps.
topographica.org
BSD 3-Clause "New" or "Revised" License
53 stars 32 forks source link

Bug: Gain control projections do not work properly #585

Closed Tobias-Fischer closed 10 years ago

Tobias-Fischer commented 10 years ago

Hi,

I encountered this problem earlier and was not able to find the source of the following issue. When modeling color, the gain control projection is created between the wrong sheets. The weird thing is that the correct sheet is shown when investigating the projections of an individual sheet, but the wrong sheet is used when looping through the sheets as in e.g. summary() or call().

./topographica -p dims=[\'xy\',\'or\',\'od\',\'dy\',\'sf\',\'cr\'] -p sf_channels=3 -p gain_control_SF=False -i examples/gcal.ty topo_t000000.00_c1>>> x = topo.sim.model.setup() topo_t000000.00_c2>>> x.projections.RightLGNOffRedGreenBlueRedGreenBlue.LateralGCLeft Out[2]:ProjectionSpec(SharedWeightCFProjection, SheetSpec(SettlingCFSheet, {'eye':'Left', 'level':'LGN', 'polarity':'Off', 'opponent':'RedGreenBlue', 'surround':'RedGreenBlue'}), SheetSpec(SettlingCFSheet, {'eye':'Right', 'level':'LGN', 'polarity':'Off', 'opponent':'RedGreenBlue', 'surround':'RedGreenBlue'}))

topo_t000000.00_c4>>> x.summary() .... RightLGNOffRedGreen : SettlingCFSheet RightLGNOffRedGreen.AfferentCenter0 [RightRetina -> RightLGNOffRedGreen] : SharedWeightCFProjection RightLGNOffRedGreen.AfferentSurround1 [RightRetina -> RightLGNOffRedGreen] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentCenter0 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentCenter1 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentCenter2 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentSurround0 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentSurround1 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.AfferentSurround2 [RightRetina -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.LateralGCLeft [LeftLGNOff2 -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection RightLGNOffRedGreenBlueRedGreenBlue.LateralGCRight [RightLGNOff2 -> RightLGNOffRedGreenBlueRedGreenBlue] : SharedWeightCFProjection ....

topo_t000000.00_c5>>> x.projections.RightLGNOffRedGreen. x.projections.RightLGNOffRedGreen.AfferentCenter0 x.projections.RightLGNOffRedGreen.get x.projections.RightLGNOffRedGreen.parent x.projections.RightLGNOffRedGreen.AfferentSurround1 x.projections.RightLGNOffRedGreen.grid x.projections.RightLGNOffRedGreen.path_items x.projections.RightLGNOffRedGreen.children x.projections.RightLGNOffRedGreen.keys x.projections.RightLGNOffRedGreen.pop x.projections.RightLGNOffRedGreen.filter x.projections.RightLGNOffRedGreen.label x.projections.RightLGNOffRedGreen.set_path x.projections.RightLGNOffRedGreen.fixed x.projections.RightLGNOffRedGreen.merge x.projections.RightLGNOffRedGreen.update

As you can see, when viewing the individual projections (last command), RightLGNOffRedGreen does not have any gain control projections. However, in the overview somehow the gain control projections which are related to RightLGNOffRedGreenBlueRedGreenBlue show up in RightLGNOffRedGreen.

jbednar commented 10 years ago

Can you give more details or a recipe for recreating this? From that description I can't tell when the problem would be encountered, or how I would know I have it.

Tobias-Fischer commented 10 years ago

Sorry, I clicked too fast on comment. Please see my updated comment above. A hack to get the correct projections is as follows (which I used in my thesis as well):

-        topo.sim.connect(str(self.src),str(self.dest),
+        if(str(self.src).endswith('RedGreen') and \
+            (str(self.dest).endswith('RedGreenBlueRedGreenBlue') or str(self.dest).endswith('2') or str(self.dest).endswith('3'))):
+            print 'Special connect'
+            topo.sim.connect(str(self.src)+'BlueRedGreenBlue',str(self.dest),
                          self.projection_type,
                          **self.parameters)
+        else: 
+            topo.sim.connect(str(self.src),str(self.dest),
+                             self.projection_type,
+                             **self.parameters)

In topo/submodel/specifications.py

jlstevens commented 10 years ago

I am not following. Is this an issue with the submodel system in general, the particular model definition used or something else in Topographica?

Tobias-Fischer commented 10 years ago

I have really no idea where this annoying bug comes from. I spent a couple of hours on this while working on my thesis and still have no idea what is going wrong at which place in the code. It is really confusing and hard to debug, as everything is fine when looking at the individual projections. As soon as a for loop comes into play, the above mentioned mix up between RedGreenBlueRedGreenBlue and RedGreen happens. Therefore I don't think it's a mistake in the matching conditions. Maybe somewhere a getitem or similar function changes by mistake the source/dest sheets of a projection by not looking at the whole string but only a substring? This is an annoying bug, but fortunately only happens with color simulations. Sorry that I can't give any detailed information about that.

Tobias-Fischer commented 10 years ago

I found the error and suggested a fix in https://github.com/ioam/topographica/pull/589. As soon as this PR it merged, this issue can be closed.

jbednar commented 10 years ago

Thanks, Tobias! That saved us tons of headaches and debugging!