cmekik / pyclarion Goto Github PK

Add tests testing various conditions for the top-down and bottom-up activation conditions (e.g., missing dimensions/chunks).

This functionality would be useful for reporting and model inspection.

Minimally, this would take the form of a utility function that takes a Structure instance and outputs an adjacency matrix for its Construct instances, with rows corresponding to source constructs and columns corresponding to target constructs. An option to abstract away the details of certain structures by construct type (e.g., subsystems) should also be included.

For reporting purposes, a basic pretty print of the matrix with optional labeling is the minimum. Functionality to export LaTeX code or other display formats would be ideal.

There are several database classes in the library (Chunks, Rules, BLAs), which all have a similar set of core methods. What these classes have in common is a set of mapping-style methods, along with a set of methods that allow for deferred database updates. Considering that more database classes in this general style will likely be added in the future (e.g., to track rule statistics). It may be worth abstracting a general Database class implementing the shared methods.

First of all, thank you for implementing CLARION in Python.

I'm starting a research project using pyClarion to play a video game. I've noticed that from version 0.17 to 0.18 that the top-level directory with examples was renamed to tutorial, but that the breadth of the examples was significantly reduced. notes.md walks through some very high-level and simple usage but assumes the usage of a ccml file and no NACS or MCS. I've been wrestling with pyClarion for a few days trying to figure out how to programmatically create a Store with one chunk composed of a couple features, but I haven't been able to figure out how (or even verify if I have succeeded). I realize that the library is experimental and based off Anatomy of the Mind, but I feel having more resources (outside of a $160, 480 page book) would be an essential part of promoting adoption of pyClarion.

In particular, would it be possible to add more documentation or examples for some of the following please?

• The CCML spec (with some examples)
• How to populate an initial chunk database
• How to populate an initial rule database
• A free-association example (the Alice example)
• A working memory example
• A migration guide to go from 0.17 to 0.18 (so that old examples can be ported to the new modules and classes)
• An acronym guide - looking through the source code, I'm seeing lots of acronyms and abbreviations, which make the code very difficult to understand for someone not intimately familiar with the domain.
• More explanation of using TopDown and BottomUp

I'm not sure how relevant each of the above is to v0.18 anymore. I'd prefer to not use v0.17.1, but there seem to be way more resources for using it.

I also think that one of the most effective forms of documentation is automated tests. This could be an effective way to both document and validate/verify code changes without having to manually update written guides. For example, a test for a free association problem or setting up a Store from a CCML file.

Thank you.

The idea is that we need to come up with a way to handle default in various operations so that it doesn't cause problems:

transform_keys
drop
keep
clip
boltzmann

The language in the comments needs to be cleaned up. There are spelling errors, and sometimes word choice is not correct and misleading.

The reference implementation, as in http://www.clarioncognitivearchitecture.com/downloads.
If not, what are the remaining TODOs?
I can't run the C# version (Mono is too heavy of a dependency on *nix) and would be happy to have the Python version.

If I were to estimate the complexity of the task based on the 6.0.5 version (Java) which is 9348 LOC, it would take a week to fully port it.

As of 31d2c2e, simulating lone subsystems is awkward, as an enclosing agent must be provided.

This is because base.symbols.expand_address() does not support symbolic addresses with the following construct type signatures in its base argument:

("subsystem",)
("subsystem", "features")
("subsystem", "chunks")
("subsystem", "flow")
("subsystem", "terminus")
("subsystem", "updater")

Implementing this feature requires modifiying one or both of base.symbols.expand_address(), base.symbols.PATTERNS.

As of 31d2c2e, we have to do something like this to set up a reinforcement domain:

from pyClarion.components.networks import Reinforcements

rdomain = Reinforcements(
    mapping={
        feature(("r", "A")): ("A", 0),
        feature(("r", "B")): ("B", 0)
    }
)

assert rdomain.features == (feature(("r", "A")), feature(("r", "B")))

This is not ideal, because the mapping is expected to be one-to-one, requires writing out possibly redundant ad-hoc feature definitions, and requires explicitly referencing the lag values of action dimensions (which can be assumed to be 0). The initialization could be clearer and less error-prone.

One solution would be to initialize the domain like this, preserving the tag order in generated features:

from pyClarion.components.networks import Reinforcements

rdomain = Reinforcements(
    name="r",
    tags=("A", "B")
)

assert rdomain.features == (feature(("r", "A")), feature(("r", "B")))

This change automatically enforces the one-to-one requirement and requires typing out only essential information.

Making the change involves:

• rewriting the Reinforcements class
• making adjustments to SimpleQNet
• making adjustments to examples/q_learning.py