Skip to main content
Social Sci LibreTexts

2.12: Implementing Architectures

  • Page ID
    35710
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)

    ( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\id}{\mathrm{id}}\)

    \( \newcommand{\Span}{\mathrm{span}}\)

    \( \newcommand{\kernel}{\mathrm{null}\,}\)

    \( \newcommand{\range}{\mathrm{range}\,}\)

    \( \newcommand{\RealPart}{\mathrm{Re}}\)

    \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)

    \( \newcommand{\Argument}{\mathrm{Arg}}\)

    \( \newcommand{\norm}[1]{\| #1 \|}\)

    \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)

    \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    \(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)

    At the computational level, one uses a formal vocabulary to provide a rigorous description of input-output mappings. At the algorithmic level, a procedural or behavioural vocabulary is employed to describe the algorithm being used to calculate a particular input-output mapping. The functional architecture plays a special role at the algorithmic level, for it provides the primitive operations from which algorithms are created. Thus we would expect that the behavioural vocabulary used for algorithms to also be applied to the architecture.

    The special nature of the architecture means that additional behavioural descriptions are required. A researcher must also collect behavioural evidence to support his or her claim that some algorithmic component is in fact an architectural primitive. One example of this, which appears when the ideas that we have been developing in this chapter are applied to the science of human cognition, is to conduct behavioural experiments to determine whether a function is cognitively impenetrable (Pylyshyn, 1984; Wright & Dawson, 1994). We return to this kind of evidence in Chapter 3.

    Of course, the fundamental difference between algorithm and architecture is that only the latter can be described in terms of physical properties. Algorithms are explained in terms of the architectural components in which they are written. Architectural components are explained by describing how they are implemented by some physical device. At the implementational level a researcher uses a physical vocabulary to explain how architectural primitives are brought to life.

    An implementational account of the logic gates illustrated in Figure 2-1 would explain their function by appealing to the ability of metal wires to conduct electricity, to the nature of electric circuits, and to the impedance of the flow of electricity through these circuits when switches are open (Shannon, 1938). An implementational account of how a vacuum tube creates a relay of the sort illustrated in Figure 2-2 would appeal to what is known as the Edison effect, in which electricity can mysteriously flow through a vacuum and the direction of this flow can be easily and quickly manipulated to manipulate the gate between the source and the drain (Josephson, 1961; Reid, 2001).

    That the architecture has dual lives, both physical and algorithmic (Haugeland, 1985), leads to important philosophical issues. In the philosophy of science there is a great deal of interest in determining whether a theory phrased in one vocabulary (e.g., chemistry) can be reduced to another theory laid out in a different vocabulary (e.g., physics). One approach to reduction is called the “new wave” (Churchland, 1985; Hooker, 1981). In a new wave reduction, the translation of one theory into another is accomplished by creating a third, intermediate theory that serves as a bridge between the two. The functional architecture is a bridge between the algorithmic and the implementational. If one firmly believed that a computational or algorithmic account could be reduced to an implementational one (Churchland, 1988), then a plausible approach to doing so would be to use the bridging properties of the architecture.

    The dual nature of the architecture plays a role in another philosophical discussion, the famous “Chinese room argument” (Searle, 1980). In this thought experiment, people write questions in Chinese symbols and pass them through a slot into a room. Later, answers to these questions, again written in Chinese symbols, are passed back to the questioner. The philosophical import of the Chinese room arises when one looks into the room to see how it works.

    Inside the Chinese room is a native English speaker—Searle himself—who knows no Chinese, and for whom Chinese writing is a set of meaningless squiggles. The room contains boxes of Chinese symbols, as well as a manual for how to put these together in strings. The English speaker is capable of following these instructions, which are the room’s algorithm. When a set of symbols is passed into the room, the person inside can use the instructions and put together a new set of symbols to pass back outside. This is the case even though the person inside the room does not understand what the symbols mean, and does not even know that the inputs are questions and the outputs are answers. Searle (1980) uses this example to challengingly ask where in this room is the knowledge of Chinese? He argues that it is not to be found, and then uses this point to argue against strong claims about the possibility of machine intelligence.

    But should we expect to see such knowledge if we were to open the door to the Chinese room and peer inside? Given our current discussion of the architecture, it would perhaps be unlikely to answer this question affirmatively. This is because if we could look inside the “room” of a calculating device to see how it works—to see how its physical properties bring its calculating abilities to life—we would not see the input-output mapping, nor would we see a particular algorithm in its entirety. At best, we would see the architecture and how it is physically realized in the calculator. The architecture of a calculator (e.g., the machine table of a Turing machine) would look as much like the knowledge of arithmetic calculations as Searle and the instruction manual would look like knowledge of Chinese. However, we would have no problem recognizing the possibility that the architecture is responsible for producing calculating behaviour!

    Because the architecture is simply the primitives from which algorithms are constructed, it is responsible for algorithmic behaviour—but doesn’t easily reveal this responsibility on inspection. That the holistic behaviour of a device would not be easily seen in the actions of its parts was recognized in Leibniz’ mill, an early eighteenth-century ancestor to the Chinese room.

    In his Monadology, Gottfried Leibniz wrote:

    Supposing there were a machine whose structure produced thought, sensation, and perception, we could conceive of it as increased in size with the same proportions until one was able to enter into its interior, as he would into a mill. Now, on going into it he would find only pieces working upon one another, but never would he find anything to explain Perception. It is accordingly in the simple substance, Multiple Levels of Investigation 51 and not in the composite nor in a machine that the Perception is to be sought. (Leibniz, 1902, p. 254)

    Leibniz called these simple substances monads and argued that all complex experiences were combinations of monads. Leibniz’ monads are clearly an antecedent of the architectural primitives that we have been discussing over the last few pages. Just as thoughts are composites in the sense that they can be built from their component monads, an algorithm is a combination or sequence of primitive processing steps. Just as monads cannot be further decomposed, the components of an architecture are not explained by being further decomposition, but are instead explained by directly appealing to physical causes. Just as the Leibniz mill’s monads would look like working pieces, and not like the product they created, the architecture produces, but does not resemble, complete algorithms.

    The Chinese room would be a more compelling argument against the possibility of machine intelligence if one were to look inside it and actually see its knowledge. This would mean that its homunculi were not discharged, and that intelligence was not the product of basic computational processes that could be implemented as physical devices.


    This page titled 2.12: Implementing Architectures is shared under a CC BY-NC-ND license and was authored, remixed, and/or curated by Michael R. W. Dawson (Athabasca University Press) .

    • Was this article helpful?