Boilerplate

A good way to speed up the writing of scientific publications is the use of boilerplate.  People have mixed feelings about this practice.  When I was doing plasma physics boilerplate might include:

1. a diagram of the experimental machine
2. a table of typical operating parameters/conditions
3. a paragraph or two describing the device and its operation
4. a paragraph or two describing the plasma diagnostics used

These would change from one publication to the next only if the device or values really did change or if one could in some way improve the boilerplate.

I have had one or two people criticize this practice as somehow "cheating."  I disagree completely.  If one can refer to an earlier paper to present such information fine, dispense with the boilerplate.  But to the extent that a given publication is to be selfcontained then boilerplate may actually serve as quality control.  (Again, so long as it is kept current.)

Most plasma fusion work will at least have a diagram of the machine and a paragraph describing it.  The cost of such machines is so high that they and their descriptions will not be changing from one paper to the next.

If, for some reason, one were to do the same experiment over and over but with a different fill gas, lets say, each publication might then be much like the one before it.  I know of people who do spectroscopic work (not plasma physics) where this has been common.

I've known a number of scientists who would create a talk/presentation by selecting slides from a collection they had assembled (supplemented by any new results recently obtained).
It is not cheating to work smart.

Scalar utility

Asa H 2.0 has been run with both scalar and vector utilities.  An example of a scalar utility is Asa H 2.0 light (blog of 11 Feb. 2011).  In that code the utility (of the case) is the total time during which that particular pattern (case) has been observed. (a product of the time duration/length of the case and the number of times the case has occurred)

Vector intelligence again

In their paper "Fractionating human intelligence" (Neuron, 19 Dec. 2012) Hampshire, Highfield, and Owen offer evidence that IQ can not be described by a scalar quantity but requires at least 3 (vector) components.

Natural language versus mentalese

Natural languages are sequential, we can only say or write one word at a time.  Language of thought (mentalese) is, at least in part, parallel, non-sequential.  The brain is a parallel distributed processor.  Many concepts are activating one another across the brain simultaneously.  Humans must teach one another sequentially, they are using natural language.  Robots could transfer data to one another in parallel.

Symbol grounding

I agree with Werbos' definition of intelligence, "a system to handle all of the calculations from crude inputs through to overt actions in an adaptive way so as to maximize some measure of performance over time" (IEEE Trans. Systems, Mind , and Cybernetics, 1987, pg 7).  A brain is a control system.  In any artificial intelligence all symbols (internal representations) are then surely grounded in so far as they functionally connect sensory and utility/value inputs with outputs/responses. But in deep (complex) networks some symbols will be far removed from primitive/raw perceptions. i.e., more "abstract" concepts.

What thoughts are made up of

In their paper "what thoughts are made of" (in Embodied Grounding, edited by Gun and Smith, Cambridge U. Press, 2008, pg 108) Boroditsky and Prinz detail a view of the nature of thought which is very similar to my own (as it occurs in my artificial intelligence, Asa H).  They also suggest that teaching an agent a natural language (as I have been doing with Asa H) may enhance the agent's level of intelligence.

One difference is that Boroditsky and Prinz discuss representations (of concepts) in terms of feature lists whereas I employ vectors and allow each feature (vector component) to have variable activation.

Repressed memories in Asa H

The performance elements of Asa prefer cases having high utility.  Forgetting/deleting cases with low utility speeds up search.  Additional low utility cases ("repressed" memories) can be retained for use (in a larger "augmented" casebase) by the learning element.  Knowing what NOT to do is useful there.

When a vector utility is employed we prefer to delete cases from the more densely populated regions of the case vector space.  Also, if a case has a single vector component that is high we prefer to retain it.