Towards a Silicon Mind

Motivations & Limits of Silicon Minds

Since the early days of the computer age (late 40's & early 50's), many naively talked of "Big Brains" and "Artificial Intelligence" or AI. The extreme naivete of such talk is quite apparent from the advantage of today's knowledge of both computers & biology. Unfortunately the disappointing track record of AI during the last six decades throws a disreputable light over any attempt to investigate the feasibility of non proto-plasma based minds.

It is also true that the workings of brains, especially human brains, are still largely "terra incognita". Both of these factors are hurdles but not iron clad prohibitions for the exploration of possible alternative mind's substrates. There are, in fact, two significant factors that justify exploring such possibilities. The first & foremost is the emergence, in the last few decades, of a robust software engineering technology for handling abstractions. Secondly the very significant advantages that would accrue to such eventual mind technology.

Abstractions as Building Blocks

The mind's alternative substrate problem can be restated very clearly & concisely in terms of software Engineering (SE) abstractions as:" design & implement information processing systems that can formulate their own abstractions in response to environmental stimuli. We will explore next possible approaches that could lead to such systems.

Capturing an Abstraction

The most basic process for such silicon mind (SM) is the observation, parsing & recognition (OPR) process. Once an SM perceives an entity in its field of "vision" it must scan it into the entity's components & subcomponents. This scan should be documented in a data structure (DS) showing, in its fields, all the direct attributes of the entity, as well as, its subcomponents. The latter ones could be represented by either a name or an address of a subcomponent DS. That is the entity's DS fields will be either values or subcomponents identifiers. The latter can be either an address or a name. The recognition part of OPR could very well be performed by matching the DS under construction against the library of the system's known abstractions. If a match is discovered at any subcomponent level the library version is used as a replacement. The recognition process should proceed bottom up replacing known DSs whenever possible. If matches are found at all levels the entity is completely recognized. If at some level recognition fails this signals the need for extending the system's DS library.

Virtually all of the subtasks of the OPR process are doable with currently available technology. The area where new technology may be required is parsing an entity into subcomponents. The recognition phase may also require new technology. However, effective parsing coupled with extensive libraries of "known" abstractions should, in most cases, allow effective recognition to take place. This means that the building and sharing of exhaustive libraries of abstractions by a population of SMs is a key factor in bootstrapping of non proto-plasma intelligence. The bootstrapping in question can &will take place via two mechanisms: firstly, as a community wide accumulation & dissemination of effective abstraction libraries. Secondly, as teaching & learning to & by the individual SM.

The obviously helpful recognition role of "known" abstraction libraries suggests that further research on the behavior of large libraries could show that intelligence is an emergent property of such libraries. If this turns out to be the case the next question is "do any forms of intelligence have to rely on a library bootstrapping process?". If the last question is always answered in the affirmative then one has to inquire as of the nature of such bootstrap process in the case of human intelligence. Clearly the leading candidate, in the human case, is the language acquisition process. We will explore below the relationship between abstractions and language.

Abstracting a Concept

Understanding the Object Oriented Database (OODB) notions is key to appreciate the argument below. The link OODB supplies the key concepts & terminology. The terminology used in this reference is identical to that used in this note except for exchanging the term "abstraction" for the term "object".

The representation of an entity can take the form of a list of the entity's own direct attributes and a list of links to the entity subcomponents' representations. This form of representation is said to be the normalized representation. The normalized form explicitly & clearly shows the entity's architecture. In other words, as Christopher Alexander said in the 70's, the entity dissolves in a pattern of relationships. As such the normalized form highlights the entity's intrinsic structural properties (architecture).

The normalized form's links can take two forms: a) a component's name or handle, b) a component's address. Distinguishing between them is important in Software Engineering (SE), but not significant in this discussion since it is premature to discuss implementation issues.

The attributes of an entity description can be undefined. An undefined attribute is one whose "value" will be determined at some later time from a range of potential values. For example in describing the entity "column" we could leave the attribute "Capitel" undefined, that is, to be selected in a subsequent development stage out of the range [of values]: Corinthian, Ionic & Doric. An entity's description which has all attributes defined is said to be a concrete description. A description which has all attributes undefined is said to be an abstract description. The most frequent case is that the description has some defined attributes & some undefined ones. In that case the description is said to be partially abstracted.

A description which has some undefined attributes is capable of representing a class of entities. Namely all the entities that share all the defined attributes and are obtained by substituting the admissible values for its undefined ones. For example the entity chair can be viewed as composed of: back rest; seat; leg1; leg2; leg3; etc.. components. Its normalized form would comprise the following links: back; seat; leg1; leg2 ;leg3; leg4. If the links "point" to concrete descriptions, then we are describing a specific chair. If any or all of the links point to undefined components then we are describing ,more or less, extensive classes of chairs. Notice that the fully normalized description of chair with links all pointing to undefined components describes the class of all chairs. This class is said to be an abstract class. Classes obtained from descriptions with some undefined entries are said to be partially abstract classes. Notice, further that the fully normalized & abstracted description of a class , namely the abstract class, contains only structural or architectural information shared by all entities represented by the class.

Class definitions can be made more specific, that is, including fewer members, by adding attributes to the class definition. The new class, so derived, is considered a member of the inheritance hierarchy of the original class. In other words, any class definition can be considered the root of a tree of derived inheritance hierarchy or taxonomy. The inheritance in question consists in the fact that offspring classes inherits some or all of its parent attributes (& methods as we shall see in the next section). More on inheritance hierarchies can be found at class inheritance.

It is easy to define a SM recognition process as the following two major steps: a) construct the DS of the observed entity; b) find the highest root of the inheritance class the DS belongs to. Step a) starts by parsing the entity in its subcomponents. Step b) is then performed for each subcomponent. If the sub is terminal this step will result in the recognition of the component. If not the sub is parsed onto its subs & the procedure recurses. For example, if SM "sees" a chair. its initial parsing will find that typically the DS will have six subcomponents. Performing step b for each of the six subs, & assuming that the notions of leg, seat, back are represented by corresponding sufficiently broad (abstract) classes, these steps b) will result in recognizing that the DS on hand parses into (back; seat; leg; leg; leg; leg). This representation will be immediately recognized as the DS of the abstract class Chair. So the SM will understand that it is "seeing" a chair.

The nexus with linguistic is readily found by recognizing that a DB of abstractions capable of going "critical" will include hundreds of thousands, if not millions of classes. Retrieval from such huge DB will be greatly aided if each distinct class is given a handle or name. That is, nouns in languages most likely correspond or retrieve associated class definitions. If this supposition is true, then it would follow that any species capable of mind would develop language.

####

Abstracting an Action

#####

Copyright sire.com 2010