Exercise 14: Implement SolvePathVariableSeptember 11, 2008
SummaryInputs:
  | A parent entity, which might be null. |
| A parent relation type which describes the mandatory relationship between the parent entity and the variable entity that is being solved for. |
| A child entity, which might be null. |
| A child relation type which describes the mandatory relationship between the the variable entity that is being solved for and the child entity. |
Outputs:
All entities that satisfy the conditions.
To accomplish this, new indices and their respective look up functions will need to be added to the
Entity and
Brain classes:
New index:
Given an entity Y and relation type R, what entities X satisfy the relationship X R Y?
New lookup functions:
| 1. | GetInverseHasList: Given an entity X, which entities have a has_a relationship with X? |
| 2. | GetInverseIsAList: Given an entity X, which entities have a is_a relationship with X? (Actually, it appears that this one might not be needed) |
Exercise 13: Rule parserSeptember 11, 2008
SummaryWrite a parser to allow rules to be added to the brain. Add a hash to the brain called "rules" that indexes rules on the following three items:
| 1. | Their type |
| 2. | Their first non-variable entity type |
| 3. | Their second non-variable entity type |
Test casesClick hereExercise 12: Rule class designSeptember 11, 2008
SummaryThe objective of this exercise is to complete a class design for rules as described in an earlier post.
| A rule can have one or more conditions. |
| A rule has exactly one conclusion. |
| A rule condition is basically the same as a transformation output specification, whereby any token can be replaced with a numbered variable. |
| Likewise, a rule condition is basically the same as a transformation output specification. |
| The rule conclusion can only use variables that are referenced in one or more rule conditions. |
| A rule has a type: A rule is either an "assignment rule" or a "relationship rule". |
older >>
