Skip to content
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

Revise Memory,Event,Percept Representations and Type Wrapping #14

Open
toaomalkster opened this issue Oct 26, 2019 · 0 comments
Open

Revise Memory,Event,Percept Representations and Type Wrapping #14

toaomalkster opened this issue Oct 26, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@toaomalkster
Copy link
Owner

toaomalkster commented Oct 26, 2019

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.
@toaomalkster toaomalkster added the enhancement New feature or request label Oct 26, 2019
@toaomalkster toaomalkster added this to To do in Making Something Interesting via automation Oct 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

1 participant