Playing with Semantic Memory Bob Marinier 11/22/2018

Motivations for Semantic Memory Expensive rules Data chunking / learning Runtime query construction Limit the size of WM (possibly to help epmem) Take advantage of underlying database Pre-load data Maintain data across runs Data chunking example: if we want to learn that the capitol of the US is DC, then we have to bend over backwards to learn a rule like “capitol of US => DC”. And that rule is still incapable of answering the question “What country is DC the capitol of?” Query construction example: find me a blue car with a flat tire. With just those 3 features (color, vehicle type, tire status), you’d have to write at least 7 rules (assuming values could be variablized). What if you had 100 features? What if you didn’t know what the features were, or how many you’d need to simultaneously match on? 11/22/2018

Example (from Soar manual) sp {smem*sample*query (state <s> ^smem.command <sc> ^lti <lti> ^input-link.foo <bar>) --> (<sc> ^query <q>) (<q> ^name <any-name> ^foo <bar> ^associate <lti> ^age 25) } Name can be anything (wildcard) Foo’s value must match whatever <bar> is bound to Associate’s value must be the LTI bound to <lti> Age’s value must be 25 11/22/2018

Semantic Memory Does Not: Retrieve multiple matches at once Support arbitrary partial matching Support deep structure matching Support variablize attributes Support less than/greater than matching Support negative queries Support special spatial queries Prove P=NP Solve world hunger The way people talk about semantic memory sometimes, it seems that there are some misconceptions 11/22/2018

Looping to Retrieve Multiple Matches Looping in semantic memory: 3 methods Build up a prohibits set As each item is retrieved, add its LTI to the prohibits For large sets, this doesn’t scale well Modify the memories so they don’t match anymore Scales much better, but requires data to share some flag Retrieve linked LTIs (walk a list) Scales even better since there is no match cost, but requires data to be structured as a list Compared to writing a single expensive rule, writing the many rules to do either of these patterns is a lot of work So I started extending the Dave Ray’s bebot library 11/22/2018

Generic Bebot Loop Proposal sp {propose*bebot*smem*loop (state <s> ^name test-smem-loop -^result) --> (<s> ^operator <o> +) (<o> ^name bebot*smem*loop ^query <query> ^func my-function-operator ^tcnum-attr my-tcnum-attr # optional ^next-attr my-next-attr # optional ^allow-chunks true # optional; default false ^init my-init-operator # optional ^test my-test-operator # optional ^return my-return-operator) # optional Performs all work in a substate, with result returned to superstate query: the cue to give to semantic memory func: operator to propose for each retrieved value (you must write the apply rule(s)) tcnum-attr is optional (if not supplied, will use prohibits) By default chunking is disabled. Can enable it with ^allow-chunks true (learning still needs to be on) Can also specify operators for init, loop condition testing, and returning results (but defaults exist for all of these). For any specified operators, have to write appropriate apply rules 11/22/2018

Bebot Example: Retrieve first n values sp {propose*bebot*smem*retrieve-n (state <s> ^name test-smem-retrieve-n -^result) --> (<s> ^operator <o> +) (<o> ^name bebot*smem*retrieve-n ^query <query> ^n 3) (<query> ^value <v>) } 11/22/2018

Example: get two smallest values in a set (Expensive rule) sp {search-wm*return-result (state <s> ^name search-wm ^values <vals> ^superstate <ss>) (<vals> ^value <v1> {<v2> < <v1>}) -(<vals> ^value {<v3> <> <v2> < <v1>}) --> (<ss> ^min-values <mv>) (<mv> ^value <v1> <v2>) } 11/22/2018

Example: get two smallest values in a set (Bebot) sp {propose*bebot*smem*loop (state <s> ^name test-smem-loop -^result) --> (<s> ^operator <o> +) (<o> ^name bebot*smem*loop ^query <query> ^func func-two-min-vals ^tcnum-attr tcnum) (<query> ^value <v>)} sp {apply*func-two-min-vals*first (state <s> ^operator <o>) (<o> ^name func-two-min-vals ^object.value <newval> ^previous <p>) -(<p> ^value) (<s> ^result <p>) (<p> ^value <newval>)} sp {apply*func-two-min-vals*second (<p> ^value <v1> -^value <> <v1>) sp {apply*func-two-min-vals*too-large (state <s> ^operator <o>) (<o> ^name func-two-min-vals ^object.value > <v2> ^previous <p>) (<p> ^value <v1> ^value {<v2> > <v1>}) --> (<s> ^result <p>)} sp {apply*func-two-min-vals*replace-value ^object.value {<newval> < <v2>} (<s> ^result <p>) (<p> ^value <v2> - <newval>)} 11/22/2018

Performance Results: Time (get 2 smallest values) These results from csoar 9.3.1 WM-rule: expensive rule – kills reactivity WM-ineqop: using identifier ordering to process objects like a list. Slow, but remains reactive WM-list: storing objects in a list and using bebot’s list processing (note, this doesn’t scale in jsoar because of a bug fix that hasn’t been ported) Smem-prohibit: using prohibits list Smem-modify: modifying memories Smem-list: storing objects in a list in smem and doing a NCB retrieval to get the next item 11/22/2018

Performance Results: Time (get 2 smallest values) 11/22/2018

Performance Results: Throughput (get 2 smallest values) Looks like list processing slows down over time Early list craziness probably due to memory pools being initialized? 11/22/2018

Performance Results: Throughput (get 2 smallest values) Indeed, at large set sizes, smem is faster when using the modify or list approaches The degradation over time is probably due to the backtrace building up, but I’m not sure why it affects the WM version more than the smem versions 11/22/2018

Should I Use Semantic Memory? Yes No Simple rules too expensive Data learning Runtime query construction Can’t use WM Need a small WM Can’t maintain data in a WM list Want database guarantees Need to pre-load lots of data Need to maintain data across runs Simple rules work well Performance matters and don’t need a general solution Need to do queries smem doesn’t support Need a stable system 11/22/2018

More Information Soar 9.3.1 manual Bebot: https://github.com/daveray/bebot 11/22/2018

Nuggets Coal Smem really does work May be able to capture some common usage patterns in a reusable library Even when slow, still maintains reactivity Underlying database can be useful Starting to understand some use cases where it makes sense Requires more work to use than expensive rules Maybe not the best for extensive looping over sets Prohibit approach doesn’t really scale Architectural support for iterators/cursors might be nice Best uses cases still not well understood 11/22/2018