Keith A. Pray - Professional and Academic Site
About Me
·
·
·
LinkedIn Profile Facebook Profile GoodReads Profile
Professional
Academic
Teaching
                                          
Printer Friendly Version

Intro ] [ 29-ML Survey ] [ 30-Strain Gauge ] [ 31-Grammar ]

Up: AI in Design ]

Critique: Compiling Design Plans from Descriptions of Artifacts and Problem-Solving Heuristics
Araya, Mittal *

      While a reasonable justification is given for making an analogy between knowledge compilation and computer language compilation, it would have been nice to see acknowledgment of the opposing opinion that the two have very little in common. One alternate point of view is that knowledge compilation often takes a very specific, all encompassing source of knowledge and extracts the pieces that only pertain to a certain task, often abstracting the knowledge so it applies to a set of problems. Computer language compilation on the other hand takes a high level language and translates it into a very specific, exact representation for use on a particular platform. Also, the problems solved or tasks carried out by the compiled program are no different from those intended by the higher level representation.

      It was interesting to see that a common aspect of design systems that incorporate learning is the profuse use of cross-indexing various pieces of information in the representation. One example is Keller's compiling redesign plans work where all quantities kept a list of equations they appeared in. This is analogous to the theory of human intelligence that suggests much of the information processing capability and creativity the people exhibit is largely a function of the presence of a highly connected memory system. Creating connections between different pieces of knowledge is a form of learning or discovery. It is no surprise that machine learning systems tend to have more indexing than non-learning systems.

      I am not completely convinced that a distinction must be made between "always-relevant" parameters and "possibly-relevant" parameters. It seems to complicate the system more than it is worth. Since always-relevant parameters are simply those that are used to specify constraints on the functionality of the thing to be designed, they would be easily identified at run time.

      I thought it odd that with the capability of generating design plans automatically there was no mention of a method for choosing a design plan automatically given a new problem. Is the system simply going to generate a new plan for every new problem? I don't think so. With the automation of design plan creation, one would expect there to be many more design plans to choose from.


* Agustin A. Araya & Sanjay Mittal, Compiling Design Plans from Descriptions of Artifacts and Problem-Solving Heuristics. Proc. Int. Jnt. Conf. on AI, IJCAI-87, 1987, pp. 552-558.

Intro
01-DPMED
02-Dominic
03-DSPL Air-Cyl
04-Pride
05-COSSACK
06-MICOM-M1
07-Configuration Survey
08-Dynamic CSP
09-MOLGEN
10-Failure Handling
11-VT
12-Conflict Resolution
13-Cooperative Negotiation
14-Negotiated Search
15-Multiagent Design
16-Prototypes
17-CBR Survey
18-PROMPT
19-A Design
20-Bogart
21-Cadet
22-Argo
23-Analogy Creativity Survey
24-Algorithm Design
25-AM
26-Edison
27-LEAP
28-Plan Compilation
29-ML Survey
30-Strain Gauge
31-Grammar
32-Config GA
33-Functional First
34-Functional CBR
35-Functional Survey
36-Models
37-First Principles
38-Config Spaces
39-Task Analysis

by: Keith A. Pray
Last Modified: August 13, 2004 8:02 PM
© 2004 - 1975 Keith A. Pray.
All rights reserved.

Current Theme: 

Kapowee Hosted | Kapow Generated in 0.01 second | XHTML | CSS