Why there seem to be no preferences in preference memory for (id ^attribute value) triples acquired through C input functions ?
From Randy Jones: Working memory elements from I/O are added directly to working memory without going through Soar’s preference mechanism. That’s why they don’t have any preferences. That’s also why production rules can’t make them disappear (say, with a reject preference), because those WME’s just totally bypass the preference process. This is intentional. The idea is that the input link represents “current perception”, and you can’t use purely cognitive processes to “shut off” your current perceptions. If you want to remove things from the input link, you have to make the I/O code remove them. If you want the input link to be under the control of cognition, then your rules have Tcl tell the I/O system (via the output link) to change the values on the input link. The rules cannot do it directly. From Karen Coulter: C Input functions add wmes using the kernel routine add_input_wme, which surgically alters working memory directly. The preference mechanism is not part of this process. Th
Related Questions
- Can the line fault current in amperes rms, which is the first input value in the GPR-Expert program, represent simultaneous multiple phase faults?
- Why there seem to be no preferences in preference memory for (id ^attribute value) triples acquired through C input functions ?
- Where do I get the L-R (Litres/Revolution) value from to input into the MAST?
