Notions on addressing of LMs, "input ports", etc

Research and Theory
1

IMHO, Monty will need a convenient, logical, and neuroscience-grounded way to address messages to specific LMs, including input ports, message semantics, etc. (A rough biological equivalent of this, AIUI, is specifying a synapse for a dendrite type at a cortical level.)

In Monty, I’d expect an actor framework to handle addressing to the level of processes (e.g., LMs). Each LM would then perform pattern-based message dispatching, based on a variety of characteristics, e.g.:

  • level within the cortical column
  • transmission power and speed
  • type of the receiving dendrite
  • …

In Erlang and Elixir, the BEAM manages the details of message handling (e.g., addressing, transmission, routing, queuing, dispatching). In particular, addressing is based on “nodes” (BEAM instances) and process IDs (i.e., PIDs).

This works, for some value of “work”, but PIDs aren’t particularly self-documenting, let alone obvious or transparent. When I asked ChatGPT about this, it replied with a few suggestions, e.g.:

  • slash-separated path names, akin to URI formats
    (e.g., “region/column/level/port”).
  • key-value encoding for characteristics
  • map-based data structures containing characteristics

The path name / URI approach offers familiarity, flexibility, and simplicity. However, it doesn’t deal well with location-independent characteristics such as sensitivity, speed, etc.

So, my suspicion is that we’ll want to use slash-separated path names for things like “region/column/level/port” and relegate location-independent characteristics to a routing data structure. Comment?

2

I continued my conversation with ChatGPT, exploring ideas like using wildcards in address paths and using the Phoenix web server framework to handle dispatching within each LM. The responses contained a lot of interesting ideas, most of which seem quite plausible…

3

@jhawkins describes the (unfolded) cortex as being the size of a large dinner napkin. In an effort to handle some addressing issues, I’d like to follow this description in a new (and quite possibly naive) direction…

Each cortical column exchanges nerve impulses with many other columns. Most of these are nearby (in the cortex), but some are distant. To simulate this behavior, each of Monty’s modules will need to handle large numbers of addresses. Although these could be kept in a lookup table, this would result in both space and time inefficiencies.

To avoid this problem, I’d suggest laying out Monty’s modules as a 2D array. Each target module’s address would be specified by a pair of integer indexes which could be generated arithmetically at need. So, they wouldn’t need to be retained.

On a (loosely) related note, cortical regions and sub-regions could be allocated as sub-arrays, then displayed using a treemap.

4

Watching @vclay’s presentation on A Solution for Behavior in the Cortex, I was impressed by her detailing of possible data paths to and from each cortical column. However, the diagrams and discussion did not get into any explicit terminology.

Could anyone present a list of data paths, with brief descriptions and suitable nomenclature (e.g., for the cortical levels and input and output ports involved)?