What is this all about, cont'd?



  • Copyright © 2020, Kevin Dowd

    Dynamic Concepts

    A dynamic concept is one that is created at runtime. Dynamic concepts are used for names and addresses. Below, we see the creation of "rover"--the name of a dog.

      >> my dog's name is rover.
       your rover dog belonging to You is rover.
      >> break
    
       Break in debug at the start:
       debug> list rover
       Meme: default
         (context text) rover->rover-15099 (dynamic_recorded), MID 10000
    

    Because dynamic concepts are not sourced from the vocabulary, their labels (like "rover") have to be stored along with any save sets that reference them.

    Hash Tables

    Hash tables are a mechanism that aid in the storage and retrieval of data. The simplest form of hash table is a direct hash--a fixed collection of slots numbered from 0 to N-1. To use the hash table, one generates a number from 0 to N-1 as an index into the table. The index chooses the slot. The slot contains something of value.

    For illustration, imagine an old hotel with a wall of of wooden box-slots behind the front desk. The slots contain room keys. There is one slot per room. If you have the room number, you can check the slot for the room key. The room number is the index. The room key is something of value to be found in the slot.

    Now, suppose that there are many more rooms in the hotel then there are boxes. One would have to share box-slots between rooms. In order to map M rooms onto N hash table slots, one could create an index that is equal to '(room number) modulo N.' In this case, the same hash slot will be used for room 1, room 1+N, room 1+2N, and so on. If the hash table is built to accommodate multiple data sets, then overloading a hash slot won't replace the information within it when new data are stored. Rather, a slot will accumulate additional stored data and grow.

                 o
                /|\
       SUBJECT / | \ OBJECT
              /  |  \
       dog (100) |   bone (tag value = 200)
                 |
                 | VERB
                 |
              to chew (tag value = 101)
    

    Hash tables and slots are a mechanism that Brainhat uses to store and retrieve CCs. We can use hashes because individual concepts are associated with tag values. The concepts for "dog," "to chew" and "bone" might have tag values 100, 101 and 200, respectively, for example. These can be combined to create a hash for the CC that represents "dog chews bone." A simple hash would be the sum of all of the values, such as 100+101+200 = 401. To store or retrieve the CC associated with "dog chews bone", one locates a hash table slot associated with the number 401 and finds a reference to "dog chews bone." This could be used in other ways, too; we might ask "does the dog chew a bone?" The hash would again be 401.

    Unrelated CCs can yield the same hash value. This will cause them to share a slot. Overloading is permitted; many CCs can share a single slot. Hash slots include extra information to verify that a "hit" matches the values that created the hash. By this, the hash table becomes the long-term directory for locating CCs and searching for knowledge.

    Hash Vines

    Guided by the hierarchical organization of the vocabulary, Brainhat can recognize a CC containing specific knowledge to be the child of a CC containing abstract knowledge. It is useful for answering questions, invoking inferences and restoring memories. For example, "pet chews bone," "pet action bone", "animal chews thing", "thing action thing" are all abstract cases of "dog chews bone." Any of these abstractions can hash to find "dog chews bone." Therefore, we can ask Brainhat "does an animal chew something?" and the answer is yes; a dog chews a bone.

        >> a dog chews a bone
         a dog chews a bone.
        >> break
    
        Break in debug at the start:
        debug> eval animal chews something
         animal chews thing.
        "True"
        debug> cont
    
        >> does an animal chew something?
         yes. a dog chews a bone.
    

    The vocabulary parents of concepts "dog", "to chew" and "bone" create the hashes. Brainhat gathers each concepts' parents into a linear list. Say, for illustration, that the parents for hash variable "dog" include "pet", "animal" and "thing." The parents for "bone" might be "body part" and "thing." "Chew" might simply be classified as an "action." Given all the parents, we can place them side-by-side:

          hash     hash      hash
          var 1    var 2     var 3
      ---------- | ------- | -----------
          thing    action    thing
          animal   chews     body part
          pet        :       bone
          dog        :        :
           :         :        :
    

    In Brainhat parlance, the ordered sets of concepts are called "hash vines" by virtue of the way they hang down from least-specific to most-specific, and by the way the code climbs them: hash searches are bottom-up and breadth-first, meaning that more-specific matches are favored over less-specific. The code reaches the more specific hashes first, like a gorilla climbing a set of vines. Moreover, by the way they are traversed, hash vines can support "occlusion" such that more-specific hashes are reached before less-specific hashes, and thus will take precedence in a search. An example of where this can apply: "Animals like water" is the generalization. "Cats do not like water" is more specific. Thus, a search for "do cats like water? (no)" may locate a match before "animals like water (yes)."

    Memories

    Earlier, as we were looking at how to program a dog, we considered a simple sequence of statements as a description of what a dog will do when the mailman comes. You could visualize the behavior of the dog because you have worldly experience. Brainhat has no experience with dogs and the things that dogs do. In order to approximate an understanding of a dog, Brainhat has to learn about dogs. It does this by reading programs about dogs. As Brainhat reads, it collects, stores, indexes and groups dog knowledge (CCs) into neighborhoods. These neighborhoods are called memories. Memories are saved into a backing store (disks, databases or other instances of Brainhat acting as memory-servers) in bunches.

    The indexes used to store and retrieve memories are called triggers. They are organized and accessed with hash vines. At runtime, the presence of one or more triggers may cause Brainhat to restore a memory. Hearing the mailman and running to the door could resurrect a recollection of barking, for example.

    Considered as data, a memory is a short string of CC data structures, fetched in the order in which they were stored. Here are three CCs in the memory that contains: "I hear the mailman," "I bark" and "I run to the door." The three CCs are a snippet of the running context, recorded and indexed for retrieval at some later time.

             Root               Root               Root
              o------------------o------------------o
        SUBJ /|\                /|                 /|\
            / | \ OBJECT       / |           SUBJ / | \ ADVERB
           o  |  o            /  | VERB          o  |  o
         I    |  mailman     /   o              I   |  to door
              |             /      bark             |
         VERB |            / SUBJ             VERB  |
              o hear      /                         o run
                         o
    

    Here's an illustration of (layer 3) memories at work. This first block of code is the input to Brainhat that is used to create a memory:

        the weather was beautiful
        the sun was shining
        i walked on the beach
        i lost my dog
    

    Memories are stored in binary fashion to a backing store, such as file, database or other copy of Brainhat. A subsequent session may access these memories. The following is a demonstration of the retrieval of the memory above in a subsequent Brainhat session:

      >> i walked on the beach
       You did walk on the beach.
      >> the sun was shining
       the shining sun was shining.
      >> did i lose something?
       yes. You did lose your dog.
    

    The conditions that invoke a memory needn't exactly match the triggers that stored it. A subset of triggers may be sufficient. Nor do they have to appear in order. General memories may be invoked by more specific triggers; a memory involving house pets may be resurrected in conjunction with a trigger that refers to a cat or dog, for example (see "hash vines", above). Brainhat will attempt to substitute the specific concepts that trigger a memory into the abstract concepts it may contain; "cat" may be substituted to replace "house pet" in the restored memory, for example.

    Because runtime memory triggers are found in the context, a restored memory will likely contain some CCs that duplicate elements of the context that triggered it. A memory will often also contain some CCs that are not already resident in the context. It is this extra knowledge that provides expectation for what might come next, such as "I lost my dog" in the example above. Multiple memories can be restored simulataneously. Unrelated memories can combine. By this, Brainhat can generate fresh observations under novel conditions. The illusion of intuition occurs when conditions cause Brainhat to resurrect old memories and apply them to new situations and new actors.

    Orthogonality is an important tool for maintaining coherence in memories. In cases where restoring a particular memory would create an orthogonality violation (causing the dog to be both inside the house and outside the house, for instance), the itinerant memory will be skipped--not restored.

    For the time they are relevant, memories are intertwined with the CCs of the recent context and with each other. The memory's constituent concepts (dog, weather, etc.) are merged with the dirty concepts of the current context. When a memory loses relevance, it is removed from the context. The dirty concepts (dog, weather, etc.) are rebuilt and stripped of the contributions from the retired memory. Though the memory may be removed, any newly generated knowledge derived from it will become part of the permanent context; it's ephemeral presence may have permanent effects.

    Memories have other uses, as well. When Brainhat is trying to derive the correct interpretation of user input, it may consult memories. If a particular interpretation, in combination with the context, invokes a memory, then Brainhat will favor that interpretation over other possibilities that do not. For instance, if we were to tell Brainhat

      "the dog sees the ball"
    

    memories about a dog and a ball (as a toy) are going to help Brainhat decide that this is a more likely interpretation than a dog watching a large gathering with dancing and an orchestra (another kind of ball).

    How are memories created? Memories come from regular language input, like the statements of the dog program or interactive banter about food. When instructed to do so, Brainhat will save snippets of the context from time-to-time, along with index information. Later, when similar input resembles the indexes (triggers), a saved memory will be restored. Creating or restoring memories doesn't interfere with other Brainhat processing. Accordingly, memory creation or restoration (or both) can be enabled during regular interaction to build even deeper memories.

    There are four categories of memories with the designations of "layer 1", "layer 2", "layer 3" and "layer 4". The difference between the designations are the thresholds to be met before a memory is eligible for restoration. Layer 1 is intended for memories that require no more than the mention of a pertinent concept as a condition of being restored. For instance, a memory about the sun--"the sun is bright", "the sun is in the sky", "the sun is round", "the weather is not raining"--can be safely resurrected whenever the sun is mentioned. Layer 4 memories, on the other hand, might concern specific situations, such as the presence of the mailman at the door, and be reserved for cases where multiple conditions match. The layers and thresholds are configurable. Their uses are up to the programmer.

    We spoke about the context, earlier. In case it's not clear: context and memories are not the same thing. The context provides Brainhat with a background against which to understand new input. Likening the context to a person's mind, the context is a collection of the things that Brainhat is presently concentrrating upon. Memories, on the other hand, are knowledge that is superimposed onto the context opportunistically, and usually temporarily. Memories are akin to notions that pop into one's head and later disappear.

    Brainhat Save Sets

    Save sets are used store memories, motives and whole-sessions. Via save sets, one can store the complete state of Brainhat today and resurrect it tomorrow. Save sets provide an avenue to serve Brainhat functionality from stateless servers; the clients can keep their own state.

    Save sets contain a configurable number of sections that can record context information, discourse buffer information, saved questions, dynamic concepts (created outside the vocabulary) and other sections. Save sets may rest in files, in a backing store or be traded between copies of Brainhat.

    Save sets are knowledge storage without the presence of language.

    Text Input

    Computation is motivated by changing conditions, such as a fact learned from another copy of Brainhat, some input from the programmer, a news feed update or input from an outside agent--a sensor or robot. Brainhat, running as a daemon, can listen to an arbitrary number of connections. Depending on how the connections are opened, Brainhat may expect simple English, a Brainhat save set or an exchange via Brainhat's robot API.

    In daemon mode, Brainhat listens for user connections on a TCP port. This port is used for interaction with humans, speech interfaces and a web sockets shim. Interactive connections will typically drop in and out of debug mode to exchange out of band data. Whether invoked as a daemon or interactively, Brainhat opens a default connection to interact with the programmer in simple English:

      >> i am happy
       You are happy.
      >> you are sad
       I am sad.
      >> how are you
       I am sad.
      >> how am i
       You are happy.
      >> my dog knows that his ball is in the water
       your dog knows dog's ball is in the water.
      >> what does the dog know?
       your dog knows dog's ball is in the water.
    

    Live interaction is a way for the programmer to motivate and test Brainhat computation. Live interaction is also convenient to simulate exchanges with outboard sensors or robots.

    Any input provided through the default interface is recorded verbatim and also is recorded as "speaker says..." [Foornote: the "speaker" is you, the person interacting with Brainhat]. Programs may react to command line propositions, such as "the ball is red" or with the derived fact that speaker input provided the proposition, e.g. "speaker says the ball is red."

    Robot Interface

    To connect with a sensor or robot, the programmer designates a concept as a robot and opens a connection to it:

    a robot's address is 192.168.0.100:300.
    the robot's name is freddy.
    

    This designates a robot and gives it a name. One can subsequentlyzdirect the robot in the imperative tense.

    >> tell freddy put the ball in the bin.
    

    The robot will receive a list of field/value pairs, delimited by a start and end statement.

    start
    tag=4839
    subject=freddy
    command=put
    object=ball
    color=red
    objprep=bin
    prep=in
    end
    

    The robot may respond with a status code and optional simple English message. A response of "Y" indicates that the action was completed:

    4839:Y
    

    A "N" means the action failed. An optional reason may be provided by the robot.

    4839:N:freddy does not have ball
    

    Robot interfaces are asynchronous. At any time, a robot may provide simple language input via its connection to the daemon.

    Outbound Text Connections

    A Brainhat daemon can open a text channel to external programs or to other copies of the daemon:

    a daemon's address is 192.168.0.101:4144.
    the daemon's name is freddy.
    tell freddy hello.
    

    In this example, the local copy of Brainhat will open a connection to a remote copy and send "hello." When the remote copy responds, it's response will be prepended with "freddy says" to create "freddy says hello" within the context. By this, the source of the input is identified and its value may be associated with the reputation of the source.

    A Brainhat daemon can open a text channel to external programs or to other copies of the daemon:

    a daemon's address is 192.168.0.101:4144.
    the daemon's name is freddy.
    tell freddy hello.
    

    In this example, the local copy of Brainhat will open a connection to a remote copy and send "hello." When the remote copy responds, it's response will be prepended with "freddy says" to create "freddy says hello" within the context. By this, the source of the input is identified and its value may be associated with the reputation of the source.

    Outbound Context/Memory-Sharing

    Brainhat can also open a channel for sharing Brainhat binary save sets. This is particularly useful for sending save sets that contain a portion of the immediate context in anticipation of receiving a remote Brainhat's memories in return.

    a memorybank's address is 192.168.0.102:4144.
    

    When a remote daemon connection is opened this way, the local copy of Brainhat will automatically share out sections of the context and receive remote memories in return. By this, a local copy of Brainhat may benefit from the experiences of remote copy of Brainhat.

    Unsolicited memories and updates may be received from remote copies of Brainhat while a connection is open.

    Motives

    Brainhat has a facility where applications may be crafted to pursue specific goals. Imagine, for example, that our dog is told by a camera-robot that it has detected a person's face. We might wish to exercise a decision tree that decides whether to growl or wag the dog's tail, depending on whether the face appears to be friendly. This goal-seeking facility is called Motives. Motives are hand-crafted, N-way branching, overlayed, restartable decision trees. Motives coexist with and combine with memories in order to affect context-dependent behavior.

    Each motive is a block of code initiated by a test. When the test evluates TRUE, the block gains focus and its contents execute. The contents of the motive are simple English statements.

        MotiveName: start
        Test:
        Contents:
        Branches: see-a-face, start
    
        MotiveName: see-a-face
        Test: you see a human face.
        Contents:
            you are afraid.
            tell body-robot crouch.
            tell vocal-robot growl.
            tell vision-robot analyze-face.
        Branches: friendly-face, unfriendly-face
    
        MotiveName: friendly-face
        Test: face is friendly.
        Contents:
            you are not afraid.
            you are happy.
            tell body-robot stand.
            tell body-robot wag-tail.
            tell vocal-robot happy-bark.
            reset friendly-face.
            reset see-a-face.
        Branches: see-a-face
    
        MotiveName: unfriendly-face
        Test: face is unfriendly.
        Contents:
            tell vocal-robot angry-bark.
        Branches:
    

    [footnote: The syntax shown is representative of the actual Brainhat syntax, and chosen for illustration.]

    The 'MotiveName' field provides a label for the block. This label can be used as a branch target from other blocks.

    The 'Test' is a condition that, when true, will cause the the motive block to gain focus.

    The 'Contents' are statements that execute when the block gains focus. The statements can be a mix of propositions, inference templates and imperatives.

    'Branches' nominate potential next blocks, making them standby-active.

    Once a block is active, its Test is armed and will remain that way until the block is reset or executed. Note that many blocks can be active-standby at any time. Focus may shift between blocks that are on separate paths. This makes it possible to pursue many sets of goals (and motive blocks) simultaneously.

    Motives interact with memories, causing memories to be restored and retired as a side-effect of the new information a motive may add to context. Unlike memories, however, the contribution of motives is permanent, and becomes part of the ongoing context.

    In the case where a motive becomes active, and where its contents will create an orthogonality conflict with the context, portions of the context may be graduated into the preterit. So, for example, if the context says "dog is inside the house" and a newly activated motive says "dog is outside the house", the motive wins and the context changes to say "the dog was inside the house."

    A Brainhat server may be invoked with a set of motives pre-activated. When clients connect, the motives will direct their interaction. Additionally, a client may provide its own motives and their state to a Brainhat server. By this, individual clients can persue their own goals on a generically-programmed Brainhat server platform.

    Belief Systems

    There are mode and debug flags in Brainhat that allow the programmer to modify Brainhat's interpretation and computation. One flag, "verbatim", controls whether speaker interaction is taken at face value. With the "verbatim" flag unset, input of a statement like "the ball is red" records only "speaker says the ball is red." Here is an example:

      >> debug unset verbatim
    
      >> if i say a thing is red then a thing is blue
       if You say a thing is red then a thing is blue.
      >> the ball is red
       the ball is red. a blue ball is blue.
      >> why
       a blue ball is blue because You say a blue ball is red.
    

    Debug

    The program includes extensive debug facilities.

        Commands:
        DEBUG symbol [ location] -or-
        BREAK symbol [ location] -or-
        SET symbol [ location]
          Increment debug count for routine/process/flag,
          and optionally stop at listed locations.
          "location" is one of {start, loc[1-3], finish, all}
    
        NODEBUG symbol -or-
        UNSET symbol
          Decrement debug count for routine/process/flag.
        CLEAR symboln  Zero the debug count for routine/process/flag.
        DUMP [n]
          Dump optional argument concept (if concept).
          Dump optional conchain (if conchain).
          "n" chooses conchain element.
        RDUMP [n]
          Dump recursively.
        LIST label
          Show all symbols matching label.
        WORDS
          Dump pre-prepared word list.
        LISTM
          Shows loaded motvs.
        SHIFTN number
          Shifts meme processing to motv N.
        SHIFT name
          Shifts motive processing to motv by name.
        STOP
          Stop.
        S[R]DUMP symbol
          Dump symbol from clean symbol table.
        C[R]DUMP symbol
          Dump symbol from context.
        M[R]DUMP symbol
          Dump symbol from MID symbol table.
        X[R]DUMP n
          Dump nth CC from context.
        D[R]DUMP n
          Dump nth CC from discourse buffer.
        Q[R]DUMP n
          Dump nth CC from questions buffer.
        SPEAK [n]
          Speak optional argument concept (if concept).
          Speak optional conchain (if conchain).
        CCSPEAK label
          Speak CC from context.
        XSPEAK [n]
          Speak nth context entry.
        DSPEAK [n]
          Speak nth discourse entry.
          "n" chooses conchain element.
        SQSPEAK/SQ[R]DUMP
          Speak/dump the saved question, if any.
        A[R]DUMP/SPEAK n
          Dump nth anaphor candidate.
        PARSE string.
          Parse and read back the input.
        EVAL string.
          Evaluate the truth value of the input.
        REDIR flag.
          Output debug for "flag" to stderr.  "Flag" may additionally
          be specified as "journal", in which case the journal output is
          redirected.
        STDERR ipaddr port.
          Send stderr to a socket waiting at ipaddr:port.
        ARGV
          Print out the argument vector for this Brainhat invokation.
    

    Graphical User Interfaces

    Brainhat has two limited use graphical interfaces:

    • A Windows-based interface provides a SAPI4 connection to speech engines.

    • A more comprehensive HTML5/websockets-based GUI is helpful for testing
      programming and vocabulary.


Log in to reply