|
Record |
Links |
|
Type |
Freeman-Benson, B.N.; Maloney, J.; Borning, A. |
|
Title |
An Incremental Constraint Solver |
Type |
Journal Article |
|
Year |
1990 |
Publication |
Communications of the ACM |
Abbreviated Journal |
|
|
|
Volume |
33 |
Issue |
1 |
Pages |
54-63 |
|
|
Keywords |
constraints, simulation, design, analysis, user interface support, reasoning support, geometric layout, CSP, DeltaBlue, walkabout strength, Agentsheets |
|
|
Abstract |
Constraint programming language do not have the notion of control flow. In contrast to Model-View-Controller change/update mechanism (which is for example exploit in the INSIST simulation system) constraint programming requires no explicit notification messages in the code of the programmer. The focus of interest has shifted from interactive physics programming of ThingLab to user interface construction of ThingLab II. The big conceptual change was in introducing an incremental constraint satisfaction component to overcome the large latency time inherent to the compilation of plans into Smalltalk methods. This effort led to the design, proof and implementation of the delta blue algorithm. In order to achieve an efficient incremental algorithm the set of constraints had to be partitioned in a constraint hierarchy. It appears to be quite natural to differentiate several levels of preference in cognitive processes. Some constraints are pivotal while others are only mildly desired. ThingLab furnishes two basics classes: required constraints, and preferential constraints. The class of preferential constraints is dichotomized further into arbitrary levels of preference. A solution comparator called locally-predicate-better finds plausible solutions at reasonable computational costs. Four basic functions are provided to interface an application with the delta blue algorithm: • add a constraint • remove a constraint • add a variable • remove a variable Possible impact to my work: Even a not too sophisticated communication network of agents is likely to be computation-cost expensive. The incremental nature of refining an application iteratively should be reflected in a constraint model. After all, a user is not willing to accept batch-like behavior (e.g., to “recompile” a dependency network) for each single modification. |
|
|
Address |
|
|
|
Corporate Author |
|
Thesis |
|
|
|
Publisher |
|
Place of Publication |
|
Editor |
|
|
|
Language |
|
Summary Language |
|
Original Title |
|
|
|
Series Editor |
|
Series Title |
|
Abbreviated Series Title |
|
|
|
Series Volume |
|
Series Issue |
|
Edition |
|
|
|
ISSN |
|
ISBN |
|
Medium |
|
|
|
Area |
|
Expedition |
|
Conference |
|
|
|
Notes |
Communications of the ACM |
Approved |
no |
|
|
Call Number |
refbase @ user @ personalACM |
Serial |
8969 |
|
Permanent link to this record |