Bayle Shanks's website: work-storage-presentations-qualsJC-routingPostscript

\documentclass{seminar}

Summary of some stuff I remember from our discussion of routing in the brain

by Bayle Shanks

\begin{center}

Q: What happens in your brain when I say

"When you see the blue light, press the green button"

?

%%\Huge{\begin{equation*}\downarrow\end{equation*} } %%\begin{ugraph} %%"?" [fontsize=15 width=.2 height=.2 margin=0] %%\end{ugraph}

\begin{ugraph} size="1.7,1.7" node [width=0.2 height=0.2 style=filled fillcolor=lightgray] 1;2;3;4 [fillcolor=blue];5;6;7;8;9;10;11 ;12 [fillcolor=green]

12--9;12--11;1--6;8--9;4--5;6--8;9--6;2--8;9--1;3--7;4--5;9--1;4--3;5--2;2--9;2--1;3--2;3--4;4--6;7--5;6--5;3--10;10--9;7--10;11--1;11--3 \end{ugraph}

\end{center}

Disagreements with architectural assumptions

Erik: You're presupposing that there are little, spatially separated modules for each separate semantic concept. i think it is more like this: there are ~15-50 large spatially separated modules each encompassing an architectural feature like "probablistic state of the world monitor", "goal keeper", and "reward/goal calculator". In this case the topology of the connections between these modules can be static. Within each module, the separate "concepts" may be just separate symbols in a neural code.

The "central switchboard" (Shantanu) model

\begin{graph} size="2.7,2.7" center [height=2 width=2 label=$\downarrow\downarrow\downarrow$] selectorIn [shape=diamond color=blue] selectorOut [shape=diamond color=blue] "Stimulus 1" [shape=box] "Stimulus 2" [shape=box] "Stimulus 3" [shape=box] "Stimulus 4" [shape=box] "Stimulus 5" [shape=box] "Response 1" [shape=box] "Response 2" [shape=box] "Response 3" [shape=box] "Response 4" [shape=box] "Response 5" [shape=box] is1 [label="" height=.1 width=.1] is2 [label="" height=.1 width=.1] is3 [label="" height=.1 width=.1] is4 [label="" height=.1 width=.1] is5 [label="" height=.1 width=.1] ir1 [label="" height=.1 width=.1] ir2 [label="" height=.1 width=.1] ir3 [label="" height=.1 width=.1] ir4 [label="" height=.1 width=.1] ir5 [label="" height=.1 width=.1] "Stimulus 1" -> is1 [arrowhead="none"] ; is1 -> center "Stimulus 2" -> is2 [arrowhead="none"] ; is2 -> center "Stimulus 3" -> is3 [arrowhead="none"] ; is3 -> center "Stimulus 4" -> is4 [arrowhead="none"] ; is4 -> center "Stimulus 5" -> is5 [arrowhead="none"] ; is5 -> center center -> ir1 [arrowhead="none"] ; ir1 -> "Response 1" center -> ir2 [arrowhead="none"] ; ir2 -> "Response 2" center -> ir3 [arrowhead="none"] ; ir3 -> "Response 3" center -> ir4 [arrowhead="none"] ; ir4 -> "Response 4" center -> ir5 [arrowhead="none"] ; ir5 -> "Response 5" selectorIn -> is1 selectorIn -> is2 selectorIn -> is3 selectorIn -> is4 selectorIn -> is5 selectorOut -> ir1 selectorOut -> ir2 selectorOut -> ir3 selectorOut -> ir4 selectorOut -> ir5 \end{graph}

All possible stimuli and all possible responses are connected to a single central structure. The central structure propagates any input it receives to all outputs. However, the "selector"s, in conjunction with diffuse neuromodulators, excite or inhibit the paths to and from the central structure, ensuring that at any one time, only one input path and one output path is uninhibited.

The switchboard model for multiple concurrent s-r pairings

Just have multiple central nodes/selector structures\footnote{Shantanu, Jyoti}:

\begin{graph} size="3.2,3.2" center1 [height=2 width=2 label=$\downarrow\downarrow\downarrow$] center2 [height=2 width=2 label=$\downarrow\downarrow\downarrow$]

selectorIn1 [shape=diamond color=blue] selectorOut1 [shape=diamond color=blue] selectorIn2 [shape=diamond color=blue] selectorOut2 [shape=diamond color=blue]

 {"Stimulus 1" [shape=box] "Stimulus 2" [shape=box] "Stimulus 3" [shape=box] "Stimulus 4" [shape=box]

 rank=same;}

 {"Response 1" [shape=box] "Response 2" [shape=box] "Response 3" [shape=box] "Response 4" [shape=box] rank=same; }

is11 [label="" height=.1 width=.1] is12 [label="" height=.1 width=.1] is13 [label="" height=.1 width=.1] is14 [label="" height=.1 width=.1] ir11 [label="" height=.1 width=.1] ir12 [label="" height=.1 width=.1] ir13 [label="" height=.1 width=.1] ir14 [label="" height=.1 width=.1] is21 [label="" height=.1 width=.1] is22 [label="" height=.1 width=.1] is23 [label="" height=.1 width=.1] is24 [label="" height=.1 width=.1] ir21 [label="" height=.1 width=.1] ir22 [label="" height=.1 width=.1] ir23 [label="" height=.1 width=.1] ir24 [label="" height=.1 width=.1] "Stimulus 1" -> is11 [arrowhead="none" color=red] ; is11 -> center1 [color=red] "Stimulus 2" -> is12 [arrowhead="none"] ; is12 -> center1 "Stimulus 3" -> is13 [arrowhead="none"] ; is13 -> center1 "Stimulus 4" -> is14 [arrowhead="none"] ; is14 -> center1 center1 -> ir11 [arrowhead="none"] ; ir11 -> "Response 1" center1 -> ir12 [arrowhead="none"] ; ir12 -> "Response 2" center1 -> ir13 [arrowhead="none" color=red] ; ir13 -> "Response 3" [color=red] center1 -> ir14 [arrowhead="none"] ; ir14 -> "Response 4" "Stimulus 1" -> is21 [arrowhead="none"] ; is21 -> center2 "Stimulus 2" -> is22 [arrowhead="none" color=red] ; is22 -> center2 [color=red] "Stimulus 3" -> is23 [arrowhead="none"] ; is23 -> center2 "Stimulus 4" -> is24 [arrowhead="none"] ; is24 -> center2 center2 -> ir21 [arrowhead="none"] ; ir21 -> "Response 1" center2 -> ir22 [arrowhead="none"] ; ir22 -> "Response 2" center2 -> ir23 [arrowhead="none"] ; ir23 -> "Response 3" center2 -> ir24 [arrowhead="none" color=red] ; ir24 -> "Response 4" [color=red] selectorIn1 -> is11 [color=orange] selectorIn1 -> is12 selectorIn1 -> is13 selectorIn1 -> is14 selectorOut1 -> ir11 selectorOut1 -> ir12 selectorOut1 -> ir13 [color=orange] selectorOut1 -> ir14 selectorIn2 -> is21 selectorIn2 -> is22 [color=orange] selectorIn2 -> is23 selectorIn2 -> is24 selectorOut2 -> ir21 selectorOut2 -> ir22 selectorOut2 -> ir23 selectorOut2 -> ir24 [color=orange] \end{graph}

In this example, stimulus 1 will trigger response 3, and stimulus 2 will trigger response 4.

The switchboard model for multiple concurrent s-r pairings

Also, you can have different sorts of systems coexisting\footnote{Jyoti, Philip} (for example, you could have this thing for 7+-2 conscious actions, and then have a bunch of reflex actions using some other system; this would explain how you could have lots of reflexes ready to go at any given time )

Possible anatomical locations of a central switchboard

Basal ganglia\footnote{Shantanu}
Amygdala \footnote{Justin}
Hippocampus\footnote{okay, i didn't say this in the discussion, but it was later in my slides -- not to say that i believe in a central switchboard}

Bayle's complain about high fan-out

Bayle: i don't like the high fan-out of the selector node

Jyoti: Remember, these connections might not be representing physical axons; they might be representing some computation inside a phase code or something

Bayle: hmmm, it seems that a high fan-out would still imply SOME pressure on some resource; for instance, if you have a phase coded signal representing a billion-way choice, then the system has to set the phase of the signal with a billion-fold precision, which isn't feasible

(note later: however, without specifying the neural code it's impossible to know if this sort of thing is really a problem. for example, by using a digital system of numeric representation, we can code a billion-fold choice in only 30 bits, which is about 4 bytes)

Philip's other idea for reflexes

Let's say there is some sort of routing. Maybe with practice, an often-used pathway gets re-routed to a shorter path:

Initial path upon learning task: \begin{ugraph} size="1,1"; [node label="" height=.1 width=.1] a b c d e f a--b [weight=100] b--c [weight=100] a--d [color=red] d--e [color=red] e--c [color=red] a--f [weight=100] f--c [weight=100] \end{ugraph}

Path later, after much practice: \begin{ugraph} size="1,1"; [node label="" height=.1 width=.1] a b c d e f a--b [weight=100] b--c [weight=100] a--d d--e e--c a--f [weight=100] [color=red] f--c [weight=100] [color=red] \end{ugraph}

Composition of modules?

Philip: But in this system, how can you compose simpler subroutines into complex ones?

For example, what if you want to press the green button when an even number of lights come on?

Now the output from the "blue light detector" and "orange light detector", etc, must be fed into an even/odd module, the result of which must be connected to the motor programs.

Bayle (later, with Ben): If you add the ability to do composition to this system, then you essentially have to do routing. At each stage of the computation, you could have a system like the following:

"Press green button when an even # of lights come on"

\begin{graph} size="3.1,3.1"

{ center1 [height=2 width=2 label=$\downarrow\downarrow\downarrow$] center2 [height=2 width=2 label=$\downarrow\downarrow\downarrow$]

 rank=same}

{ selectorIn1 [shape=diamond color=blue] selectorOut1 [shape=diamond color=blue] selectorIn2 [shape=diamond color=blue] selectorOut2 [shape=diamond color=blue]

 rank=source;}

 {"orange light" [shape=box] "yellow light" [shape=box] "blue light" [shape=box]

 rank=same;}

"odd/even detector" [shape=box]

 {"press red button" [shape=box] "press green button" [shape=box] rank=same; }

is11 [label="" height=.1 width=.1] is12 [label="" height=.1 width=.1] is13 [label="" height=.1 width=.1] is14 [label="" height=.1 width=.1] ir11 [label="" height=.1 width=.1] ir12 [label="" height=.1 width=.1] ir13 [label="" height=.1 width=.1] is21 [label="" height=.1 width=.1] is22 [label="" height=.1 width=.1] is23 [label="" height=.1 width=.1] is24 [label="" height=.1 width=.1] ir21 [label="" height=.1 width=.1] ir22 [label="" height=.1 width=.1] ir23 [label="" height=.1 width=.1] "orange light" -> is11 [arrowhead="none" color=red] ; is11 -> center1:n [color=red] "yellow light" -> is12 [arrowhead="none" color=red] ; is12 -> center1:n [color=red] "blue light" -> is13 [arrowhead="none" color=red] ; is13 -> center1:n [color=red] "odd/even detector" -> is14 [arrowhead="none"] ; is14 -> center1:n center1:s -> ir11 [arrowhead="none"] ; ir11 -> "press red button" center1:s -> ir12 [arrowhead="none"] ; ir12 -> "press green button" center1:s -> ir13 [arrowhead="none" color=red] ; ir13 -> "odd/even detector" [color=red] "orange light" -> is21 [arrowhead="none"] ; is21 -> center2:n "yellow light" -> is22 [arrowhead="none"] ; is22 -> center2:n "blue light" -> is23 [arrowhead="none"] ; is23 -> center2:n "odd/even detector" -> is24 [arrowhead="none" color=red] ; is24 -> center2:n [color=red] center2:s -> ir21 [arrowhead="none"] ; ir21 -> "press red button" center2:s -> ir22 [arrowhead="none" color=red] ; ir22 -> "press green button" [color=red] center2:s -> ir23 [arrowhead="none"] ; ir23 -> "odd/even detector" selectorIn1 -> is11 [color=orange] selectorIn1 -> is12 [color=orange] selectorIn1 -> is13 [color=orange] selectorIn1 -> is14 selectorOut1 -> ir11 selectorOut1 -> ir12 selectorOut1 -> ir13 [color=orange] selectorIn2 -> is21 selectorIn2 -> is22 selectorIn2 -> is23 selectorIn2 -> is24 [color=orange] selectorOut2 -> ir21 selectorOut2 -> ir22 [color=orange] selectorOut2 -> ir23 \end{graph}

\scriptsize{as before, red means a selected path: orange means that a selector is enabling a path}

"Press green button when an even # of lights come on" cont'd

In this circuit, both of the two central switchboards have the same connectivity:

Inputs:

all light detectors
the output of the odd/even detector

Outputs:

all motor programs
odd/even detector

"Press green button when an even # of lights come on" cont'd

The settings of the "selector"s, which enable specific pathways, make all the difference. SelectorIn?1 enables the pathways from the light detectors, SelectorOut?1 enables the pathway to the odd/even detector, SelectorIn?2 enables the pathway from the odd/even detecor, and SelectorOut?2 enables the pathway to the green button pusher.

"Press green button when an even # of lights come on" cont'd

Now, though, imagine what this system looks like scaled up a little:

\begin{graph} size="3.1,3.1"

{ A [shape=diamond height=2 width=2] B [shape=diamond height=2 width=2 ] C [shape=diamond height=2 width=2 ] D [shape=diamond height=2 width=2 ] E [shape=diamond height=2 width=2 ]

 rank=same}

 {"orange light" [shape=box] "yellow light" [shape=box] "blue light" [shape=box] oein [shape=box label="odd/even detector"]

 rank=same;}

 {"press red button" [shape=box] "press green button" [shape=box] oeout  [shape=box label="odd/even detector"]

 rank=same;}

"orange light" -> A:n [color=red style=bold] "yellow light" -> A:n [color=red style=bold] "blue light" -> A:n [color=red style=bold] oein -> A:n A:s -> "press red button" A:s -> "press green button" A:s -> oeout [color=red style=bold] "orange light" -> B:n "yellow light" -> B:n "blue light" -> B:n oein -> B:n B:s -> "press red button" B:s -> "press green button" B:s -> oeout "orange light" -> C:n "yellow light" -> C:n "blue light" -> C:n oein -> C:n C:s -> "press red button" C:s -> "press green button" C:s -> oeout "orange light" -> D:n "yellow light" -> D:n "blue light" -> D:n oein -> D:n [color=red style=bold] D:s -> "press red button" D:s -> "press green button" [color=red style=bold] D:s -> oeout "orange light" -> E:n "yellow light" -> E:n "blue light" -> E:n oein -> E:n E:s -> "press red button" E:s -> "press green button" E:s -> oeout \end{graph}

Each of the diamonds here represents an entire central node/selector structure (which I'll call a "switch"). For readability, I've put "odd/even detector" in two places (at the top, but also at the bottom) even though it's really just one module wih both and input and an output.

"Press green button when an even # of lights come on" cont'd

In the above picture, switch A receives the inputs from the lights, and sends them to the odd/even detector. Switch D receives the output of the odd/even detector, and triggers the "push green button" motor subprogram.

The "selectors" are hidden inside the diamonds, but just as before, they are the key components which open up the red paths, and shut off the other paths.

"Press green button when an even # of lights come on" cont'd

But how do the selectors know what to do? There has to be some coordination between them.

One assumes that there is some other component, "outside" the ones pictured here, which "programs" the selectors; i'll call this component the "selector controller". The selector controller receives from somewhere a description of the desired chain of computation (e.g. something like "send the output from the light sensors to the odd/even detector. Send the output of the odd/even detector to the "press green button" motor program" \footnote{it is difficult to imagine how this request could be coded, but we'll put that aside for now}). Based on this description, the selector controller tells each selector what to select:

\begin{graph} size="3.1,3.1"

{ A [shape=diamond height=2 width=2] B [shape=diamond height=2 width=2 ] C [shape=diamond height=2 width=2 ] D [shape=diamond height=2 width=2 ] E [shape=diamond height=2 width=2 ]

 rank=same}

"selector controller" [height=1 width=1 color=blue] "selector controller" -> A [color=orange] "selector controller" -> B [color=orange] "selector controller" -> C [color=orange] "selector controller" -> D [color=orange] "selector controller" -> E [color=orange]

 {"orange light" [shape=box] "yellow light" [shape=box] "blue light" [shape=box] oein [shape=box label="odd/even detector"]

 rank=same;}

 {"press red button" [shape=box] "press green button" [shape=box] oeout  [shape=box label="odd/even detector"]

 rank=same;}

And this leads to a problem. The selector controller must have a way to tell A's output selector to select the odd/even detector. It must have a way to tell D's input selector to select the odd/even detector. How can it do that?

How does the selector controller communicate with the selectors?

One way it might happen is to have a certain pattern of spikes\footnote{i.e. a symbol in a language} that means "odd/even detector". It sends that pattern to A's output selector and also to D's input selector. This is easy enough for the selector controller, but it means that we must somehow have a standardized language that all of the switches know. This is absolute addressing, and it seems infeasible.

How does the selector controller communicate with the selectors? cont'd

Another way would be for each switch to have it's own "language". This means that the selector controller sends one pattern to A's output selector, and sends a different pattern to D's input selector. But the controller has to know that both of these different patterns refer to the same module. Therefore, the controller has to have a huge translation table that allows it to translate between all the "languages" spoken by each selector. This seems like an infeasibly large undertaking.

How does the selector controller communicate with the selectors? cont'd

A third way would be for the controller to communicate with the selectors via labeled lines, one line for each desired path. But since the controller must know which line activates which path, this is similar to the previous situation; we have just replaced "patterns" with "lines". So we still have the task of building an enormous translation table inside the controller, so that it knows that line 1253 of switch A goes to the odd/even detector, and line 0771 of switch D goes to the same place.

Composition of modules, conclusion

So, it seems that composing modules via switches forces us to do something very complex in order to properly coordinate the instructions gives to the selectors inside each switch.

This problem is essentially similar to routing; instead of routing directly between the modules, the "selector controller" is routing a signal path through the switches.

So, while it is possible that routing is implemented in this way, having switches would not remove the necessity of routing in the brain.

(Bayle's opinion: in addition, it seems likely to me that the complexity of the task assigned to the monolithic "selector controller" in this architecture demonstrates the need for a more decentralized solution.)