On Thu, Jan 16, 2020 at 8:05 AM Alexander Gabriel <[email protected]> wrote:
> Also, are you sure you want to use StateLink? I tend to think reasoning >> works better on immutable structures. >> > > The robot needs to decide what to do based on the state of the human and > the environment, so if the human has a crate do this, if not do that. > Thus I need to keep track of the human state which I do via StateLinks. Is > that suboptimal? > Should be OK. After all, the StateLink was invented for robot control :-) However... some history might help: When the StateLink was invented, the intent was for it to be used to build "behavior trees" https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control) The intended usage was to have some sensory system (ROS) punch atoms into the StateLink, tracking external reality. Then, in the atomspace, there would be a collection of rules, written using SequentialAndLink and SequentialOrLink to implement the behavior-tree "selector" and "sequencer" concepts. The current state of the Statelink would be accessed via GetLink's that would run whenever some behavior tree triggered. No one ever day-dreamed about using StateLink in a predicate-logic or reasoning system. It might be usable as such, but .. this is fresh territory. Next: when StateLink was invented, neither the URE nor PLN were in a usable state. Also, at that time, the "openpsi" system was being developed as an alternative rule-selection and scheduling system. (That's because URE has certain scalability problems aka "combinatorial explosion" when there's a lot of rules; the openpsi system had/has a way of beating down the combinatorial explosion.) So anyway, no one ever ran any of the behavior-tree robot-control rules within URE or PLN; they were run either hard-coded, or in openspi. So .. again .. unexplored territory. Oh, and openpsi "mostly works" but is also a kind-of unfinished project. Meanwhile, back at the farm ... tracking state with the StateLink is .. OK, but not terribly scalable if there's a lot of state. The reason for this is that any update to a StateLink requires punching it into the atomspace, and there's CPU overhead in that. ... and "most users" probably don't need to put things into the atomspace. The "only reason" to put something in the atomspace is to "remember it" for later graph-search, ... or for reasoning. There is an alternative way to track state: use FloatValue or StringValue (or the extensions thereof). These are like TruthValue, but do not have a pre-defined interpretation as "truth" - they can represent "anything". They also do not pay the over-head of insertion into the atomspace, which makes them (much?) faster. The down-side is that they cannot be searched over. You have to know their precise location to use them, as otherwise they are not findable/searchable. So for example: (ConceptNode "gripper hand") ;; a well-known location in the atomspace (PredicateNode "3D location") ;; a well-known key for key-value tagging. (cog-set-value! (ConceptNode "gripper hand") (PredicateNode "3D location") (FloatValue 0.1 0.2 0.3333)) ; update the "state" of the gripper location (cog-value (ConceptNode "gripper hand") (PredicateNode "3D location")) ; Get the current state of the gripper and if you want to use this in PLN/URE/etc, then: (ValueOfLink (ConceptNode "gripper hand") (PredicateNode "3D location"))) which is vaguely like StateLink, except its ... well, different. whatever. This provides an alternative design point for state management and state tracking, but has never moved beyond a proof-of-concept. I really like the concept, but I know that in reality, you have to actually try to build one to see how well it might actually work. -- Linas -- cassette tapes - analog TV - film cameras - you -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA35Ngqvq-c1r-3i_pWxF20vc9FC_1ZTf9tDNqVxZdyenjA%40mail.gmail.com.
