-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared data source between AgentSensorSubroutines and AgentSubroutines #5
Comments
Could we use a relational db for the brain? association table Each agent gets its own association table ex
Using the above, we don't know if plant01 is edible; we need to create a Hypothetical Association (HA):
We would create one EA model based on 'self' sources to make a weighted prediction, We would compare the EA and LA predictions (weighted, of course) and then make a determination. Thought Process for New EncounterI am on a cell with a Do I know anything about this If there are no results: |
AgentSensorSubroutines and AgentSubroutines both require access to a shared data store, preferably a document-based (i.e. nosql) store so that we don't have to continuously amend table schemas.
Example
Let's say we have a sensor subroutine
AgentSensorSubroutineFeel
, and in this subroutine, it checks neighboring cells for something it can feel. If it finds something, it will indicate that there is something feelable there and indicate its qualities. For example, it might post something like this to the agent's brain:The entity's
get_features()
function may return something in the form of an array of arrays, each subarray containing a[<thing>, <key>, <value>]
like this:Now the brain for this agent will have three Experiential Associations for
plant03
'sfeel
feature (which is only knowable now because we have an AgentSensorSubroutine for feel). When it comes time to process sensory data for this agent during a given step, a subroutine can now 'recall' any associations between any 'plant' thing, and specifically any 'plant03'.Organizing sensory input this way--thing, key, value--doesn't give an agent any future abilities to generalize about certain things. For example, let's say that an agent has a wealth of associations about plants 01-09. Can it make a generalization about plants based on what it knows about plant01, plant02, etc?
Perhaps the way to create a 'production' model about a
plant
is to take into account all the associations aboutplantNN
s and form aplant
model?As an example, let's say I know that
plant01
feels wet and pokey,plant02
feels wet and soft, andplant03
feels dry and soft. Now let's say I am hungry and I decide, not having any associations with plants and edibility, to try to eatplant01
and get the following returned:Given this new information, my
AgentSubroutineEat
subroutine should read this sensor data and create new associations based off them for theEat
subroutine (since taste and consumption are closely linked), like (pseudo code):plant01
]plant01
. If there are none, go to 3. If there are any 'edible' features, is plant01 edible? Eat it. If not, don't eat it.edible
feature associations exist forplant01
, what features exist for any plant whereedible = True
? If none exist, go to 4. If there are edibleplantNN
s, should we try to eatplant01
based only on the information we know? If yes, eat it and learn a new association. If NO, don't learn anything new--since we haven't tried to eat it.In this way, the ability to generalize is an innate feature of having compiled sensory data in a way that can be mined by a subroutine.
The text was updated successfully, but these errors were encountered: