Docstoc

Comparing Computational Power

Document Sample
Comparing Computational Power Powered By Docstoc
					Abstract State Machines Meet Computational Models

Udi Boker
Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

Abstract State Machines
 Mathematically define algorithms  Simulate every machine step for step

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

2

Computational Models
 Define a computing mechanism  Its machines are defined on top of the common framework  Examples: Turing machines, finite automata, counter machines, …

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

3

The Motivation
 We want ASMs to define computational models  Not a single machine or algorithm, but the general model’s mechanism  The individual machines of the model can then be defined on top of the model’s configuration

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

4

The Gap
 A single machine vs. a framework


ASMs simulate single machines ASMs have no extensionality ASMs have no domains (they have all domains) due to the isomorphism closure

 Extensionality (implemented function)


 Domain of computation


Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

5

In The Literature
 There are many examples in the literature of ASM defining computational models.  There is no general framework, nor analysis:
As a side effect of this – epistemologically significant – generality of the postulates, the application of the Blass and Gurevich proof scheme to established models of computation may yield “abstract” machine models which are more involved than necessary and may blur features which really distinguish different concrete systems. ASM book, 2003
Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

6

Filling the Gap

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

Extensionality - Demands
 There is a domain of computation – input and output domains  The machine has no control over the possible inputs

Input

Computation

Ouput

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

8

Extensionality - Solution
 The signature contains two designated nullary functions named In, Out  There is a specific domain over which the machine is defined  All initial states are the same, except for the value of In  There is exactly one initial state for each domain element e, in which In  e

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

9

Comp. Models - Demands
 Every computational model has its own concepts and building blocks, on top of which its machines are defined.

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

10

Comp. Models - Solution
 All model’s machines share the same signature  All machines share the same ASM program  An ASM state has the following configuration:
Specific machine’s part
Machine’s description: Finitary static data

Computational model’s part
Instantaneous storage: Finitary dynamic data Building blocks (oracles): Infinitary static data

In, Out
Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

11

Examples
 Most examples in the literature fit the framework  Some (improper) exceptions, e.g. with a different ASM program for each simulated machine  Turing machines:
ctl_state := Nxtctl(ctl_state,tape(head)) tape(head) := Write(ctl_state,tape(head)) head := head + Move(ctl_state,tape(head))

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

12

Analysis

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

Conflicts?
 Does the suggested framework conflict with the ASM concepts?  There are four potential issues:
   

In, Out – two specific nullary functions Fixed state configuration Specific domain for the structures Fixed initial state, up to changes in In

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

14

Conflict Resolution – In, Out
 Designated functions are not a problem, and are often used in the ASM approach, e.g. with distributed ASMs (Mod, Self)

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

15

Resolution – State Configuration
 The separation of static and dynamic functions is well established in ASMs  The finitary and infinitary properties are preserved under isomorphism, hence well defined in the ASM approach  The separation of the machine’s part and model’s part is a higher level view, not concerning ASM internals

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

16

Resolution – Specific Domain
 ASM defines an algorithm, operating over all domains.  Every specific run operates over a specific domain


This domain is the interpretation given to the abstract machine’s entities by the user, who views the machine as performing a specific computation.

 The ASM defining a computational model is a general (all domains) ASM, in which we relate only to those runs that apply to the chosen domain
Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

17

Fixed Domain View
Strings
Initial states

Integers

∙∙∙

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

18

Resolution – Fixed Initial State
 As with the domain, the ASM is general  Relating to a fixed view of the elements
Fixed View
Initial states Isomorphic Views

∙∙∙

Summary
 We provide a framework for representing computational models by ASMs  The framework provides a specific configuration, which goes along with the ASM approach  This representation scheme is intended for analyzing properties of computational models, for example effectivenes

Perspectives on the ASM Theorem Berlin, 26-27 Feb 2007

20

Thanks


				
DOCUMENT INFO