Group Details Private

administrators

Member List

  • Quick QA results for 12/22/20

    These are the automated QA test results (click here) for 12/22/20.

    posted in QA and Release Info
  • Layer-2 memories

    Copyright © 2020, Kevin Dowd

    Layer-2 Explicit Inference Memories

    Whereas layer-1 memories are a collection of general propositions, equivalences and descriptions, layer-2 memories are inference templates, mostly.

    if a person is in the woods and the time is night then the person is afraid and the person is cold.

    Inferences can be entered on-the-fly, recalled in general memories or save-sets. What makes a layer-2 inference different is that it is not part of the context, not in memory and may not even be on the same computer. Rather, layer-2 inferences are found in a file, a database or perhaps in another copy of Brainhat.

    dowd@beast:~/brainhat$ ./brainhat -r memories/inthewoods.txt -2
    Starting new memory hash.
    

    Layer-2 inferences are resurrected when a new entry(s) in the context trigger a hash. So, for example, a file might contain the above inference template. Brainhat could learn that the there is a person in the woods. It might then learn that it is nighttime, too, at which point concepts are substituted into the inference and the inference fires.

    dowd@beast:~/brainhat$ ./brainhat -A +repeat
    
    >> mario is in the woods
     mario is in the forest.
    >> the time is night
     the time is night. cold mario in the forest is cold. he is afraid. afraid cold mario is cold. he is afraid.
    >> the princess is in the woods
     the princess is in the forest. she is cold. the cold princess in the forest is afraid.
    >> bye
    
    goodbye!
    
    

    patent pending

    posted in Tutorials
  • 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.

    patent pending

    posted in General Discussion
  • What is this all about?

    Copyright © 2020, Kevin Dowd

    What is this?

    We're going to program with knowledge. It's likely to be different than other kinds of programming you are familiar with. Most languages, like C or Python, are procedural, meaning that code executes in sequence.

        integer i,j,k
        string c
        j = 2
        k = 1
        i = j + k
        string = "here is the answer"
        print string, " ", i
        end
    

    Procedural code executes from the top to the bottom. It might also have flow control statements, like 'if' or 'while,' that cause branches. There may be subroutines an perhaps there's an event loop. The program may jump from place to place, but execution will always be somewhere within the code.

    Brainhat is dataflow programming, and dataflow programming is different. There are no flow control statements. There's no program, in regular sense. Rather, the data themselves direct execution.

    "the dog is hungry."
    

    Think of this statement as an assignment. It adds to the collection of things that are known.

    "if the dog is hungry then the dog wants to eat."
    

    This statement is executable; it becomes part of the program. When the two statements find each other, there will be side-effects, such as:

    "the dog wants the dog to eat."
    

    How do the statements find each other? They're hashed. When hashes match, Brainhat executes. This, in turn, can generate more hashes, knowledge and other side-effects. Hashing is the key to recalling memories, testing for the truth or existence of knowledge and for triggering inferences.

    Procedural programs are deterministic. But in Brainhat, where the programming can be modified by additional input, the answer can change. Moreover, two copies of Brainhat running side-by-side might provide different results. This is because all input is interpreted against a context, and contexts can differ. If you say "the dog is hungry," I will understand what you mean. But the resulting knowledge probably won't be the same as yours. That's because I understand "the dog is hungry" in my context, using my image of a dog and what a dog likes to eat. You understand it in your context. My dog might be brown; yours could be tan. If you had said "the tan dog is hungry," I would have had an entirely different understanding. My dog is brown. Ergo, you must be talking about a different dog. That's the tricky part, and the fun it all: human language makes knowledge portable, but it leaves out the details.

    Here's how "the dog wants the dog to eat" looks inside Brainhat:

                               o Root
                              /|\
                    SUBJECT  / | \
                            /  |  \
                           / VERB  \
                      dog o    |    \
                               |     \
                               o      \
                            to want    o Root
                                      /|
                                     / |
                                    /  |
                                   /   | VERB
                             SUBJECT   |
                                 /     |
                                o      o
                            dog      to eat
    
    

    This is a knowledge data structure (called a Complex Concept or CC). It's very much like a diagrammed sentence that you might have created in grammar school English. However, unlike a diagram or the variable j, this data can be modified by changes in the context around it. If we later learn that the dog is brown, this data structure changes too.

    It's not all chaos; there is a great deal of formal input processing for shaping input and interpreting it correctly. A number of post processing efforts seek to discover patterns in the context and to pro-actively recall memories and exercise inferences.

    Vocabulary

    To read human language, Brainhat has to recognize the tokens (words) and it has to make sense of their order. Tokens and order are prescribed by a vocabulary and a grammar. The vocabulary says what the tokens can be. The grammar says how they can be combined. The vocabulary and grammar create the possibilies for, and define the limits of, what Brainhat can understand.

    Brainhat's vocabulary is defined hierarchically. A poodle is a dog, a dog is a pet, a pet is an animal, and so on. Concepts for hamster, cat, dog and wildebeest are children (hierarchically) of the concept for animal. So, we may ask if a wildebeest is an animal and whether it shares some features in common with dogs, and the answer will be "yes." However, there is no upward path from wildebeest to pet. Therefore a wildebeest is not a pet.

    
                  o things          o actions          o adjectives
                 /|\               /|\                /|\
                / | \             / | \              / | \
               /  |  \           o  |  o to eat     o  |  \
              o   |   \      to be  |           happy  |    o pretty
       vegetable  |    \            o to sense         |
                  |     o          / \                 o color
                  |   mineral     /   \               / \
           animal o              o     \             /   \
                  |\       to hear     to see       o     o red
                  | \                           blue     / \
                  |  o wildebeest                       /   \
                  |                                    /     o
                  o pet                               /     pink
                 /|\                                 o
                / | \                             scarlet
               /  |  o cat
      hamster o   |
                  o dog
                  |
                  |
           poodle o
    
    

    A vocabulary definition appears below. This definition has multiple synonyms: "hot dog", "hot dogs" and the name "hotdog-1". To reference this definition, one could refer to it by any of the synonyms, e.g. "the dog ate a hot dog" or "the dog ate a hotdog." [footnote: You'll notice that we've grouped plural and singular forms together. This is not a requirement; the vocabulary can be built so that singular and plural are distinct. For the time-being, and for simplicity, we will work with combined forms.]

        define      hotdog-1
                    label           hot dogs
                    label           hot dog
                    label           hotdogs
                    label           hotdog
                    orthogonal      food-1
                    child-of        food-1
    

    When a word has two or more distinct meanings, there may be two or more definitions. For example, a ball is round, a ball has the quality of being a certain color, a "ball" is a toy. A "ball" might also be a formal dance, with an orchestra and glass slippers.

        define      ball-1
                    label           balls
                    label           ball
                    child-of        toy-1
                    wants           color-1
                    wants           size-1
                    related         round-1
                    related         play-1
                    wants           shape-1
    
        define      ball-2
                    label           balls
                    label           ball
                    child-of        party-1
                    related         loud-1
                    wants           volume-1
    

    To tell the two forms of ball apart, we may add hints to the definitions. If we say "the ball is red," chances are that we'll get the correct sense of the word "ball" because of the hint that says "ball-1 wants color-1". Once Brainhat has been processing for a while, reliance on hints in the vocabulary become less important. Instead, Brainhat will look to memories and context when trying to determine the sense of a word.

    Grammar

    Grammar defines how the vocabulary elements can be combined. Consider the statement: "I hear the mailman." The words "I" or "mailman" may play the part of a subject or object. The word "hear" can only take the part of a verb. Using a grammar rule like this, we can recognize "I hear the mailman":

    grammar_rule = subject + verb + object,
    

    Brainhat tags parts of speech--the subject, verb and object--and places them into a data structure that represents the statement. Once the knowledge is captured, the original statement is no longer needed.

                    o Root
                   /|\
         SUBJECT  / | \ OBJECT
                 o  |  \
                I   |   o mailman
                    |
               VERB |
                    o
                  to hear
    
    

    In Brainhat terminology, each of the vocabulary elements--"I", "to hear" and "mailman" is called a concept. Any combination of concepts is called a complex concept or CC. Compiling the statement "I hear the mailman" produces a CC data structure that resembles the diagram, above. A CC can be indexed, stored, recalled, compared and transformed:

       >> i hear the mailman
        You do hear the mailman.
       >> what do i hear?
        You do hear the mailman.
       >> do i hear the mailman?
        yes. You do hear the mailman.
       >> what do i do?
        You do ask do You hear the mailman.
    

    Orthogonality

    Returning to the definition of the concept hotdog-1: as a child of concept food-1, the concept hotdog-1 becomes part of a class that may include hamburgers, potato chips and chicken parmigiana, provided that they are also children of food-1.

        define  hotdog-1
                label           hot dogs
                label           hot dog
                label           hotdogs
                label           hotdog
                label           weiner
                orthogonal      food-1
                child-of        food-1
    
        define  hamburger-1
                label           burger
                label           haburger
                orthogonal      food-1
                child-of        food-1
    

    Hot dogs are food. Hamburgers are food. But hamburgers are not hotdogs. Indicating orthogonality makes it possible to tell them apart. The directive "orthogonal food-1" instructs Brainhat that hotdogs and hamburgers are exclusively different than other concepts that are also declared orthogonal to food-1 (or one of its parents).

       >> what are hotdogs?
        hotdog is food.
       >> are hotdogs hamburgers?
        no. hotdog is not hamburger.
    

    As orthogonality helps to differentiate objects, it applies to attributes, too. [Footnote: an ATTRIBUTE is an adjective or propositional phrase, typically, though it can be a binary large object (BLOB), too, such a thumbprint, picture or voice scan.] The "red dog" is not the "blue dog,"the "first dog" is not the "second dog", and the "dog in the restaurant" is not the "dog in the library."

       >> the first dog sees a cat
        the first dog sees a cat.
       >> the second dog sees a squirrel
        the second dog sees a squirrel.
       >> does the first dog see a squirrel?
        maybe. the second dog sees a squirrel.
    

    Orthogonality may apply to whole clauses playing the part of subject or object. For instance "the party at the beach" may be orthogonal to "the funeral for my uncle." Tests for orthogonality of more complex CCs like these may take place by semantic evaluation.

    Inheritance and Orthogonality and Truth

    Computing with knowledge, we need to be able to ask whether something is true or false, or whether we don't know the answer. Truth is important for steering processing, and invoking inferences and memories. Truth motivates computation.

    Brainhat's vocabulary is built of taxonomies. Every concept, except for the very top concepts, is the child of another. Some are the children of many. A toy is a thing; a ball is a toy. Inheritance is functionally broken, however, when orthogonality is detected. A blue ball is not a red toy, for example.

    Just as individual concepts can be the children of others, whole CCs (complex concepts, described above) can be the children other CCs. For one CC to be the child of another, the child CC must contain the same basic parts of speech as the parent. [Foornote: In Brainhat parlance, we say that two CCs have the same shape.] Furthermore, each of the child's constituent concepts, taken in pairwise comparison to the parent's, must be child concepts, or be the same.

    To take a few examples, the CC on the left is a proper child of the CC on the right. Each of the concepts in the left-hand CC is a child of each of the concepts on the right, and the two CCs have the same shape.

                Root                     Root
               o                        o
              /|\                      /|\
        SUBJ / | \ OBJ           SUBJ / | \ OBJ
            /  |  \                  /  |  \
           o   |   \                o   |   \
        dog  VERB   o ball     animal  VERB  o toy
               |                        |
               o                        o
             to see                  to sense
    

    The next two CCs do not have a child/parent relationship because they have different shapes. This is because links are different; OBJECT versus ATTRIBUTE. They also lack pairwise inheritance in all but the OBJECT.

                Root                     Root
               o                        o
              /|\                      /|\
        SUBJ / | \ OBJ           SUBJ / | \ ATTRIBUTE
            /  |  \                  /  |  \
           o   |   \                o   |   \
        dog  VERB   o ball     animal  VERB  o happy
               |                        |
               o                        o
             to see                  to be
    

    In this next comparison, the shape is the same. The corresponding concepts are identical. In fact, the CCs are identical. A concept can be a child of itself; the child/parent relationship is valid.

                Root                     Root
               o                        o
              /|\                      /|\
        SUBJ / | \ OBJ           SUBJ / | \ OBJ
            /  |  \                  /  |  \
           o   |   \                o   |   \
        dog  VERB   o ball       dog  VERB   o ball
               |                        |
               o                        o
             to see                  to see
    

    Next, we have two CCs that do not share a child/parent relationship because at least one of the constituent parts-of-speech is not a child of the other, even though they have the same shape.

                Root                     Root
               o                        o
              /|\                      /|\
        SUBJ / | \ OBJ           SUBJ / | \ OBJ
            /  |  \                  /  |  \
           o   |   \                o   |   \
        dog  VERB   o ball       dog  VERB   o ball
               |                        |
               o                        o
             to see                  to eat
    

    In this next example, the constituent concepts of "dog sees red ball" ("dog", "to see" and "ball") are all proper children of the corresponding concepts in the itinerant parent. The shape is the same, too. However, the concepts occupying the OBJECT positions are orthogonal because they bear orthogonal ATTRIBUTEs ("red" versus "blue"). Thus, even though each of the concepts that make up the two CCs have child/parent relationships, orthogonality between the concepts breaks the child/parent relationship between the CCs; when we test to see if the left-hand CC is a child of the right, the answer is NO.

                Root                     Root
               o                        o
              /|\                      /|\
        SUBJ / | \ OBJ           SUBJ / | \ OBJ
            /  |  \                  /  |  \
           o   |   \                o   |   \
        dog  VERB   o ball       dog  VERB   o toy
               |    |                   |    |
               o  ATTRIBUTE             o  ATTRIBUTE
          to see    |             to see     |
                    o                        o
                  red                      blue
    

    Reviewing all of the examples again, we ask the question:

    is the CC on the left a child of the CC on the right?

    The answers are TRUE, MAYBE, TRUE, MAYBE and FALSE, in order. "TRUE" signifies that the relationship is established; one CC is the child of another. An answer of "FALSE" means that the two are the same shape, but in opposition, due to an orthogonality. "MAYBE" means that there is insufficient shared structure to answer the question. For instance, in the second example, the CC representing 'the dog sees a ball' neither is nor isn't a child of 'the dog is happy'. Accordingly, the answer is MAYBE; the two CCs can't be compared.

    Other parts of speech within CCs will affect the child/parent comparison, too. Negation, for example, in a comparison of "ball is not blue" (child) "the ball is red" (parent) will return TRUE. If we reverse them, testing to see whether "the ball is red" is a child of "ball is not blue", the answer will be MAYBE.

    Tense can be attached to verbs and attributes. This also affects child/parent comparisions. Take, for example, "the ball is blue" test as the child of "the toy was red." The answer is MAYBE because the two CCs occur in diferent tenses. Orthogonality really only applies when attributes are in the present tense.

       >> the ball is red
        the red ball is red.
    
       >> debug eval the ball is red
        the red ball is red.
       "True"
    
       >> debug eval the ball was red
        the red ball was red.
       "Maybe"
    
       >> debug eval the ball is blue
        the red blue ball is blue.
       "False"
    
       >> debug eval the ball is not grey
        the red not grey ball is not grey.
       "True"
    

    There are a number of situations where Brainhat may ask itself "is this CC a child of that CC?" or "is this CC true?" The answer may be unknown; "is this CC true?" could return MAYBE. Given an answer of MAYBE, Brainhat will often initiate a more aggressive search for the answer in what is called "self talk." Brainhat will reformulate a question to itself (in English) and process it as if it came from the user. Self-talked input may cause inferences to fire, memories to be restored or motives to be advanced--all of which can lead to a more definitive answer to "is this CC true?"

    Context

    As Brainhat processes, it builds and updates running context and discourse buffers. These provide a background against which Brainhat can better understand what might come next. A simple illustration of the role the context is the resolution of pronouns. If we refer to something by "he", "she" or "it", we're hoping that the program will recognize these as wild cards for some definite noun or noun phrase that came before.

       >> i see the dog
        You see the dog.
       >> it is hungry
        the hungry dog is hungry.
    

    The "it" we are referring to in the statement above is an immediate reference to a dog, fetched from the context. An example matching a noun phrase:

       >> the princess loves luigi it
        the princess loves luigi.
       >> mario hates it
        mario dislikes the princess loves luigi.
    

    "W" words (who, what, when, where and why) can be satisfied by the context, too.

       >> the cat meows
        the cat meows.
       >> the dog barks
        the dog barks.
       >> what meows
        the cat meows.
       >> does something bark?
        yes. the dog barks.
    

    The context grows as the program runs. Older knowledge is pushed to the back. New entries are added to the front. By this, the resolution of ambiguous references evolves to favor the new. This shows the context following "the cat meows" and "the dog barks":

       >> debug
       Break in debug at the start:
       debug> xspeak 1
        You say the dog barks. the dog barks. You say the cat meows. the cat meows.
    

    The CCs of the context are the product of parsing, disambiguation and an election process that arrives at a single input interpretation. The product may be constructed from a combination of clean and dirty concepts. Clean concepts are those that are sourced from the vocabulary, but have not been modified. Dirty concepts are those that have been modified. An example of a clean concept is "dog." An example of a dirty concept is "happy dog." Below, we see two concepts for dog--one dirty and one clean:

      >> happy dog
       dog to be happy.
      >> break
    
       Break in debug at the start:
       debug> list dog
       Meme: default
         (clean text) dog->dog-1 (clean), MID 10000
         (context text) dog->dog-14c57 (dirty), MID 10000
    

    For any vocabulary concept, there will always be a clean original. The original is never touched. Rather a dirty copy is created and modified when necessary. During processing, Brainhat strives to create as few dirty copies as possible. Two copies of "dog"--clean and dirty--may be sufficient for the life of a session. A case where Brainhat will create multiple dirty copies is where an orthogonality is detected.

      >> the happy dog has food
       the happy dog has food.
      >> the sad dog does not have food
       the sad dog does not have food.
      >> is the happy dog the sad dog
       no. the dog is not the happy dog.
      >> break
    
       Break in debug at the start:
       debug> list dog
       Meme: default
         (clean text) dog->dog-1 (clean), MID 10000
         (context text) dog->dog-17028 (dirty), MID 10000
         (context text) dog->dog-1f64f (dirty), MID 10000
    

    Now, we see two dirty dogs: one is happy; one is sad.

    patent pending

    posted in General Discussion
  • Bananas are yellow, of course

    Copyright © 2020, Kevin Dowd

    Layer-1 Memories

    There's a particular flavor of Brainhat memory that forms the basis for common knowledge, like the color of bananas or where you'd expect to find a refrigerator. In Brainhat parlance, these nuggets of common knowledge are called layer-1 memories--very basic stuff, generally true.

    When one is crafting knowledge for Brainhat, the effort is typically one of constructing a scenario, like a day at the beach or an elevator ride. But, you never know when bananas are going to come up, and it might be nice to know something about them, like their color.

    Layer-1 memories have the qualities that they are simple to invoke, will not be recalled if they conflict with the context, and can be overridden easily. Unlike other types of memories that intermingle with the context, recalled layer-1 memories are referenced but never actually installed.

    Here's a layer-1 memory:

    bananas are yellow.
    

    This memory typically be contained in a file. Let's call it bananas.txt. To compile the memory, you would invoke Brainhat like so:

    ./brainhat -r bananas.txt -1
    

    This will add "bananas are yellow" to the collection of memories. To access the memory, we run Brainhat in autorecall mode, with the -A flag:

    dowd@test:~/brainhat$ ./brainhat -A +repeat
    
    >> what color are bananas
     yellow banana is yellow.
    >>
    

    Some bananas are red. The notion that bananas are yellow can be overidden.

    dowd@test:~/brainhat$ ./brainhat -A +repeat
    
    >> what color are bananas
     yellow banana is yellow.
    >> bananas are red
     red banana is red.
    >> what color are bananas
     red banana is red.
    >> are bananas yellow?
     no. banana is red.
    >>
    

    If you are running Brainhat as a daemon, and if the daemon is a memory server, it will make "bananas are yellow" available to other copies of Brainhat, too.

    -Kevin

    patent pending

    posted in Tutorials
  • Vocabulary introduction

    Copyright © 2020, Kevin Dowd

    Vocabulary

    To read human language, Brainhat has to recognize the tokens (words) and it has to make sense of their order. Tokens and order are prescribed by a vocabulary and a grammar. The vocabulary says what the tokens can be. The grammar says how they can be combined. The vocabulary and grammar create the possibilies for, and define the limits of, what Brainhat can understand.

    Brainhat's vocabulary is defined hierarchically. A poodle is a dog, a dog is a pet, a pet is an animal, and so on. Concepts for hamster, cat, dog and wildebeast are children (hierarchically) of the concept for animal. So, we may ask if a wildebeast is an animal and whether it shares some features in common with dogs, and the answer will be "yes." However, there is no upward path from wildebeast to pet. Therefore a wildebeast is not a pet.

    
                  o things          o actions          o adjectives
                 /|\               /|\                /|\
                / | \             / | \              / | \
               /  |  \           o  |  o to eat     o  |  \
              o   |   \      to be  |           happy  |    o pretty
       vegetable  |    \            o to sense         |
                  |     o          / \                 o color
                  |   mineral     /   \               / \
           animal o              o     \             /   \
                  |\       to hear     to see       o     o red
                  | \                           blue     / \
                  |  o wildebeast                       /   \
                  |                                    /     o
                  o pet                               /     pink
                 /|\                                 o
                / | \                             scarlet
               /  |  o cat
      hamster o   |
                  o dog
                  |
                  |
           poodle o
      
    

    A vocabulary definition appears below. This definition has multiple synonyms: "hot dog", "hot dogs" and the name "hotdog-1". To reference this definition, one could refer to it by any of the synonyms, e.g. "the dog ate a hot dog" or "the dog ate a hotdog." [footnote: You'll notice that we've grouped plural and singular forms together. This is not a requirement; the vocabulary can be built so that singular and plural are distinct. For the time-being, and for simplicity, we will work with combined forms.]

        define      hotdog-1
                    label           hot dogs
                    label           hot dog
                    label           hotdogs
                    label           hotdog
                    orthogonal      food-1
                    child-of        food-1
    

    When a word has two or more distinct meanings, there may be two or more definitions. For example, a ball is round, a ball has the quality of being a certain color, a "ball" is a toy. A "ball" might also be a formal dance, with an orchestra and glass slippers.

        define      ball-1
                    label           balls
                    label           ball
                    child-of        toy-1
                    wants           color-1
                    wants           size-1
                    related         round-1
                    related         play-1
                    wants           shape-1
    
        define      ball-2
                    label           balls
                    label           ball
                    child-of        party-1
                    related         loud-1
                    wants           volume-1
    

    To tell the two forms of ball apart, we may add hints to the definitions. If we say "the ball is red," chances are that we'll get the correct sense of the word "ball" because of the hint that says "ball-1 wants color-1". Once Brainhat has been processing data for a while, reliance on hints in the vocabulary become less important. Instead, Brainhat will look to memories and context when trying to determine the sense of a word.

    patent pending

    posted in Tutorials
  • Quick QA results for 10/14/20

    These are the automated QA test results (click here) for 10/14/20.

    posted in QA and Release Info
  • A little bit of hands-on

    Copyright © 2020, Kevin Dowd

    Introductory Hands On

    This chapter introduces Brainhat by example. As we look at examples, we will also have the opportunity to introduce terminology and discuss how knowledge is handled within Brainhat.

    To run Brainhat from the command line, go to the directory where you have unpacked the program and enter "./run". The "run" script will check for changes you might have made in the configuration files, update as needed, and then start the program, like so:

    % ./run
    make: 'data' is up to date.
    Initializing
    
    >> hello
     hello.
    >> goodbye
    
    goodbye!
    %
    

    Brainhat comes with a basic vocabulary and grammars that support all of the exercises we will present. You are encouraged to experiment as we proceed. Be aware that if something doesn't work the way you hope, it may be because the vocabulary or grammar don't currently cover it. We will talk about how to extend both much later on.

    We refer to simple English as code. Once parsed, stored and indexed, the code becomes knowledge, and may be executable. The exact nature of the stored knowledge is affected by context, which is the product of code that came before.

    In Brainhat, an individual knowledge entity is called a concept. A concept is similar to a vocabulary word. For example, "dog" is a concept:

    >> dog
     dog.
    

    When we combine two or more concepts, we create a complex concept or CC:

    >> dog is happy
     happy dog is happy.
    >> dog
     dog is happy.
    

    Attribute assignment

    Attribute assignments are the combination of a concept that is a thing with a concept that is an attribute. Below, we build a dog with several attributes:

    % ./run
    >> dog is happy
     happy dog is happy.
    >> dog is hungry
     happy hungry dog is hungry.
    >> dog is big
     hungry happy dog is large.
    >> bye
    

    Once we have a dog, we can ask questions about the dog's attributes.

    % ./run
    >> dog is happy
     happy dog is happy.
    >> dog is hungry
     happy hungry dog is hungry.
    >> is dog hungry?
     yes. happy dog is hungry.
    >> is dog happy?
     yes. hungry dog is happy.
    >> bye
    

    Just as concept for happy is an attribute, so is the concept for sad. These two concepts are orthogonal, meaning that you cannot attach both concepts to a third concept at the same time. Orthogonality is useful because it makes it possible to differentiate things based on their attributes.

    % ./run
    >> dog is happy
     happy dog is happy.
    >> is dog happy?
     yes. dog is happy.
    >> is dog sad?
     no. dog is happy.
    >> bye
    

    Attribute assignments can be explicit or implicit. The examples we have looked at so far demonstrate explicit assignments. Implicit attribute assignments occur when an attribute is adjacent the subject. An example of an implicit assignment is the application of happy in the following example:

    % ./run
    >> happy dog is hungry
     happy hungry dog is hungry.
    >> is dog happy?
     yes. hungry dog is happy.
    >> is dog hungry?
     yes. happy dog is hungry.
    >> bye
    

    Something to be careful about: the use of orthogonal implicit attributes can spawn multiple variants of a CC; though you may believe that you are dealing with just one copy of dog, you may find that you actually have two. Here's an example of how this can happen:

    % ./run
    >> happy dog is hungry
     happy hungry dog is hungry.
    >> sad dog is hungry
     sad hungry dog is hungry.
    >> describe dog
     happy dog is hungry. sad hungry dog is hungry.
    >> bye
    

    We have already seen that attributes sad and happy are orthogonal. The concept for dog cannot carry two orthogonal attributes at the same time and in the same tense; that is, we cannot have a "happy sad dog." Accordingly, the above code produces two CCs for dog--one that is happy, and one that is sad. This might be exactly what you want, in which case the example shows how it's done.

    When making explicit attribute assignments, and when there is an orthogonality, Brainhat will push the older attribute into the perfect past tense. By this, a dog that was once sad may become happy:

    % ./run
    >> dog is sad
     sad dog is sad.
    >> dog is happy
     past sad dog is happy.
    >> bye
    

    Attributes can take the form of prepositional phrases, too.

    % ./run
    >> the dog is in the water.
     the dog is in the water.
    >> where is the dog.
     the dog is in the water.
    >> bye
    

    As with simple attributes, prepositional phrases can be orthogonal. For example, the dog cannot be inside the house and in the yard at the same time. This is because the objects of the prepositions, house and yard, are orthogonal, but the preposition, in, is the same.

    % ./run
    >> dog is in the house.
     dog is in the house.
    >> is dog in the yard?
     no. dog is in the house.
    >> bye
    

    We could keep the objects the same and vary the preposition and get a similar result. Here we find the the orthogonality between prepositions inside and outside:

    % ./run
    >> the dog is inside the house.
     the dog is inside the house.
    >> is the dog outside the house?
     no. the dog is inside the house.
    >> bye
    

    As we have seen, orthogonal attributes can coexist if they are in different tenses. More precisely, orthogonal attributes can coexist as long as they are not both in the present tense. It is possible to have orthogonal attributes in future or past tenses, such as "the dog was happy" in combination with "the dog was sad" as both could have been true at different times, and so may co-exist. Here are some explicit attribute assignments in several tenses:

    % ./run
    >> i was sad.
     You were sad.
    >> i am angry.
     You are angry.
    >> i will be happy
     You will be happy.
    >> bye
    

    Possession is another form of attribute based on the prepositional notion of belonging to, as demonstrated in the following example:

    % ./run
    >> the dog's ball is red.
     dog's red ball belonging to dog is red.
    >> the cat's ball is blue.
     cat's blue ball belonging to cat is blue.
    >> is cat's ball red?
     no. the ball is blue.
    >> bye
    

    A name is another form of attribute. Names have the special property that they can be used in a position where a reference to a concept that is a thing would typically appear.

    % ./run
    >> the big dog's name is rover
     large rover dog is rover.
    >> the little dog's name is sparky
     small sparky dog is sparky.
    >> rover is hungry
     large rover dog is hungry.
    >> sparky is happy
     small sparky dog is happy.
    >> bye
    

    Following the name assignment, we can use "rover" in place of "the large hungry dog" or "large dog" or "hungry dog."

    Propositions (not prepositions)

    In Brainhat, we refer to a statement that uses verbs other than to be as a proposition. Here's an example of a proposition. The verb is to want:

    % ./run
    >> the dog wants a bone.
     the dog wants a bone.
    >> does the dog want a bone?
     yes. the dog wants a bone.
    >> bye
    

    Many complex concepts (CCs) have tense, number and person (TNP) attached. The tense, number and person are derived from the subject and a verb or auxiliary verb. The tense portion of a CC's TNP is one of past, present, future, conditional, future conditional, and so on. Here are a few examples of tense:

    % ./run
    >> i saw my mother.
     You did see your mother belonging to You.
    >> i see my country.
     You see your country belonging to You.
    >> i will see europe.
     You will see europe.
    >> bye
    

    Auxiliary or helper verbs like do, did, will and would can also carry tense, like so:

    % ./run
    >> i saw the princess.
     You did see the princess.
    >> did i see the princess?
     yes. You did see the princess.
    >> do i see the princess?
     maybe. You did see the princess.
    >> bye
    

    Tenses may be grouped for simplicity. For instance, the English gerund may be understood as the present tense, as in the following example:

    % ./run
    >> i am sleeping.
     You sleep.
    >> bye
    

    One particular tense--the future imperfect--is programmed to be recognized by Brainhat post-processing as an opportunity for asking a question (if Brainhat doesn't already know the answer). This functionality is configurable.

    % ./run
    >> i might like french fries.
     You might like fries. do You like fries?
    >> bye
    

    A CC's number is derived from the subject, and can be either of singular or plural. For simplicity, most of the concepts within a Brainhat vocabulary distribution are in the singular with plural forms as aliases for their singular counterparts, as demonstrated here. This, too, is configurable:

    % ./run
    >> the cats chase the dogs.
     the cat chases the dog.
    >> bye
    

    A CC's person comes from the subject, too. I (or brainhat) is first-person; You (or speaker) is second-person; almost every other object is in the third-person. Combinations of TNP are derived from the components of the input and become part of the knowledge represented by the corresponding CC. Here, we demonstrate how the number and person found on the verb are subordinate to the number and person of the subject. In each case, we have used the verb infinitive, yet produce a sensible CC:

    % ./run
    >> i to be hungry.
     You are hungry.
    >> you to be happy.
     I am happy.
    >> the dog to eat his food.
     the dog eats the dog's food belonging to the dog.
    >> bye
    

    Brainhat resolves pronouns from the immediate context. Gender is taken into consideration. Often, pronouns are ambiguous, in which case Brainhat attempts to resolve based on proximity or position.

    % ./run
    >> the princess is pretty.
     the pretty princess is pretty.
    >> mario is ugly.
     ugly mario is ugly.
    >> the food is delicious.
     the delicious food is delicious.
    >> she likes him to eat it.
     she likes ugly mario eats the delicious food.
    >> who is she?
     the pretty princess to be pretty woman.
    >> bye
    

    In some cases, Brainhat will resolve anaphors. These are pronouns at the end of a statement that reference a noun at the beginning, such as:

    % ./run
    >> mario knows that he is happy
     mario knows mario is happy.
    >> bye
    

    Sometimes, they're implied:

    % ./run
    >> mario wants to see the dog
     mario wants mario to see the dog.
    >> bye
    

    As we have seen in the last few examples, the object in a proposition can be another proposition, as with "mario wants mario to see the dog", just above. Object propositions may also be referenced by (event) pronouns:

    % ./run
    >> the princess swam in the river.
     the princess swam in the river.
    >> mario liked it.
     mario liked the princess swam in the river.
    >> bye
    

    Propositions built with stative verbs make an assertion about the subject. They are similar to attribute assignments made with the verb "to be". However, they describe an action performed by or on behalf of the subject; they don't bind the the attribute to the subject. For example:

    % ./run
    >> mario seems happy
     mario appears happy.
    >> is mario happy
     maybe. mario.
    >> how does mario seem?
     he seems happy.
    >> bye
    

    Later, we will see that implicit or explicit inferences provide a path to attach happy to mario when he seems to be happy. Or, on the contrary, inferences may provide a path to sad.

    In the same way that a stative verb combined with an adjective says something non-binding about the subject, a stative verb combined with an object proposition makes the object non-binding. We say that the object proposition is in the subjunctive case. This will become clearer with an example:

    % ./run
    >> mario believes that the princess loves luigi
     mario thinks the princess loves luigi.
    >> does the princess love luigi?
     maybe. I do not know.
    >> does mario believe that the princess loves luigi?
     yes. mario thinks the princess loves luigi.
    >> bye
    

    The fact that mario believes that the princess loves luigi doesn't necessarily make it so. What we do know is that mario believes it.

    A little digression: thus far in our examples, Brainhat has believed everything I've said. Consider, however, that it could all be prefaced with "You say...". It's the subjunctive at work again, just like in the previous example. Why should Brainhat believe anything that I say just because I say it?

    % ./run
    >> the dog is happy
     the happy dog is happy.
    >> what do i say
     You say the happy dog is happy.
    >> bye
    

    Brainhat believes what I say because that's the default setting. However, we can change it so that Brainhat registers what I say, but doesn't necessarily believe it. There is a debug flag, verbatim, that we will reset for this purpose:

    % ./run
    >> debug unset verbatim
    >> the dog is happy
     the dog is happy.
    >> is the dog happy?
     maybe. the dog.
    >> do i say that the dog is happy?
     yes. You say the dog is happy.
    >> bye
    

    Once Brainhat is free to believe as it wishes, it needn't trust the code from it's interlocutor. In this example, Brainhat believes the opposite of when I tell it, based on an inference template:

    % ./run
    >> debug unset verbatim
    >> if i say the dog is happy then the dog is sad
     if You say the dog is happy then the dog is sad.
    >> the dog is happy
     the dog is happy. the sad dog is sad.
    >> why
     the sad dog is sad because You say the sad dog is happy.
    >> bye
    

    Concepts for things, attribute, verbs, etc., live in a taxonomically ordered vocabulary. A dog is a pet, a pet is an animal, and so on. At the same time, a dog is a mammal, a mammal is an animal, and so on. We say that pet and mammal are parents of dog and that dog is a child of mammal and pet. Each concept may have zero, one or more parents. The inter-relationships between parents and children can be arbitrary with the exception that no concept can be its own parent. A concept's relationship to its parents and children play a role in recognizing the concept as a specific instance of a general reference to its parent or vice versa.

    % ./run
    >> is a dog a pet?
     yes. a dog is a pet.
    >> is a dog an animal?
     yes. a dog is a animal.
    >> is a dog a mammal?
     yes. a dog is a mammal.
    >> is a dog a thing?
     yes. a dog is a thing.
    >> is a dog a fish?
     no. a dog is not a fish.
    >> bye
    

    The answer to the last question, "is a dog a fish", is "no" because fish and dogs are orthogonal within the vocabulary. If I were to ask "is the dog a banana?", the answer would be "maybe." This may seem odd to you; a dog is certainly not a banana as we know it. However, we will see later that we can make a relationship between dogs and bananas by saying "the dog is a banana" or "the dog is not a banana", in which case the answer will be "yes" or "no."

    Here's an important point: within Brainhat, yes means something is definitely the child of something else; no means something is definitely not the child of something else (due to orthogonality or a knowledge); or maybe, which really means that the two cannot be compared.

    Whole CCs can be compared to other CCs as long as their piecewise components (subject, verb, attribute, object, whatever) have a homologous superior/inferior parent/child relationship.

    % ./run
    >> dog sees cat."
     dog sees cat.
    >> does dog see animal
     yes. dog sees cat.
    >> does something see cat
     yes. dog sees cat.
    >> does something sense something?
     yes. dog sees cat.
    >> does dog see fish?
     maybe. I do not know.
    >> bye
    

    We start with the proposition "dog sees cat." We ask "does something sense something?," and this returns true because each of the concepts in the question (something, sense and something) is a parent of the corresponding concept in the answer (dog, sees and cat) and because "something senses something" is the the same shape as "dog sees cat." That is: "thing verb thing."

    The last question, "does dog see fish?" comes back "maybe" because fish is not a child of cat, therefore "dog see fish" is not a child of "dog sees cat." Accordingly, we never get to the point where we would ask if fish and cat are orthogonal because the two CCs don't have a parent/child relationship in the first place. The two CCs cannot be compared. This is what we want.

    Intransitive

    An intransitive verb is one that takes no object. Examples of intransitive verbs are to sleep or to wonder. One does not say "I sleep my lunch" or "I wonder the banana." But, a reflexive "I sleep myself" almost makes sense.

    A transitive verb, on the other hand, is one that takes a subject and an object. Examples of transitive verbs are to eat or to want, as in "I eat my lunch" or "He wants a doughnut." Transitive verbs can be used intransitively, too, with a subject implied, such as I eat or he sings.

    In Brainhat, intransitive objects are represented by the concept things, which is at the top of the taxonomy for all things--dogs, french fries, potato bugs. So, when you input "mario sleeps", the CC that's generated captures "mario sleep things." Likewise, when you
    ask "does mario sleep?", the question is internally represented as "does mario sleep things?"

    % ./run
    >> mario sleeps
     mario sleeps.
    >> luigi talks
     luigi talks.
    >> the princess sees bananas
     the princess sees banana.
    >> does mario sleep?
     yes. mario sleeps.
    >> does luigi talk?
     yes. luigi talks.
    >> does the princess see?
     yes. the princess sees banana.
    >> does mario sleep bananas?
     maybe. I do not know.
    >> bye
    

    Equivalence

    In Brainhat, the assignment of one concept as the child of another is termed an equivalence. Examples are "the dog is a banana" or "mario is the king". When "mario is the king" is input, it causes the concept for mario to become a child, hierarchically, of king. The term equivalence isn't perfect; the two concepts are not made equivalent; one becomes subordinate to the other. However, once we say "mario is the king", all of the parents of king become parents of mario.

    % ./run
    >> mario is an onion.
     mario is a onion.
    >> is mario a vegetable?
     yes. he is a onion.
    >> bye
    

    We can also say that mario is not something, like so:

    % ./run
    >> mario is not the king.
     mario is not the king.
    >> is mario king?
     no. he is not the king.
    >> bye
    

    Orthogonality applies to the relationships formed by equivalences:

    % ./run
    >> is a fruit a vegetable?
     no. a fruit is not a vegetable.
    >> mario is a fruit
     mario is a fruit.
    >> is mario a vegetable?
     no. he is not a vegetable.
    >> bye
    

    Explicit Inferences

    Explicit inference templates are a executable code stored in the subjunctive. Elements of the template--subject, verb, attribute, etc.--are unresolved references to concepts that may fill their spots if the inference is executed. Here's a simple example:

    % ./run
    >> if i love you then you love me.
     if You love Me then I love You.
    >> i love you
     You love Me. I love You.
    >> why?
     I love You because You love Me.
    >> bye
    

    Here's an inference template with more complicated substitutions:

    % ./run
    >> if an animal sees something then an animal eats something.
     if a animal sees thing then a animal eats thing.
    >> bird sees a grape
     bird sees a grape. bird eats a grape.
    >> cat sees a bird
     cat sees a bird. cat eats a bird.
    >> bye
    

    Orthogonality makes it possible to build inference templates that would otherwise be difficult to express:

    % ./run
    >> if a dog sees another dog then the dog barks at the other dog.
     if a dog sees another dog then the dog barks at the dog.
    >> a dog's name is fido.
     fido is fido.
    >> a dog's name is sparky.
     sparky is sparky.
    >> fido sees sparky.
     fido sees sparky. fido barks at sparky.
    >> bye
    

    In this case, the concepts another and other signal orthogonality between the second dog and the first dog. By this, we can reference two dogs in an inference template and be able to tell them apart at runtime. Other orthogonality clues can come from first versus second or this versus that.

    When the result of one inference provides the input for the next, we say that the inferences form a chain. Chaining is applicable to explicit and implicit inferences alike. Here's an example with explicit inference chaining:

    % ./run
    >> if i am happy then you are happy
     if You are happy then I am happy.
    >> if i see a toy then i am happy
     if You see a toy then You are happy.
    >> if i look then i see a ball
     if You look then You see a ball.
    >> i am looking
     You do look. You see ball. You are happy. I am happy.
    >> why
     I am happy because You are happy.
    >> why
     You are happy because You see ball.
    >> why
     You see ball because You look.
    >> bye
    

    An explicit inference template is executable code. Execution of an inference depends on the conditions of the template being true. When Brainhat recognizes that some knowledge in the context that may invoke an inference, it substitutes elements of that knowledge into the inference template and tests for truth. To be successful, the substituted concepts must be children of the corresponding concepts of the template and there must be no orthogonalities.

    % ./run
    >> if i see a red house then i am happy.
     if You see a red house then You are happy.
    >> i see a house.
     You see a house.
    >> Am I happy?
     maybe. You.
    >> i see a blue house.
     You see a blue house.
    >> Am I happy?
     maybe. You.
    >> i see a red house.
     You see a red house. You are happy.
    >> bye
    

    The inference does not fire the first time because "I see a house" does not satisfy "I see a red house." The inference does not fire the second time because "I see a blue house" not satisfy "I see a red house." Moreover, it's orthogonal. When we say "I see red house," the condition is satisfied and the inference fires.

    % ./run
    >> if i see a red house then i am happy.
     if You see a red house then You are happy.
    >> i see a house
     You see a house.
    >> debug eval i see a house
     You see a house.
     "True"
    >> debug eval i see a red house
     You see a red house.
     "Maybe"
    >> bye
    

    Implicit chaining occurs when memories are restored. We will look at implicit inferences when we explore memories, later on.

    patent pending

    posted in Tutorials
  • Goldilocks and the Three Bears

    Here's Brainhat's rendition of Goldilocks and the Three Bears:

    goldilocks girl is goldilocks. she walks in the forest. goldilocks
    girl sees a house in the forest. a house in the forest belongs to a
    family. first papabear bear is papabear. first papabear bear is
    large. second mamabear bear is mamabear. second mamabear bear is
    medium. third babybear bear is babybear. third babybear bear are
    small. nobody are home.

    goldilocks girl does go in a house. she does go into the kitchen.
    bowl are in the kitchen. bowl in the kitchen does contain porridge.
    the first bowl in the kitchen does belong to first bear. the first
    bowl in the kitchen are too hot. the second bowl does belong to
    second bear. the second too cold bowl are too cold. the third bowl
    does belong to third bear. the third good bowl are good. goldilocks
    girl does eat bear's porridge belonging to third bear. goldilocks
    tired girl are tired at that she does eat bear's porridge belonging to
    third bear.

    goldilocks girl does go to the living room. she are goldilocks are
    tired. chair are in the living room. bear's first chair in the
    living room are belonging to first bear. bear's first chair in the
    living room are too large. bear's second chair are belonging to
    second bear. bear's second chair are too large. bear's third chair
    are belonging to third bear. bear's third chair are good. goldilocks
    girl does sit in third bear. she does break bear's third chair.

    goldilocks girl are tired. bed are in the bedroom. bear's first bed
    in the bedroom are belonging to first bear. bear's first bed in the
    bedroom are too hard. bear's second bed are belonging to second bear.
    bear's second bed are too soft. bear's third bed are belonging to
    third bear. she are goldilocks are tired.

    second bear does come home. third bear does come home. the first bear
    does come home. the first bear does see somebody've eat the bear's
    porridge belonging to the first bear. second bear does see
    somebody've eat bear's porridge belonging to second bear. third bear
    does see somebody've eat bear's porridge belonging to third bear. the
    first bear does see somebody've sit on bear's first chair. second
    bear does see somebody've sit on bear's second chair. third bear does
    see somebody've sit on bear's third chair. the first bear does see
    somebody've lay in bear's first bed. second bear does see somebody've
    lay in bear's second bed. third bear does see somebody've lay in
    bear's third bed. third bear does see somebody in bear's third bed.
    goldilocks girl does jump out bear's third bed.

    posted in Blogs
  • Empty, now, but plenty to come

    We're working hard to have a development release before the end of the year. At that time, I will be looking for a small group of developers to test and create content. Write me if you are interested.

    -Kevin

    posted in Blogs