Lately I've been studying Tensor Calculus and how to use tensors for computations in The Harmonic Mind by Smolenksy and Legendre. I find the Harmonic Mind book to give not enough and too much information. They don't seem to assume any prior knowledge in the domain of linear algebra since pp.150-156 gives a tutorial, but as early as page 65 there are concepts introduced that use the material introduced several chapters later. I think they are trying to convince you that the subject is worth studying by showing you that it works without showing you how it works. I find this mode of argumentation to be a waste of time.

Later, in Chapter 8, they finally get into the gritty details of how their system works, but it focuses too much on formalisms. There is an example of how to separate a constituent and its role binding (p. 293-294), however it is extremely elementary. Ideally what I would have liked is one large, concrete example implemented in something like Mathematica, which is well suited to the task. I'm constructing such an example on my own but I have been hampered by ambiguities and thick use of mathematical rather than computational syntax. For instance, on p. 188 filler/role binding is defined as "A x r1 + B x r2" for binding A to r1 and B to r2. The next definition is of recursive embedding: "A x r0 + (B x r0 + C x r1) x r1." Notice how  the indices for r in the first definition are one higher than in definition 2. I spent at least a few hours reading and reading to try and find out how they were different only to figure out that they're not; merely the use of indices is inconsistent. The same inconsistency is found on p. 295.

Overall though I've learned a lot. I have PassiveNet from p. 197 mostly implemented. The bug right now is that I don't have unbinding working quite right.

Since I began studying The Harmonic Mind my General Problem Solver, Regular Expression, and Vague Predicate Semantics projects have been on hold. The Regex compiler doesn't have an implementation of backreferences working inside of lookarounds. What it does have working is variable length lookarounds in both directions, which is something the Perl regex module doesn't do. On the other hand, I'm sure my implementation is slower.

My final goals for my Regex machine is to generalize over strings so that any linear type can be used for matching and then allow the matching machine to be used as a computational device in the sense of "(?{code})" in Perl. The second goal might require me to re-engineer my machine in terms of a proper backtracking state machine, but I would rather not do that since my machine (like Perl's) is more powerful than a finite state machine.

For my GPS I don't have any particular long term goals. It works as far as I wanted it to. I would like to find out if a form of GPS can handle recursive clause structure such as CP. I have had no luck making such a grammar work in my GPS via grammar rewriting. I believe it would require special tags on the grammar to tell the GPS machine to push an empty stack when going into a particular structure, and then pop it when retreating.

Details about my research in vague predicate semantics will remain private for now as I develop the mathematical and computational tools I need. I'm having to start a new line of inquiry since my studies in Tensor Analysis have provided me with fresh tools and ideas. When I feel the material is of a quality worth publishing I have a few academic friends I can call on for help.

On a side note, I believe I have stumbled on a use for tensors for analyzing character abilities in role playing games. Specifically, a character in an RPG game uses multiple "stats", usually just numbers such as "agility", within a system of combat to determine their character's offensive and defensive abilities. Players of such games try to optimize the numbers to maximize their combat abilities. Many simulators exist to assist players in deciding how to develop their characters, but I believe Tensors could give a form of static analysis that is potentially much more powerful.