You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per "Memory, Events and Percepts - A discussion on Representation" page.
TODO - phase 1:
LongTermMemory story Events and Percepts as first-class objects.
PerceptEvents are only used for historical memories of inputs that have been "perceived".
LongTermMemory .search() returns List (where Object is always either Event or Percept)
LongTermMemorySearchProcessor no longer needs to un-wrap PerceptEvents into Percepts.
In first cut, MemoryEvent kept but changed to be able to store arbitrary objects, and then used to store List.
FindMatchingConceptProcessor updated as needed when handling the MemoryEvent.
TODO - phase 2:
Processors to return Events without timestamp, and with triggering Event(s) in references.
Processors emit with their own totally ego-centric strength.
AA uses references to decide on relative strength of the event.
AA sets timestamp.
Get rid of use of 'HANDLED' flag
Should be able to create a very simple DSL for emitting Event that automatically tracks whether the event has already been emitted, taking that complexity out of the processors. ie: make processors more stateless and to just work immediately off what's in WM. I wonder how far this could be taken? See wiki page "Processors-like-Cloud-Lambda-Functions".
TODO - phase 3:
Consider whether to remove the existence of MemoryEvent altogether
Requires LTM results to be stored as individual items (un-collected) into WM.
The text was updated successfully, but these errors were encountered:
As per "Memory, Events and Percepts - A discussion on Representation" page.
TODO - phase 1:
TODO - phase 2:
TODO - phase 3:
The text was updated successfully, but these errors were encountered: