**AM:** Why do you need XOR in your inquiry system?

Clearly we need a way to represent exclusive disjunction, along with its dual logical equivalence, in any calculus capable of covering propositional logic, so I assume this is a question about why I chose to represent those two operations more compactly with cactus graphs instead of using trees and defining them in terms of conjunctions and negations.

The generalization from trees to cacti presented itself at the point where multiple lines of problem-solving effort converged. Some of the problems were conceptual, arising from a desire to include the types of operator-variables that Peirce considered. Other problems were computational, provoked by a need to avoid combinatorial explosions in the evaluation of logical formulas.

But, as I remarked earlier, “the genesis of that generalization is a tale worth telling another time …”, after we have gotten a better handle on the basic logical issues.

Re: Peirce List Discussions • (1) • (2)

Theme One puts cactus graphs to work in three distinct but related ways, called *lexical*, *literal*, and *logical* uses, and these applications make use of three distinct but overlapping subsets of the broader species of cacti. Thus we may find ourselves speaking of expressions, graphs, or files of lexical, literal, or logical types, depending on our focus and point of view at a given moment.

Logical cacti are the most inclusive class, encompassing the whole species of structures described above, and so we have already seen a typical example of a logical cactus, in its avatars as an abstract graph, a pointer structure, and a string of characters suitable for storage in an external text file.

But being a logical cactus is not just a matter of syntactic form — it means being subject to meaningful interpretations as a sign of a logical proposition. From a logical perspective we expect our cactus expressions to *express* something, to represent a proposition that can be true or false of something.

For present purposes it will speed things along to skip the discussion of lexical and literal cacti and jump right to the logical and semantic interpretation of cactus graphs. Readers seeking immediate enlightenment about the details may peruse the outline of notes given below. My next post will take up the discussion at Note 13.

- Lexical Cacti • Notes (6) • (7) • (8) • (9) • (10)
- Literal Cacti • Notes (11) • (12)
- Logical Cacti • Notes (13) • (14) • (15) • (16)

Re: Peirce List Discussions • (1) • (2)

We have seen how to take an abstract logical graph of a sort a person might have in mind to represent a logical state of affairs and translate it into a string of characters a computer can translate into a concrete data structure.

Now we look a little more closely at the finer details of those data structures, as they work out in this particular sequence of representations.

It is possible to write a program that parses cactus expressions into fairly close facsimiles of cactus graphs as pointer graph structures in computer memory, doing this in such a way that edges correspond to addresses and nodes correspond to records. I did exactly that in early forerunners of the present program, but it turned out to form a more robust strategy in the long run, in spite of the seemingly exorbitant investment in nodes at the outset, to implement a more articulate but more indirect type of parsing algorithm, one in which the punctuation marks are not just tacitly converted to addresses in passing but recorded as nodes in roughly the same way as the ordinary identifiers, or *paints*.

Figure 3 illustrates this type of parsing algorithm, showing the form of pointer graph that results from parsing the cactus expression in Figure 2. A traversal of this graph naturally reconstructs the cactus string that parses into it.

o-----o o------|--o | | o---o | | o->| ) |--o | o---o | ^ o-----o | / o-----o o-----o o--------------------|-/----|--o | o-------------|--o | | o---o o---o o---o< o---o | | | o---o o---o | | o->| a |->| , |->| ( |->| ) |--o | o->| d |->| ) |--o | o---o o---o o---o o---o | o---o o---o | ^ o--------------------------o ^ o------------o | / | / o-----o o------|-/----------------------------------|-/------------------|--o | | o---o< o---o o---o o---o o---o o---o< o---o o---o o---o | | o->| ( |->| , |->| b |->| c |-->| , |-->| ( |->| b |->| e |->| ) |--o | o---o o---o o---o o---o o---o o---o o---o o---o o---o | ^ o---------------------------------------------------------------o | / o------|-/---------------------o | o---o< o---o o---o o---o | o->| ( |->| a |->| c |->| e |--o o---o o---o o---o o---o ^ | @ ( ( a , ( ) ) , b c , ( d ) b e ) a c e Figure 3. Parse Graph and Traverse String

A pointer graph of the type shown in Figure 3 has the underlying form of a cactus graph and will normally be convenient to describe in those terms, so long as we remember its level of abstraction lies a step further in the direction of concrete implementation than the last thing we called by that name.

Re: Peirce List Discussions • (1) • (2)

My earliest experiments with coding logical graphs as pointer data structures taught me that conceptual and computational efficiencies of a critical sort could be achieved by generalizing their abstract graphs from trees to the variety graph theorists call *cacti*. The genesis of that generalization is a tale worth telling another time, but for now it makes a quicker start to proceed by way of generic examples.

Figure 1 shows a typical example of a *painted and rooted cactus*.

o a | d o---o o \ / b c | o----o----o b e \ / \ / \ / \ / @ a c e Figure 1. Painted And Rooted Cactus

Figure 2 shows a way to visualize the correspondence between cactus graphs and cactus strings, demonstrated on the cactus from Figure 1. By way of convenient terminology, the polygons of a cactus graph are called its *lobes*. An edge not a part of a larger polygon is called a *2-gon* or a *bi-gon*. A terminal bi-gon is called a *spike*.

o a (|) d o---o o (\ /) b c (|) o--,--o--,--o b e \ / \ / ( \ / ) \ / \ / @ a c e ( ( a , ( ) ) , b c , ( d ) b e ) a c e Figure 2. Cactus Graph and Cactus Expression

The correspondence between a cactus graph and a cactus string is obtained by an operation called *traversing* the graph in question.

- One traverses a cactus graph by beginning at the left hand side of the root node, reading off the list of paints one encounters at that point. Since the order of elements at any node is not significant, one may start the cactus string with that list of paints or save them for the end. We have done the latter in this case.
- One continues by climbing up the left hand side of the leftmost lobe, marking the ascent by means of a left parenthesis, traversing whatever cactus one happens to reach at the first node above the root, that done, proceeding from left to right along the top side of the lobe, marking each interlobal span by means of a comma, traversing each cactus in turn one meets along the way, on completing the last of them climbing down the right hand side of the lobe, marking the descent by means of a right parenthesis, and then traversing each cactus in turn, in left to right order, that is incident with the root node.

The string of letters, parentheses, and commas one obtains by this procedure is called the *traversal string* of the graph, in this case, a *cactus string*.

Re: Peirce List Discussions • (1) • (2)

Discussion arose in the Laws Of Form Group about computational explorations of George Spencer Brown’s calculus of indications.

Readers of Peirce are generally aware that Spencer Brown revived certain aspects of Peirce’s logical graphs, focusing on the Alpha level interpretable for Boolean Algebra and Propositional Calculus but adding some hints of potential extension and generalization. He used what amounts to Peirce’s *entitative* interpretation of the graphical forms in his exposition but was clear about the abstract character of the forms themselves, as evidenced by their admitting dual interpretations, dubbed “entitative” and “existential” by Peirce.

In computational context the question naturally arises how to code the abstract formal structures used by the calculi of CSP and GSB into the relatively concrete forms that a computer can process.

I began my response to that question as follows …

*To be continued …*

Programs are algorithms that operate on data structures (Wirth). How do we turn abstract graphs like those used by C.S. Peirce and Spencer Brown into concrete data structures that algorithms can manipulate? There are many ways to do this, but one very efficient way is through the use of “pointer data structures”.

The full documentation of my Theme One Program is still in progress, but here’s a link to a page of exposition, describing the family of graphs used in the program, how to code the graphs as strings of parentheses, commas, and letters, and how the program parses the strings into pointer structures that live in computer memory.

Here’s a link to a suitable point of entry for our present purpose:

Figure 1 depicts a typical example of a *painted and rooted cactus* (PARCA).

o a | d o---o o \ / b c | o----o----o b e \ / \ / \ / \ / @ a c e Figure 1. Painted And Rooted Cactus

The graph itself is a mathematical object and does not inhabit the page or other medium before our eyes, and it must not be confused with any picture or other representation of it, anymore than we’d want someone to confuse us with a picture of ourselves, but it’s a fair enough picture, once we understand the conventions of representation involved.

Let be the set of nodes in a graph and let be a set of identifiers. We very often find ourselves in situations where we have to consider many different ways of associating the nodes of with the identifiers in Various manners of associating nodes with identifiers have been given conventional names by different schools of graph theorists. I will give one way of describing a few of the most common patterns of association.

- A graph is
*painted*if there is a relation between its node set and a set of identifiers, in which case the relation is called a*painting*and the identifiers are called*paints*. - A graph is
*colored*if there is a function from its node set to a set of identifiers, in which case the function is called a*coloring*and the identifiers are called*colors*. - A graph is
*labeled*if there is a one-to-one mapping between its node set and a set of identifiers, in which case the mapping is called a*labeling*and the identifiers are called*labels*. - A graph is said to be
*rooted*if it has a unique distinguished node, in which case the distinguished node is called the*root*of the graph. The graph in Figure 1 has a root node marked by the “at” sign or*amphora*symbol “”.

The graph in Figure 1 has eight nodes plus the five paints in the set The painting of nodes is depicted by drawing the paints of each node next to the node they paint. Observe that some nodes may be painted with an empty set of paints.

The structure of a *painted and rooted cactus* (PARC) can be encoded in the form of a character string called a *painted and rooted cactus expression* (PARCE). For the remainder of this discussion the terms *cactus* and *cactus expression* will be used to mean the painted and rooted varieties. A cactus expression is formed on an alphabet consisting of the relevant set of identifiers, the *paints*, together with three punctuation marks: the left parenthesis, the comma, and the right parenthesis.

I started learning programming about the same time I first ran across C.S. Peirce’s Logical Graphs and Spencer Brown’s Laws of Form in the late 60s and naturally tried each new language and each new set of skills I learned on writing processors and theorem provers for the propositional calculus levels of their graph-theoretic formalisms. Using previous work I had done in Lisp, I spent the 80s developing a series of Pascal programs that integrated aspects of sequential learning with aspects of propositional reasoning over an extension of the CSP–GSB systems. I applied the program to a selection of observational data sets from one of my advisor’s research projects and got an M.A. in Quantitative Psych out of it. People looking for contemporary applications of the general Peircean paradigm may find some of the directions in this work of interest.

The following blog post updates a list of links to what documentation and exposition I’ve put on the web so far.

]]>- Theme One Program • Pascal Source Code
- Theme One Program • User Guide
- Theme One Program • Exposition

- Applications of a Propositional Calculator : Constraint Satisfaction Problems
- Exploratory Qualitative Analysis of Sequential Observation Data

- Awbrey, S.M., and Awbrey, J.L. (May 1991), “An Architecture for Inquiry : Building Computer Platforms for Discovery”,
*Proceedings of the Eighth International Conference on Technology and Education*, Toronto, Canada, pp. 874–875. Online. - Awbrey, J.L., and Awbrey, S.M. (January 1991), “Exploring Research Data Interactively : Developing a Computer Architecture for Inquiry”, Poster presented at the
*Annual Sigma Xi Research Forum*, University of Texas Medical Branch, Galveston, TX. - Awbrey, J.L., and Awbrey, S.M. (August 1990), “Exploring Research Data Interactively • Theme One : A Program of Inquiry”,
*Proceedings of the Sixth Annual Conference on Applications of Artificial Intelligence and CD-ROM in Education and Training*, Society for Applied Learning Technology, Washington, DC, pp. 9–15. Online.

I finally finished retyping the bibliography to my systems engineering proposal that had gotten lost in a move between computers, so here is a link to the InterSciWiki copy:

This may be of interest to people working towards applications of Peirce’s theory of inquiry, especially the design of intelligent systems with a capacity for supporting scientific inquiry.

The role of acquired knowledge bases in inquiry, learning, and reasoning is discussed in the following article and sections.

]]>