THE DESIGN PROBLEM SOLVER

A SYSTEM FOR DESIGNING EQUIPMENT ORF URNI T URE LAYOUTS_',

byChar]es E. Pfefferkorn

September ] 972

Computer Sciences Department

Mathemat{cal Sciences Building

Purdue University

West Lafayette, Indiana 47907

*The research described in this paper is based on the author's thesis re-

search (Pfefferkorn 1971). The author is greatly indebted to his thesis advisorDr. Herbert Simon and the other members of his thesis committee, Mr. Charles

Eastman, Dr. Raj Reddy, and Dr. Allen Newell for their help and suggestions.

*While at Carnegie-Mellon University (Pittsburgh, Pa), this research was supported

in part by the Advance Research Projects Agency of the Office of the Secretary ofDefense (F44620-70-C-0107) which is monitored by the Air Force Office of ScientificResearch.

9/10/72 Pfefferkorn

Abstract

The Design Problem Solver (DPS) demonstrates that the computer can perform

simple design tasks. In particular, it designs furniture and equipment layouts.

This task was chosen because it is simple, well defined, and characteristic of

many design tasks in architecture, engineering, urban planning, and natural

resource management. These space planning tasks usually involve manipulating

two-dimensional representations of objects, to create feasible or optimal

solutions for problems involving topological and metric spatial constraints.

DPS is a heuristic problem solver with a planning phase prefixed to it.

It uses the planning process to give it a sense of direction, diagnostic pro-

cedures to locate difficulties, and remedial actions to recover from difficulties.

It uses a convex polygon representation to accurately describe the objects and

the layout. This representation allows topological and metric constraints to be

tested and the design to be easily updated.

While DPS is slow and limited in scope, the ideas behind it are general. It

demonstrates the need for selectivity in controlling search, and demonstrates how

to achieve it by using task specific information, planning, diagnostic procedures,

remedial actions, and selective alternative generators.

Ke[words: Artificial Intelligence, Computer-Aided Design, Design Synthesis,

Diagnostic Search, Heuristics, Planning, Problem Solving, Representations,

Search Strategies, Space Planning, Spatial Representations.

9/I O/7 2 Pfe fferkorn1

1.0 Introduction

To modify his environment, man has developed a wide variety of problem-

solving activities referred to as "design". To investigate the possibility

of using the computer as a designer, the Design Problem Solver (DPS) was

written. It designs furniture or equipment layouts.

This task requires placing objects in a room while satisfying a set of

given constraints. The objects for an office might be desks, tables, file

cabinets, and bookcases. The objects for a computer room might be the computer,

its memory modules, and its I/0 equipment (magnetic tapes, card readers, printers,

etc.). The constraints require that physical objects occupy independent regions

of space, access areas be accessible, and path, view and distance constraints

be satisfied. Figure I.1 gives a few examples of constraints which may be re-

quired. Figures 1.2 and 1.3 show sample problems and their solutions. The task

is well specified: place the given objects in the room satisfying given constraints.

This task was chosen because it is relatively simple, well defined, and

characteristic of many design tasks in architecture, engineering, interior

design, and urban planning, which require manipulating two-dimensional representa-

tions of objects to create feasible or optimal solutions to problems with a set

of metric and topological spatial constraints. Eastman (1970 and 1970) refers

to these design tasks as space planning problems.

The objective of this empirical research was to identify key technic.al

problems, to purpose tentative solutions, to provide guidance in building future

design systems, and to suggest areas requiring further research.

i.i Representation

While human designers can solve design tasks by manipulating the physical

objects used to complete the actual design, they usually solve an abstract

version. In furniture or equipment layout problems, the designer (architect,

engineer, or interior designer) usually avoids the effort and cost of moving

the physical objects by using a simple model to represent the solution: pencil

sketches, engineering drawings, small cutouts on a floor plan, or even miniature

copies of the objects on a floor plan.

The human designer must also select the constraints to use. Often the

constraints a_e buried in the external environment, or in the designer's store

9/i0/72 P fefferkorn2

of general knowledge. In either case, the designer must retrieve and apply them

to the current problem. Poor solutions are frequently caused by a designer

using the wrong constraints. Examining a designer's solution is also difficu'It

because he seldom explicitly specifies the constraints he is using. Disagreement

over the merits of a particular design often implicitly involves a disagreement

over which constraints should be used to evaulate the design.

If the computer is to solve design problems, it must have computer representa-

tions of the task which it can search and modify. DPS required both a spatial

representation and a constraint representation. Its constraints were explicitly

defined to avoid the problem of retrieving the correct constraints from context

(the problem environment and definition).

i.2 Problem-Solving

If the computer is to solve a design problem, it must have a model of the

design process, as well as, an abstract representation of the task. One

possibility is to set design problems up as mathematical optimization problems.

This technique requires forcing the original design problem into a form which

can be solved by existing optimization techniques. This can be extremely

difficult even for simple space planning tasks.

An alternate approach is to use techniques developed from examining human

problem-solving activities. The heuristic search method which is the basis of

numerous existing artificial intelligence programs offers a viable alternative.

In this model, problem solving is characterized as a process of search through

a tree whose nodes are situations and whose branches are operations that trans-

form one situation into another. A solution in this model is a path which

leads from the initial situation to a goal situation. This model and its

applications are described in several places including Newell (1969), Newell

and Ernst (1965), Newell and Simon (1972), Nilsson (1971), and Slagle (1971).

To implement a design problem using this model requires providing a set

of operators and a representation of the initial problem which can be transformed

into a final situation (solution) by applying the given operators. In DPS, the

9/10/72 Pfefferkorn3

the initial situation is a list of empty rooms (usually one), a list of objects

to enter the rooms, and a set of constraints to be satisfied. The steps be-

tween the initial situation and the final situation consist of partial layouts.

The basic operation to get from one step to the next is to enter an object in

the layout. The desired situation is a layout containing the required objects

and satisfying the given constraints.

In most problem solving situations, including design, the_tree of possible

solutions (generated by applying the basic operators to the initial situation and

all situations created from it) is immense. Because the size of this search space

prohibits simple exhaustive techniques (in most cases) a search strategy must

be developed which allows enough of the space to be searched to find an adequate

solution. To minimize the number of branches created in finding a path to a

desired solution node, the problem solver must be extremely selective in deter-

mining what branches to create (which node to expand and which operator to use

in expanding it). When making these decisions the problem solver has two forms

of information available: (I) information which is available when the problem

is defined, and (2) information that becomes available as the search for a

solution proceeds.

In DPS, the initial information available includes the description of the

objects, the rooms which the objects are to enter, and the constraints which

must be satisfied. The information generated as the design progresses includes

the current layout, the partial-design tree (the past history of DPS's search

activity) and the statue of the different constratints (satisfactory, unsatis-

factory, inactive or ready to be evaluated).

1.3 Organization of this Paper

Numerous decisions must be made in building a design system. These deci-

sions are discussed by describing DPS in sections 2 and 3 and by analyzing

it in sections 4 and 5. Section 2 describes the task representation used by

DPS: spatial representation (2.1), constraint representation (2.2), and

design description (2.3). Section 3 describes the structure of DPS; search

strategies (3._, main problem-solving functions (3.2 to 3.7), and the book-

keeping functions (3.8).

Pfefferkorn

4

DPS was written in LISP-I.5 and applied to solving a variety of space

planning tasks. Section 4 examines the results of running the different

examples while section 5 examines the major features of DPS and suggests how

to extend them. Section 5.8 compares the original objectives and the

results and suggests futher areas of research.

Pfefferkorn5

2.0 Design Representation

DPS's problem representation consists of three interrelated parts. The

spatial representation describes the objects and the layouts in terms of convex

polygons consisting of sides and points. The constraint representation describes

the relations required between the objects and the properties required of the

layout. It also provides the linkage between the problem-solving function of

DPS and the constraint evaluation functions. The design description describes

the initial problem, the current status of the design, and the final solution,

if one is generated. It includes pointers to the objects and their descriptions.

It also includes the partial-design tree and the current layout description.

The different components of the design description are represented by

LISP atoms and described by property lists. The values of the attributes of

these lists are often lists of other atoms that in turn have property lists.

These lists provide the different access paths through the design description

used by DPS.

2.1 Spatial Representation

A space planning design system requires a Spatial representation and its

associated routines to be able to represent and manipulate the design descrip-

tion to test constraints, and to advance the design. In DPS, this requires

spatial operators to translate and rotate objects, to find positions for them,

and to enter them in the design. It also requires routines to handle adjacency

information, find different types of space, and to construct boundaries of

different regions of space.

In the convex polygon representation, the objects and layout are represented

as sets of convex polygons called space blocks. Each space block is in turn

represented as a set of sides, and each side as a set of points. Each element

(object, space block, side, or point) is represented by a LISP atom and is

described by the atom's property list.

Pfefferkorn

6

The property list consists of a set of attributes with a set of associated

values. The property list of a point usually contains three attribute-value

pairs. The attributes are TYPE, XCORD, and YCORD. Where the value for TYPE is

POINT, a point is being described. The values for XCORD and YCORD are the x-

and y-coordinates of the point. Figure 2.1 contains the basic spatial repre-

sentation elements, their respective attributes, and a brief description of the

values associated with each attribute.

Figure 2.2 demonstrates the relation between the external engineering

drawing and the internal computer representation. Figure 2.2a shows an

engineering drawing used to describe a computer magnetic tape unit. Figure

2.2b shows an engineering drawing of the approximated unit to be used by DPS.

Figures 2.2c and 2.2d give schematic views of the internal representation of

the tape unit using arrows to indicate the different interconnections.

2.1.1 Placing Objects

To create a new partial-designs (nodes in the search tree), DPS must find

a likely position for the entering object and then place it there. Likely

positions include placing objects in corners of available space and next to

other objects. To assist in finding these positions, Spatial representation

operators exist for creating lists of contiguous space blocks (convex polygons),

boundaries of contiguous space blocks, and corners of boundaries. These

operations use the adjacency information explicityly stored in the spatial

representation. To move objects into position, the translation and rotation

spatial representation operators are used to modify the x- and y-coordinates

of the points describing the object.

2.1.2 Enter Objects

To emplement an alternative position (enter an object in the layout), the

layout must be updated. This can be visualized as pressing a copy of the object

into the layout (Figure 2.3). The ENTER.OBJECT routine accomplishes this by

entering one space block of the object at a time. The sides of this space block

Pfefferkorn

7

are processed in counterclockwise order. Each layout space block which the

current incoming side intersects is broken into two separate space blocks.

The old layout space block is replaced by two new space blocks. Note that

the layout has changed, and that the next side of the incoming space block may

divide one of the new blocks just constructed.

The new blocks are constructed by forming two lists of points: one for

the old layout space block points to the left of the incoming side and one for

the points to the right of it. Each of these lists also receives the two inter-

section points of the extended incoming side and the old layout space block.

These lists are then used to create the sides of the two new space blocks.

If requested, adjacency information is updated each time a layout space

block is dividbd. The adjacency information is transferred from the sides of

the old layout space block to the sides of the new space blocks. The sides of

the old space block which are broken up require special processing. Since each

side of each layout space block is adjacent to one and only one other side, the

layout space blocks adjacent to the old layout space block may have to be modi-

fied to keep the one-to-one relationship. This one-to-one relationship is

required to simplify routines used in constructing boundaries of regions of space.

Since ENTER.OBJECT only modifies layout space blocks which intersect in-

coming space block sides, it is desirable to discard other layout space blocks

as quickly as possible. To do this, each object and space block has a rectangu-

lar evelope circumscribed around it (defined by the values of their XMIN, YMIN,

XMAX, and YMAX attributes). These rectangular envelopes are used at each level

of processing (incoming object, space block, and side) to quickly reduce the

number of layout space blocks which must be examined in detail.

2.1.3 Forming Macro-Obj ects

Macro-objects are built when DPS wishes to enter groups of objects. The

idea of using macro-objects was suggested by experience the author gained in

designing computer room configurations. The author often found it convenient,

when manipulating plastic templates of the equipment to tape several of them

Pfefferkorn

8

together to form one template. Usually these were groups of similar units like

memory modules, magnetic tape units, or disk units.

In DPS, a macro-object is created by sliding a set of objects together and

forming a description of the set similar to that of an object. This description

is built up by using ENTER.OBJECT and other spatial routines. Additional in-

formation (name, position and direction) about the sub-objects is also included

in the description.

2.2 Description of Constraints

The constraints define the relations desired between the objects in the

layout or properties desired of the layout. The constraints fall into a number

of different classes: distance, adjacency, position, orientation, spatial, view,

and path. Examples of the different types of constraints are included in

Figure I.i.

Because each task is different, it is desirable to tailor the constraints to

the task. In order to keep the problem solver general, it is necessary to provide

a_ indirect means for communicating between the problem solver and the constraints.

This entails setting up a linkage mechanism for both program control and access

to data. While the constraints are task specific, it is desirable to represent

them in a general way so the problem solver can use the task specific data without

being task specific itself. The constraint information is used by the system to

perform planning, alternative evaluation and selection, and diagnosis of problems.

It would also be desirable to use it in generator selection and control.

The information used by the DPS includes the name of the function for

measuring a constraint's difficulty and the name of the function for evaluating

the constraint. The difficulty function, a heuristic function which attempts to

measure the difficulty of satisfying the given constraint, is used before objects

are entered in the layout. The evaluation function evaluates a constraint when

the objects are in the layout. For example, in the case of a cable constraint

between two objects, it measures the distance between the two objects in the

Pfefferkorn

9

layout. Additional information includes the severity of the constraint and its

type. The severity of a constraint measures how important the constraint; is to

satisfy. For example, in a computer room, a constraint that the operator's console

be near the drinking fountain may be very hard to satisfy, but unimportant, whereas,

a 200-foot cable restriction between a display controller and the central pro-

cessor may be very easy to satisfy, but extremely important.

To be more specific, each constraint definition and instance is represented

by a LISP atom and associated with each atom is a property list describing the

element the atom represents (Figure 2.4).

Usually a constraint is evaluated only once--immediately after all the objects

involved have been entered, and this evaluation does not change as new objects

enter. View constraints, on the other hand, are evaluated when both objects are

finally entered in the layout, but must also be evaluated each time a new object

enters the design.

To specify the solutions desired when running the examples, twelve different

constraints (described in Appendix A) were implemented in DPS. These constraints

were relatively easy to create given the large set of spatial routines which

existed. More complex constraints can be easily generated using the existing

constraints and spatial representation routines.

2.3 Design Description

The design description specifies the initial problem, the current status

of the design, and the final solution, if one has been generated. DPS proceeds

by generating a set of possible positions for an object, and selecting one to

update the design.

A simple tree structure provides a convenient representation for remembering

the different alternatives created. Each branch represents the entry of one object

(or macro-object), and each node represents the layout created by entering it into

the layout of the previous node.

Instead of providing a complete design description at each node, only enough

information is kept at each node to reconstruct it from the previous node. The

Pfefferkorn

]0

information required at each node is the object entering, its position, its

direction, and a pointer to the node from which it was created. Thus, the tree

structure being used is an inverted tree where all the pointers point toward the

head or root of the tree. This tree is referred to as the partial-design tree,

and the nodes are referred to as alternatives or partial-designs. Nodes which

have no other nodes pointing to them are tip nodes. Each node is represented by

a LISP atom with a property list containing the required information.

The initial problem specification includes the names of the objects, the rooms

the objects are to enter (usually one), and the names of the constraints.

For DPS to operate, it must be able to access all the different parts of the

representation. The Design Head, which is a LISP atom with a property list,

provides all the necessary connections. One pointer points to a LISP atom re-

presenting the initial design problem. From there DPS can get to all the spatial

descriptions of the objects, the constraint definitions, and all the constraint

instances.

The property list of the Design Head also contains the necessary pointers

into the partial-design tree. One pointer on the property list points to the

current tip node being used to generate new tip nodes. These new tip nodes are

stored on two separate lists (MTRYLIST and HISTALT) depending on whether they are

satisfactory or unsatisfactory. All other unexplored, satisfactory tip nodes are

stored on yet another list (TRYLIST).

The design property list also includes all relavent design status information

including the objects in the design, the number of alternatives which have been

created, the constraints which are open, the constraints which are ready for

evaluation, the current plan, and the current layout description. The current

layout description is a list of pointers to the space blocks representing the

current layout. Each time an object enters the design, this set of space blocks

is modi fled.

Pfefferkorn]]

3.0 The Problem Solver

DPS is a heuristic problem solver with a planning phase prefixed to it.

The initial situation is a list of empty rooms (usually one), a list of objects

to enter into the rooms, and a set of constraints to be satisfied. The steps

between the initial position and the final position consist of partial layouts.

The basic operation to get from one step to the next is to enter an object in

the layout. The selection of objects to enter and their placement are guided

by heuristics built into the program.

As the design progresses, the partial-design tree is expanded. Each branch

of the tree represents a decision to enter an object or macro-object (group of

objects) into a specific place, and each node represents the partial-design

created by implementing this decision. In DPS, a full description of a partial-

design is kept only for the current tip node. All other nodes contain only

enough information to construct the full description when required.

DPS consists of four problem-solving functions (PLAN, USE.PLAN, TES____T,and

REXAMINE) and three bookkeeping functions (PROCESS.ALT, ADVANCE.DESIGN, and

REDESIGN) which manipulate the design description. The flow of control of DPS

is shown in Figure 3.1, where each of the boxes corresponds to one of the major

system functions.

Briefly, USE.PLAN generates a set of new tip nodes from the current tip node.

ADVANCE.DESIGN selects one node and advances the design to it (makes it the current

tip node and constructs the full design description for it). It also merges the

remaining successful new tip nodes (MTRYLIST) onto the list of all tip nodes

[TRYLIST). TEST decides whether to continue forward by calling USE.PLNq, or to

try a new approach by calling REXAMINE. If REXAMINE is called, it selects from

the TRYLIST (list of tip nodes) a new tip node to proceed from, REDESIGN then

builds the full design description for this node using information stored in the

partial-design tree.

3.i Basic Search Strategies

Different search strategies for exploring the partial-design tree can be

implemented by providing different problem solving functions to DPS. A simple

Pfefferkorn

12

search strategy can be implemented by: (1) merging all currently generated

tip nodes onto the end of the list of tip nodes (TRYLIST); (2) forcing TES____T

to turn control over to REXAMINE (unless a solution has been found), and (5)

setting REXAMINE up to select the first tip node on the TRYLIST. This is a

poor strategy since it requires examining all possible arrangements of (n-l)th

objects before entering the n object in the room.

A d_epth-first search strategy can be implemented by: (1) merging all

currently generated tip nodes onto the front of the list of tip nodes (TRYLIST);

(2) having TEST turn control over to REXAMINE only if it is impossible to advance

the design, and (3) setting REXAMINE up to select the first tip node on the

TRYLIST. While the design may move directly to a solution, it can also expand

a great deal o_ effort if an object early to enter the design is incorrectly

placed.

A try-list approach can also be implemented. This approach would allow the

system to break away from a rigid exhaustive tree search strategy. It requires

a local-static-evaluation function for ordering the try-list. The static-

evaluation attempts to predict which alternatives are likely to lead to a

solution.

All of these approaches ignore feedback from the actual design, which can

be derived by analyzing the partial-designs (tip nodes) and the constraints that

failed. This requires the system to extract diagnostic information and to

implement the correct remedial action.

A simple form of feedback is to locate broken constraints and the objects

involved; given this information the layout can be backed up, and the objects

involved re-entered separately in different places, or concurrently as a macro-

object. When the system builds a macro-object, it is actually solving a sub-

problem in a space separate from the main problem solver.

Two different search strategies were implemented" depth-first and the

diagnostic approach. Implementing the different search strategies was simplified

by using the bookkeeping functions, PROCESS.ALT, ADVANCE,DESIGN, and REDESIGN,

to modify the design description, and by using the spatial representation routines

to search and manipulate the spatial representation of the objects and layouts.

Pfefferkorn

13

The following sections (3.2, 3.3, 3.4, and 3.5) describe each of the basic

problem-solving functions (PLAN, USE.PLAN, TEST, and REXAMINE) and section 3.6

describes the bookkeeping functions (PROCESS.ALT, ADVANCE.DESIGN, and REDESIGN).

3.2 Plan

The heuristic planning function prefixed to the problem solver gives DPS

a "sense of direction". It works in a separate space from the main problem

solver, and affects the solution generated by controlling the search process

used to find a solution. This differes from the planning processors normally

defined in the literature of artificial intelligence. In these planning pro-

cesses, the objective is to find a path from a starting node to a goal node

in an abstract space. This abstract space is produced by applying a many-one

mapping to the original space. In DPS, the planning process works with the

initial problem description (object and constraint descriptions) to creat a

plan which groups and orders the objects to enter the design.

The original idea of a planning phase was obtained by examining the

author's own experience in designing computer room layouts. The strategy

normally used by the author in designing a layout was to form several groups

of equipment: (i) the computer and its memory modules (tight cable restrictions),

(2) I/0 equipment requiring operator supervision, (3) I/0 equipment not requir-

ing operator supervision, and (4) any remaining equipment. Similar objects

within a group (magnetic tape units, disk units, memory modules) were often

formed into macro-objects. The groups were then entered into the layout, by

sequentially entering the required objects.

Alexander (1964 and 1965) suggests possible ways of breaking problems into

st_bpro61ems. He represents a design problem as a linear graph which he hier-

archically decomposes into clusters of tightly interconnected nodes (subproblems).

The solution to a design problem is then synthesized by hierarchically recomb-

ing solutions to the subproblems. Several systems similar to Alexander's exist

today: FPS(Davis 1970), CLUSTER (Milne 1970), and DCMPOS (Owen 1970).

In the depth-first version of DPS, PLAN simply orders the objects to enter

by their size. In the diagnostic case, two planning functions are provided:

Pfefferkorn

]4

NOPLAN and SPLAN. NOPLAN simply allows the user to specify the plan at problem

definition time, while SPLAN tries to break the problem into a set of independent

subproblems by examining the problem description (object and constraint descriptive

information). To accomplish this, SPLAN forms a set of all the objects to enter

the design. It then attempts to break this set into subsets by using one or two

different techniques. One involves removing constraints, and the other involves

removing an object from the set.

In the first case, the easiest and least severe constraints are removed, and

subsets are formed from the remaining objects and constraints. The subsets are

then ordered by the size of their largest object, and put on a list. In the

second case, one object and the constraints involving it are removed, and subsets

are formed from the remaining objects and constraints. The objects removed is

the one which _enerates the most objects. These subsets are then ordered by

the size of their largest object, and put on a list. A subset is created for

the removed object and inserted after the first element on this ordered list

of subsets.

Each subset is decomposed by one of the two techniques until a subset con-

taining fewer than five objects is obtained. When such a subset is obtained it

is appended to the plan. When the decomposition is complete, the plan consists

of a list of subsets containing fewer than five objects. This decomposition

generates a tree where the initial set is the root, the subsets are the nodes,

and the plan is the list of the terminal nodes of this tree.

In the examples run, only distance constraints were used in the planning

phase. As a result, if a particular problem involved no distance constraints,

the plan would consist of a list of subsets (each containing one object) ordered

by the size of their object.

Since the planning phase is heuristic, there is no guarantee that the order

or the groupings it generates is the best for a particular problem. The plan may

cause the problem solver to expend considerable effort examining infeasible

solutions, or to miss the solution completely. As a result, the ability to

deviate from the plan is desirable, but must be exercised with extreme caution

to prevent an excessive number of alternatives from being generated.

Pfefferkorn

15

3.3 USE.PLAN

The primary function of USE.PLAN is to create new alternatives (locations

for an object to enter the design) which become new tip nodes of the partial-

design tree. To create alternatives, USE.PLAN must determine what objects to

enter and where. Several decisions may be combined into one decision by examin-

ing a different problem space. For instance, a macro-object may be built out of

several objects (FORM.MACRO) in a space separate from the current layout. If

the decision involves making a combination of several decisions (enter a set of

objects as a macro-object), the decision is implemented in two steps: solving

the subproblem (creating a macro-object) and implementing this solution in the

main problem (entering the macro-object). The alternative decisions created

must be evaluated. This evaluation may only separate satisfactory alternatives

from unsatisfactory ones, or it may order them by their likeliness of leading

to a desirable solution.

In all cases, the alternative generators used should create and examine only

alternatives likely to lead to a solution. In general, a simple exhaustive

enumeration of all possible combinations is impractical because of the large

number of alternatives which would be created. Selectivity can be achieved by

using information from the problem statement, the constraints, and the current

layout.

A heuristic problem solver's ability to solve a problem depends heavily on

the ability of the underlying heuristics to generate promising feasible solutions

selectively. If critical alternatives are missed, the number of alternatives be-

comes excessive, or the cost of generating and evaluating each alternative becomes

large, the heuristic approach fails. Special attention must also be paid to

eliminating duplicate alternatives. In addition to wasting effort during genera-

tion and evaluation, duplicate alternatives may cause entire sections of design

to be repeated.

USE.PLAN selects the object to enter the design by examining the plan created

by PLAN and feedback generated by REXAMINE (a request for a remedial action to be

Pfefferkorn

16

implemented). In the depth-first version of DPS, REXAMINE never provides

feedback to USE.PLAN, so USE.PLAN selects the first non-entered object on

the plan. In the diagnostic version of DPS, if REXAMINE requests USE.PLAN

to enter an object, USE.PLAN tries to enter it, otherwise USE.PLAN selects

an object from the plan.

When USE.PLAN selects an object to enter, it tries to generate a small set

of likely alternatives by using information from the spatial representation, i.e.,

placing the selected object in corners of available space. While USE.PLAN

generates fewer alternatives for the examples presented later, this is not

guaranteed. In addition, simple problems can be defined which the system is

unable to solve. For instance, a problem requiring a small object to be placed

in the center of a large room. Additional generators or special purpose problem

solving programs could be added to DPS to avoid these problems, but they in turn

introduce still other problems. The objective of USE.PLAN is to selectively

generate and examine alternatives.

3.4 TEST

Each time a decision is implemented, the current design is examined by

TEST. This analysis determines whether to stop the design, because a solution

has been found; to continue forward, by turning control over to USE.PLAN; or to

diagnose why the design seems to be in trouble, by turning control over to

REXAMINE.

3.5 REXAMINE

If the design is in trouble, REXAMINE must get the design "back on the

track". Two versions of the REXAMINE function were used: depth-first and

diagnostic. The dept-first version uses a simple systematic search strategy

which is extremely expensive if an object early to enter the design must be

moved to find a solution. In the depth-first version, REXAMINE simply gets

REDESIGN to construct the full design description for the first alternative

Pfeffemkorn

]7

on the TRYLIST, and has USE.PLAN proceed from it. Since the entries on the

TRYLIST are appended to the front of the TRYLIST at each stage, the alternatives

are tried in depth-first order. This search strategy continues until a solution

is found, or until the entire set of unexplored alternatives is exhausted.

In the diagnostic version, REXAMINE tries to locate the problem. This analy-

sis is based on information collected as the design progresses. To diagnose

the problem, it examines the DESIGN description, in particular, the constraints

which caused the last set of alternatives to fail. When it does this, it is

using information built up while searching for a solution to guide it where to

search next. Once the problem has been located, DPS must select and execute

the appropriate remedial action. When doing this, care must be taken to insure

that the remedial action treats the cause of the problem, not just the sympton

of it.

The basic heuristics used by the diagnostic version of _INI_ to diagnose

the problem preventing the design from advancing are:

I) The problem is associated with a violated constraint;

2) If there is more than one violated constraint, the most important

constraint is the one involving the most objects;

3) The best remedial action is to build a macro-object;

4) If that fails, the object should be entered into the layout earlier;

and

5) If everything else fails, resort to systematic examination of the

alternatives on the TRYLIST (list of tip nodes of the partial-design

tree).

To locate the constraint causing the problem, REXAMINE examines the current

alternatives which failed. From the set of constraints which failed, it

selects the one involving the largest number of objects. If it is unable to

find one, it selects the first entry on the TRYLIST (list of unexplored tip

nodes) as the alternative for REDESIGN to implement and USE.PLAN to proceed

from. In this case, it is resorting to a systematic examination of the remain-

ing alternatives on the TRYLIST.

4

Pfefferkorn

]8

If a violated constraint is found, REXAMINE locates the objects involved.

If DPS was trying to enter these objects as a macro-object when the failure

occurred, it tries to enter the same macro-object earlier in the design. DPS

then proceeds from the first alternative on the TRYLIST which enters these

objects. If none exists, it then checks if one ever existed. If not, DPS

tries to build macro-objects which satisfy the constraints between these

objects.

If it is successful, REXAMINE gets REDESIGN to back the design up and

USE.PLAN to create alternative locations for the macro-objects. If everything

fails, it uses the first entry on the TRYLIST, and if the TRYLIST is empty

DPS gives up with the message '_0 SOLUTION FOUND". The heuristics used by

REXAMINE are simple but effective.

3.6 Bookkeeping Functions

The separation between bookkeeping functions and problem-solving functions

was made to isolate modifications to the DESIGN description for easy debugging,

and to simplify the problem-solving functions for easy modification. The

three major bookkeeping functions are PROCESS.ALT, ADVANCE,DESIGN and REDESIGN.

3.6.1 PROCESS.ALT

PROCESS.ALT is responsible for creating and evaluating an alternative. It

never enters the object into the layout, but only generates the necessary in-

formation for ADVANCE.DESIGN to enter it at a later time (if it is selected).

This information is stored on the property list of the LISP atom representing

the alternative.

PROCESS.ALT also provides the necessary linkage mechanisms for evaluating

the appropriate constraint instances, and uses the functions THRESHFN and LEAVAL

to combine the separate evaluations. After each constraint is evaluated,

THRESHFN determines whether to reject the current alternative immediately, or

to continue evaluating the remaining constraints. From the separate constraint

evaluations, LEAVAL generates a local-static-evaluation of the alternative

Pfefferkorn

]9

which is stored as the value of the LAEVAL attribute on the alternative's

property list. This evaluation is carried out without entering the object

into the design. The spatial description of the object can be visualized as

a clear plastic template of the object setting over the partial layout de-

scribed by the design description. The constraints are evaluated as if one

were looking straight down on the overlay.

If the alternative is acceptable, it is appended to the list of acceptable

alternatives. If not, it is appended to the list of current alternatives

which failed. PROCESS.ALT also checks for and discards duplicate alternatives.

5.6.2 ADVANCE.DESIGN

ADVANCE.DESIGN updates the design description by selecting an alternative and

implementing it. It selects an alternative by ordering the alternatives on the

MTRYLIST according to their local-static-evaluations (LAEVAL) and selecting the

first one. To implement this alternative ADVANCE.DESIGN must update the design

description of the layout and the current design status information (Section 2.3).

3.6.3 REDESIGN

When DPS decides to proceed from a different design context then the current

one, REDESIGN is responsible for implementing the desired context. The new context

can be a node in the partial-design tree, or a list of alternatives to be implemented.

In the first case, REDESIGN creates a list of alternatives to implement by following

the PREVSTEP links of the nodes from the desired node to the base position. It

then implements these alternatives in reverse order. In the second case, it

simply implements the given alternatives. This corresponds to taking out a clean

sheet of paper and copying over that part of the design from which the design

is to proceed.

Pfefferkorn

20

4.0 Examples

In this section, DPS's behavior is examined by analyzing the results of

running fifty different examples. These examples were divided into three

major classes: placement problems (Sect. 4.1 and 4.2), room layout problems

(Sect. 4.5 to 4.6), and other tasks (Sect. 4.7 and 4.8). The simplest pro-

blems were the two placement problem sets, Block (Sect. 4.1) and "T" (Sect.

4.2), which involved placing a set of objects into an enclosure without

overlap. These problems were used to debug the system and examine its basic

characteristics. Since DPS was designed to handle layout problems, a wide

variety of room layout examples were created and tested. To insure a diversity

of examples three types of rooms [computer (Sect. 4.3 and 4.4), office (Sect.

4.5), and living room (Sect. 4.6)] were used with two separate problem sets for

each type of room. Variations of each problem set were created by using different

objects, constraints, plans, and versions of DPS (depth-first and diagnostic).

The class of other tasks included the Pattern-Trim Problems (Sect. 4.7) and the

Line-Balancing Problems (Sect. 4.8). The objective of a Pattern-Trim problem

is to minimize the amount of material used when cutting objects from a roll or

sheet of material. The object of the assembly-line balancing problems is to

assign different tasks to different work stations on an assembly line. Figure

4.0 illustrates the relationship between the different problem sets and shows

a sample solution for one problem in each set.

Each problem set is analyzed separately. The analysis for each set briefly

describes the problems within the set, and the major results gained by intoning

the set. Figures 4.1 to 4.19 show the objects used, the constraints used, the

relationship between the different problems within a set, the final solutions

for some problems, and a few selected partial-design trees. In the part:ial-design

trees, unsuccessful or duplicate nodes are omitted or marked with an F (for failed).

The numbers indicate the order in which the alternatives were generated. The

object or macro-object entering the design is indicated by its abbreviation being

placed next to branches entering the object. The hash marked path in the tree is

the soltuion.

Pfefferkorn

2]

Numerous statistics were also accumulated when the examples were run which

are presented in Figure 5.2 in the next section.

4.1 Block Problem

The block problem set consisted of four separate problems, each of which

required placing the same six blocks in an 8 x 5 box. The differences between

the problems involved the directions the blocks were allowed to face and whether

the REXAMINE function of DPS was allowed to change the order objects entered

the design.

The block problems, while simple, show certain basic characteristics of

DPS. A simple exhaustive lexicographic approach that assigns each object a

position by specifying the coordinates of its left corner in an 8 x 5 grid would6

have twenty-four actual solutions in a candiate solution space of (8 x 5) =

4,096,000,000. In contrast, DPS generates seventy-two alternative partial-designs

before finding a solution (Figure 4.1).

While DPS generates far fewer alternatives, it can develop difficulties of

its own. In particular, when it was allowed to change the order objects entered

the design, it expended considerable effort searching similar alternatives. One

approach which was taken in Block-Problem-S and -4 is to prevent DPS from chang-

ing the order that it enters objects into the design, but this destroys DPS's

ability to solve a wide class of problems. A better approach would be to prevent

order permutation only when the objects involved have the same shape and constraints.

Better layout analysis would also allow DPS to recognize blind alley's and elimin-

ate symmetric alternatives. These improvements can be made to DPS and their effects

observed by running the block problems. The simplicity of the block problems make

them useful in exploring the behavior of DPS-type programs.

4.2 "T"-Problems

The "T"-Problem is a version of a commercially available plastic puzzle.

The commercial version consists of four plastic pieces which the person places

to form a "T". The major modification to the problem for the computer was the

definition of the enclosure defining the "T". Figure 4.2 shows the four pieces

Pfefferkorn

22

and the enclosure. In the first computer version, flipping the pieces was

prohibited. In the second version, the ability to flip the pieces was pro-

hibited. In the second version, the ability to flip the pieces was provided

by defining the problem as an "OR"-Problem (Figure 4.3).

In the T-Problems, the planning heuristic, order-by-size, forced DPS

directly to a solution generating a minimum number of alternatives. To arrive

at a solution, DPS required alternatives generated by placing objects around

concave corners of available space, as well as, in convex corners of available

space. T-Problem-2 also demonstrated the use of "OR-SETS" to describe two shapes

of the same object (the object and its flipped version). Again the major charac-

teristic of the placement problems was simplicity.%

4.3 Small-Computer-Room Problems

Since DPS was primarily designed to explore furniture and equipment layout

problems, approximately thirty different layout problems were run on DPS. The

simplest layout problem was a computer room which involved four objects: a

central processor, a memory module, a card reader, and a printer. This problem

was initially used to test the system during its development, but it also demon-

strates certain basic characteristics of DPS. The objects were described as

simply as possible, and the constraints were kept to a minimum. The only con-

straint other than spatial constraints was a cable constraint between the central

processor and the memory module. This problem was run using both versions of

DPS (depth-first and diagnostic).

In the depth-first version, DPS was frequently forced to back-track because

of the cable constraint. It examined 687 alternatives before finding a solution

(Figure 4.4). In testing the diagnostic version of DPS, additional problems

developed. DPS quickly found a solution which satisfied all the given constraints,

but was unacceptable because the objects divided the room into two separate isolated

areas. This clearly demonstrated the need for a path constraint of some form.

Since it was undesirable to specify each and every possible desirable path, a gen-

eral connectivity constraint was needed. The CAOS constraint described in Appendix

A was sufficient for this problem. Figure 4.5b demonstrates layouts using this

constraint, while Figure 4.5a shows layouts generated with the constraint.

Pfefferkorn

23

When the diagnostic version of DPS used the same plan as the depth-

first version, it generated 125 alternatives (Figure 4.5c) versus the 687

of the depth-first version. When it used SPLAN, it only required seventy-

one alternatives. In both cases, when it failed to enter the memory module,

it located the cable constraint and built a macro-object. Then REDESIGN

backed the design up, USE.PLAN entered the macro-object, and DPS proceeded

directly to a solution. While the Small-Computer-Room problem is extremely

simple, it still demonstrates the necessity of the connectivity constraint,

and the effectiveness of the diagnostic REXAMINE function in reducing the

number of alternatives explored.

4.4 Computer-Room Problems

The computer room problem set consisted of a medium size computer con-

figuration which contained nine objects: central processor (CP), two memory

modules (MI and M2), card reader (CR), printer (PR), tape control unit (TC),

and three tape units (TI, T2, and T3). The dimensions of the room and the

objects were small integer multiples of a basic unit. Both the room and the

objects contained access space (Figure 4.6a). The room's access space re-

presented a corridor to be kept open. A wide variety of constraints were

used to describe the solution desired. The distance constraints were used to

describe the solution desired. The distance constraints consisted of cable

length restrictions, and operator walking distance restrictions. Positional,

orientational, and spatial constraints were also used, along with connectivity

constraints, requiring all ACCESS space to be connected by ACCESS-OPEN space.

The constraints are shown in Figure 4.6b.

For Computer-Room-l, DPS was run using the set decomposition planning

function, SPLAN, which breaks the objects into subsets of five objects. The

plan developed (Figure 4.7) requested three macro-objects be built and that the

memory module be entered first followed by the central processor, the card-

reader-printer macro, and then the tape-unit-macro. When DPS tried implementing

this plan, it ran out of time because it tried to generate too many alternatives

for macro-objects, and was too willing to tear down macro-objects already built.

Pfefferkorn

24

To overcome these weaknesses the problem was modified to simulate the behavior

of a system (Figure 4.8a) which builds only one macro-object for each set

immediately after the planning phase. In actual practice, the macro-objects

(Figure 4.8b) were formed by hand at input time, and the constraints (Figure

4.8c) simplified by dropping those internal to macro-objects.

Several versions of the modified problem were run. Figure 4.9 shows the

relationship between different problems and the effects the different constraints

have on the final solutions. These problems demonstrated the feasibility of using

only one macr0-object per SPLAN set created immediately after the planning phase.

This technique reduced the original problem of entering nine objects into one of

entering four macro-objects. These problems also illustrated the effectiveness

of getting the system "back on the track" by using diagnostic heuristics to

locate violated constraints and the remedial action of building a macro-object.

To insure that the techniques developed were not restricted specifically to

computer layout problems, two office problem sets and two living room sets were

also tested. The objects were described more accurately in the office and living

room problem sets, but the important differences were the constraints used.

4.5 Office Problems

The first of the two office problems used required placing a desk (60" x

30"), two file cabinets (15" x 30"), a table (60" x 30"), and a bookcase (60" x

15") in a small office (14' x 8' x 2"). A blackboard was assumed to be hung

on one wall. To prevent furniture from blocking access to it, the floor area in

front of it was defined to be access space. The access areas for the desk and the

table represent the areas reserved for the person using them. The description lists

of the objects included additional descriptive information, such as, which points

defined the back, front, and sides of the objects. Figure 4.10a shows the objects.

The second office problem was similar to the first, except different objects

and constraints were used. Again, the office was assumed to have a blackboard

along one wall requiring access space in front of it. This time the office also

had a window, and in different problems the desk was required to face toward it, or

away from it. The objects were a desk, two file cabinets, a large table, a terminal,

and a bookcase (Figure 4.13a). Several versions of this problem were also run.

Pfefferkorn

25

In the office problems, the pre-built macro-objects were used for the SPLAN

sets as they were in the computer room problems. The NOPLAN versions of the

original problems (Figure 4.10 and 4.13) ran, but took considerably longer than

the corresponding pre-built macro-versions of the problem. The effect of using

the different constraints and plans can be seen in the final solutions (Figure

4.11, 4.12 and 4.14) generated, especially for the Office-A problem set. Both

sets used the diagnostic capabilities of DPS to locate difficulties and the

remedial actions to correct the difficulties.

4.6 Living Room Problems

The living room problems involved using different sets of constraints to

arrange living room furniture in two different rooms. A television set, two

couches, a corner table, and in certain cases, a chair were placed in the first

room. For the second room, several different sets of furniture were used. The

rooms and furniture are shown in Figure 4.15.

The constraints for the TV-Room problems are shown in Figure 4.16a. These

constraints required that you be able to see the television from the couches and

the chair.

The first two versions (TV-Room-I and -2) were run using SPLAN whiclh ordered

the objects by size because of the absence of distance constraints. In both

cases, the system moved forward until it was unable to enter the corner table

(Figure 4.16bi). In both cases, DPS was able to extract itself from a blind

alley quickly by using REXAMINE's ability to change the order objects enter the

design.

The third (TV-Room-3) moved directly to a solution (Figure 4.1662) using a

plan based on the heuristic of entering objects with the fewest alternative

locations first. This plan can be generated by first locating all objects which

share constraints with the i_om. These objects can then be ordered by the number

of possible alternative locations for each object in the room. Next, objects

sharing constraints with these objects would be entered, then other objects shar-

ing constraints, and finally, any remaining objects.

Pfefferkorn

26

The objects to enter the second living room problem are also shown in

Figure 4.15. Version one (Living-Room-l) required seven objects to enter

following a predetermined plan. The remaining versions used a simplified

macro-object (Figure 4.17d) for the two couches, the corner table, and the

coffee table. All of the versions involved entering the piano at some stage.

The different solutions are caused by the different constraints and plans

used. For instance, versions two and three require the corner table macro-

object to be in the corner, while versions four and five only require its right

side to be against the wall.

The effect of these constraints can be seen by examining the layouts;

generated (Figure 4.17). Determining what specific constraints to use is. a

major problem. Generally the specific constraints would be derived from a

functional description of how the room is to be used.

In the layout problems, the representation developed for DPS was used to

define complex-shaped objects like the piano, and to specify numerous different

constraints. In generating the different solutions for the layout problems, the

planning, diagnostic, and remedial action capabilities of DPS were used. The

effect of SPLAN can be seen by comparing the unmodified problems run using NOPLAN

and the corresponding pre-built macro-versions. The effect of diagnostic and

remedial action capabilities can be seen by examining the different partial-design

trees.

4.7 Pattern-Trim Problems

To see if DPS could handle other tasks, Pattern-Trim and Line Balancing

problems were set up and run. The objective of the Pattern-Trim problems; is to

minimize the amount of material used when cutting objects from a roll or sheet

of material. In DPS's Pattern-Trim Problems, arbitrarily shaped two-dimensional

objects may be used. Whereas, in Gilmore and Gomory's (1965) Trim Problems only

rectangular shaped objects are allowed. Gilmore and Gomory formulate their Trim

Problems as linear programming problems.

Pfefferkorn

27

The objects used by DPS are shown in Figure 4.18a. Several versions of

the problem were run using different sets of objects, different rotations of

T4 and T7, and different static-evaluation functions (Figure 4.18).

The static-evaluation function is used by PROCESS.ALT to evaluate each

alternative when it is created. In the previous problems discussed, the static

evaluation function either accepted or rejected an alternative. The two static-

evaluation functions used for the Pattern-Trim problems attempted to generate

a value which would cause DPS to examine the "best" alternatives first. ADVANCE.

DESIGN uses the value created to order the MTRYLIST and to select the alternative

to be used to advance the design. The static-evaluation function MENV returned

the value one hundred minus the area of the rectangular envelope enclosing all the

objects in the' layout. The static-evaluation function MINX returns the value of

the largest x-coordinate of an object in the layout. The result of using these

two functions can be seen by examining the solutions generated (Figures 4.18b

and 4.18c).

4.8 Assemblz-Line Balancing Problems

The assembly-line balancing problems involved assigning different tasks to

different work stations on an assembly-line. Each task required a specii'ic amount

of time, and certain tasks had to be finished before others were started. The

system was run using two of Tonge's (1961,1963) line balancing problems. Each

task was represented as an object, one-by-N (where N is the number of units of

time required to complete the task). The size of the room in which the tasks were

entered was N by M (where N is the number of work stations and M is the

maximum number of units of time to be spent per work station). The inter-

dependency of the task is shown in Figure 4.19a. These relations were represented

by positional constraints.

DPS is able to solve some line balancing problems rapidly while expending

a considerable amount of effor to solve others. Several things account :for

the system's poor performance. It is capable to handling complex objects and

several types of space. In the line balancing problem, the vertical order of the

Pfefferkorn

28

objects is irrelevant. At the same time, the limitations of REXAMINE, USE.PLAN

and FORM.MACRO become critical in this problem. When REXAMINE encounters

multiple constraints between a set of objects, it can cause DPS to oscillate.

This could be eliminated by making REXAMINE more sophisticated.

4.9 Review of Examples Tested

The examples were developed to debug DPS and analyze its behavior. While the

placement problems and the Small.Computer-Room problem set were used basically

to debug DPS, their simplicity allows one to compare DPS to a single lexicographic

approach and to compare the diagnostic version to the depth-first version. Block-

Problem-2 also points out the oscillation which can develop if the order objects

enter the layout is changed, and the Small-Computer-Room problem set demonstrates

the necessity of a general connectivity constraint.

The layout problems demonstrated the representational powers of DPS to

represent complex-shaped objects, like the piano, and to specify the diversity

of different types of constraints used. In solving layout problems, DPS made use

of its planning, diagnostic, and remedial action capabilities. Because of several

deficiencies of DPS, the effect of the planning function SPLAN was simulated by

providing pre-built macros. The pre-built macro versions ran considerably faster

than the unmodified problems using NOPLAN. Both the remedial actions of building

a macro-object and entering an object earlier into the design were used frequently.

While REXAMINE did not always generate the "best" response to a problem, it usually

produced a reasonable one. DPS generated a wide variety of solutions in response

to the different constraints used in the different layout problems.

DPS also was able to handle the Pattern-Trim problems and Assembly-Line

Balancing problems. In the Pattern-Trim problems two different local-static-

evaluation functions were used. Using the local-static-evaluation function

MINX, DPS was able to generate solutions as good as humans produce, if not better.

DPS's performance on the line balancing problems was erratic. Sometimes it went

directly to a solution, and other times it wasted a great deal of effort.

29

5.0 Performance and Extensions

In this section the major features of DPS are analyzed: spatial representation

(5.1), implementation (5.2), and the main problem solving functions. Modifications to

improve DPS's behavior are also included.

5.1 Evaluation of the Spatial Representation

The convex polygon representation and its associated operators provide DPS with

the ability to prepresent and manipulate objects, to test constraints, and to advance

the design. The spatial operators provided include capabilities to translate and

rotate objects, tO find positions for them, and to enter them in the design. It also

provides routines to handle adjacency information, find different types of space, and

to construct boundaries of different regions of space.

The convex polygon representation is a compromise. It requires curvilinear objects

to be approximated, while linear ones are structurally exact. Shapes are made up

of more regions than theoretically necessary, but checking for overlaps and updating

the design description is easy. The storage required is a function of the complexity

of the object, not the resolution. Because it uses convex polygons instead of the

standard rectangular regions, it has no problem handling irregularly shaped objects,

or objects placed non-parallel to the axes. Boundaries of regions of space with sides

non-parallel to the axes.are also easy to define and manipulate. Since the adjacency

information is provided via the sides of the convex polygons, it is independent of the

direction of the coordinate axes being used. This adjacency information allows the

space to be segregated into regions of disjoint space, boundaries of regions to be

constructed, and adjacency and connectivity constraints to be checked. The convex

polygon representation compares favorably with other space planning representations,

especially, if the representation must be searched for structural information about the

objects or re._ations between the different objects and different regions of space.

The ideas behind it should be applicable to a diversity of different space planning

tasks, even if the current implementation is not.

3O

In "Representations for Space Planning," Eastman (1970) compares several space

planning representations. He also describes the deficiencies of computer graphic

languages, like SKETCHPAD (Sutherland 1963a, 1963b), in representing two-dimensional

space for space planning applications. These deficiencies include the _nability to

represent empty space, to manipulate domains of space, and to handle adjacency

information. The "space planning" representations discussed by Eastman all use

rectangular domains which require structurally approximating objects which are

irregular in shape, or are non-parallel to the coordinate axes. Boundaries of

regions of space with sides non-parallel to the coordinate axes become complex -

i.e., lots of small sides. In these representations, adjacency information is also

dependent on the direction of the axes, and in the string representation it is

handled differently for each of the two coordinates. The storage required for the

array representation increases with the square of the resolution and for the string

representation it increases linearly.

To compare the several different representations, Eastman (1970) uses each

representation to represent the simple room layout shown in Figure 5.1a. Figure

5.1f shows this room layout using the convex polygon spatial representation.

Figure 5.1g compares the spatial representation using data compiled by Eastman

and extended to cover the convex polygon representation.

5.2 Implementation of DPS

DPS was written in LISP-I.5 and run on CMU's IBM $60/67. LISP was chosen because

it provided both list processing and arithmetic capabilities. Because the system

was to be an experimental prototype design program, and not a production design system,

the slow execution speed was not considered critical. With the exception of its

execution speed, LISP was an excellent language to use. LISP's general data structures

and full recursion were used frequently and in a diversity of ways.

3]

DPS consists of approximately 5,200 lines of LISP, distributed between 350

functionscascaded to form one large problem-solving program. Twenty percent of

the code is devoted to each of the following" the problem-solving functions

(PLAN, USE.PLAN, TEST, and REXAMINE), the bookkeeping functions (PROCESS.ALT,

ADVANCE.DESIGN, and REDESIGN), and the input-output routines. The remaining

forty percent is devoted to the spatial representation routines, mainly low-level

subroutines.

While the current system can handle a diversity of different problems,

it runs slowly, 1 (ten rain. to one hour per problem). It spends most of its time

in the spatial representation routines, in particular, in a half-dozen simple but

frequently called low level spatial representation subroutines. Using the LISP

compiler will speed it up by a factor of eight to ten; careful reprogramming to

increase the efficiency of the low level subroutines and to reduce the frequency at

which they are called, will spped it up an additional factor of two to four. The

system's speed and generality can be increased by adding sophistication to

problem-solving functions which are called infrequently. If this added complexity

reduces the actions performed by the spatial representation routines, the system's

performance will be siEnificantly increased. Because th e power of the system

is also increased, this approach will provide for more significant gains than the

compiling and reprogramming improvements.

Figure 5.2 contains data compiled while running the numerous examples described

in Section 4.0. In principle, DPS can solve any task which can be formulated as a

layout design problem, but the computer time required would make it impractical in

many cases. The significant features of DPS will be examined by analyzing each of

the major problem solving functions. Since USE.PLAN uses information from both

PLAN and REXAMINE, these two functions are described first, followed by USE.PLAN

and then TEST.t

32

5"3 Plannin_

The heuristic planning function used two planning heuristics: order-by-size

and set decomposition. In the placement problems, the simple heuristic order-by-

size was very effective. In the T-Problems, only one acceptable alternative was

generated at each stage, and DPS moved directly to a solution. In the Block-

Problems, it gave DPS a sense of direction but backtracking was required. In

the Pattern-Trim problems, the intuitive ordering of the objects by difficulty seems

to match the order-by-size heuristic ordering. In these problems, only spatial

constraints were involved, and the order-by-size heuristic was reasonably good.

The effectiveness of the order-by-size heuristic dropped significantly when

other types of constraints were added. In certain cases (TV-Room-i and Office A-8_,

the order-by-size heuristic started the problem off in the wrong direction, and the

REXAMINE function was forced to straighten the design out.

In the more complex problems, a set decomposition planning scheme using

constraint relaxation was used. This allows the planning phase to decompose

the problem into semi-independent subproblems. The smallest subproblems are solved

by building macro-objects. The macro-objects are then sequentially entered into

the desilrn. The effectiveness of this technique was demonstrated by running the

pre-built macro problems that simulated the effect of building the macro-objects

immediately after the planning phase. The Computer-Room, Office A, Office B, and

Living Room problem sets were run using the pre-built macros.

The original problems were also run without planning. In the Office A case,

the non-macro problem took approximately three times as long to solve as the

corresponding macro-version. It used over 470 alternatives, as compared to 117. In

the Computer Room case, the macro version found a solution while the non-macro version

ran out of time and would have required a substantial amount of additional time to

find a solution. The set decomposition technique works if the objects connected by

constraints can be organized into groups by constraint relaxation.

33

5.3.3 Other Planning Functions

For problems like the line-balancing ones, it is desirable to have a planning

function which can take advantage of the partial ordering implicit in the positional

constraints defining the order that the assembly-line tasks must be completed.

Other planning functions can be easily conceived and implemented that make more

effective use of constraint information. In Office A-9 where the provided plan

arranged the objects by size, the constraint requiring that the bookcase be on

the right side of the room caused DPS to backup to the beginning and start over.

In Office A-10, the same problem was run with the bookcase as the-first entry in the

plan. This version went straight to a solution. This plan can be generated by entering

objects with constraints to the room, then objects connected by constraints to objects

already in the plan, and finally, the remaining objects. Numerous different planning

functions can be easily developed, each tailored to a specific type of problem or

class of problems. The planning function would then require a super-planner to

select the appropriate planning function for the problem at hand.

5.4 REXAMINE

Two versions of the REXAMINE function were used: depth-first and diagnostic.

The depth-first version of DPS examined 687 alternatives to find a solution for

Small-Computer-Room-l, while the diagnostic version examined only 121 alternatives

before finding a solution (Small-Computer-Room-3). The depth-first version made

use of a simple systematic search strategy which is extremely expensive if an

object early to enter the design must be moved to find a solution.

When the diagnostic version of DPS runs into difficulty, it attempts to

locate the problem caasing the difficulty, and then attempts to select a remedial

action to correct it. To diagnose the problem, it examines the constraints which

caused the last set of alternatives to fail to determine how to proceed. When it

does this, it is using information built up while searching for a solution to guide

it in where to search next. Its current analysis of the design description is very

simple.

34

The remedial actions taken are also simple. It can scan the TRYLIST for an

alternative which enters a macro-object of the objects involved in the broken constraint;

it can build a new macro-object; it can enter an object earlier; or it can use the

TRYLIST. The first scheme can be extended to search for an alternative which matches

a general description of the type alternative desired. The second scheme of building

a new macro-object can be viewed as working in a separate problem space to solve the

subproblem of satisfying the violated constraints. This technique of working in a

separate space can be extended by providing special purpose problem solvers, or by

using the main problem solver recursively to solve subproblems.

Entering the _object earlier effectively says -- this object is causing the

problem, so concentrate on finding a solution which satisfies its constraints.

Entering the object earlier is only one way of concentrating on finding a solution

for it. The last remedial action listed, basically says -- if all else fails, resort

to a systematic examination of the remaining alternatives. The combination of diag-

nosis and remedial actions cuts down the amount of blind searching, especially if

compared to a depth-first approach.

5.4.1 Effectiveness of the Heuristics

The effectiveness of the heuristics to diagnose the problem, preventing the

design from advancing, and to initiate a remedial action to solve it can be seen

by examining the different data sets run. The amount of search required to :find

a solution for Small-Computer-Room-3 was greatly reduced by locating the cable

constraint between the central processor and the memory unit, and by taking the

appropriate remedial action of building a macro-object. In TV-Room-l, DPS recovers

by building a macro-object of the corner table and the couch. In Office B-I, it

builds a macro-object for the desk and the table. This technique of entering a

35

macro-object to satisfy a violated constraint is also used successfully in

Office A-I, TV-Room-2, and Computer-Room-l, -2, -5, and -4.

The enter-object-earlier-heuristic allowed DPS to solve Office A-9 quickly,

even though the plan started it off in the wrong direction. Both these techniques

(build a macro-object, and enter-object-earlier) allow the diagnostic version of

REXAMINE to avoid the blind searching typical of the depth-first version.

5.4.2 Limitations and Extensions

While the heuristics usually get the system "back on the track" rapidly,

this behavior is not guaranteed. The diagnostic REXAMINE function has several

limitations--some ,_caused by its simple heuristics, while others are c&used by

Zhe Zoutines it uses.

The simple heuristic of assuming the problem is associated with a violated

constraint can cause the system to oscillate if two constraints involving three

objects must be satisfied concurrently. This oscillation is extremely expensive

and could be avoided if REXAMINE was able to locate the two constraints and build

a macro-object for all three objects.

The FORM.MACRO-object routine can be considered a small problem solver working

in a different problem space. It manipulates objects like the main problem solver,

but uses slide operations instead of a place-in-corner operation. This small

problem solver can be improved by adding additional alternative generators, a planning

phase, constraint manipulation capabilities, and sophisticated alternative evaluation

routines. Instead of limiting this problem solver just to forming macro-objects,

it could be designed to handle subproblems of the main problem. In this mode, it

would receive a list of objects and a list of space blocks to enter the objects into.

The set of elements on each of these lists would be _ subset of the corresponding

lists of the main problem solver. Its objective would be to enter the objects into

the space blocks given while satisfying the constraints between the objects.

36

Limitations are caused by using the FORM.MACRO routine. In order to limit

the number of alternatives created, this routine only tried certain very simple

arrangements. As a result, it was unable to form a macro-object consisting of two

file cabinets and a desk in Office A-I. In several cases, FORM.MACRO failed to

generate macro-objects, because sub-objects were required to have certain orien-

tations with respect to each other. These limitations are caused by weaknesses in the

FORM.MACRO routine and can be solved by a more sophisticated version.

There is also limitations in the applicability of the form-macro-object-heuristic.

This heuristic works well if the constraints involved are distance or adjacency

constraints, but works very poorly if the violated constraint is a view constraint.

In one example used during debugging, the system built a macro-object out of a

chair and a television set to satisfy a view constraint. It placed the chair direc-

tly in front of the television set, which satisfies the view constraint, but is

useless with respect to the rest of the layout. As a result, the form-macro-object-

heuristic should not be applied to view constraints, and new heuristics should be

developed to handle them.

The heuristic to enter an object earlier can also cause serious problems. In

Block-Problem-2, it caused the system to permute the order it entered blocks BB23

and BBB23. Since both blocks have the same shape, they create the same layouts

when entered. Since the heuristic of entering objects earlier is useful in other

problems, it is desirable to keep the heuristic, but prevent it from being applied

when it would cause similar layouts to be created.

5.4.3 Other Improvements and Extensions

The REXAMINE function can be improved in several ways. The most straight-forward

is to increase the number of heuristics used and to implement modifications already

discussed. Additional modifications can also be made. For instance, the routine used

to build macro-objects can be designed to handle additional constraint information.

This would allow it to handle more complex arrangements without expending a great deal

37

of effort examining useless alternatives.

Another extension is to modify the main problem solver so that it can be

called recursively to handle subproblems. The slide operations would also have

to be added to the main problem solver so that it could handle the form-macro-

object operations. This would allow the main problem solver to handle layout

problems without requiring an enclosure.

The recursive nature of the problem solver could also be used by USE.PLAN

as well as REXAMINE. To get the full benefit of the recursive nature of this

problem solver, PLAN, USE.PLAN, and REXAMINE would have to be modified. Given

these modifications, DPS could take full advantage of the problem solver's

capabilities when working on sub-problems and would eliminate the need for num-

erous special purpose problem solvers.

The ability to call the problem-solver recursively provides the capability

to solve a sub-problem, but this requires REXAMINE to be able to locate, define,

and set up subproblems. To generate reasonable subproblems, REXAMINE needs

to provide better analyses of the current state of design rather than assuming

that the violated constraint that it locates is causing the problem. This

would require better constraint manipulation capabilities, especially the

ability to locate constraints which must be satisfied concurrently.

Analysis of the partial-design tree could help determine why the problem

solver is oscillating, while layout analysis could find where space is being

wasted. This approach of improving REXAMINE by providing better analysis is

independent of whether the problem solver can be called recursively, or whether

the macro-object routine is improved. These improvements increase the system's

ability to take remedial action, and are only useful if the analysis of the

difficulty is correct, and if the appropriate remedial action is requested.

38

5.4.3.4 _Replannin_

An additional remedial action REXAMINE could perform is to call for replanning.

Currently DPS creates only one plan for each problem. If the plan is inappropriate,

DPS will expend considerable effort examining infeasible solutions, or miss the

solution completely. DPS could be improved if REXAMINE could diagnose whether the

current plan is appropriate, and if not, have PLAN create a new plan using the

diagnostic information provided by REXAMINE. During this replanning phase infor-

mation from the partial-design tree and the current layout could be used, in

addition, to the constraint and object descriptive information used during the

initial planning phase.

The modifications described above indicate some of the directions that can

be taken in improving the REXAMINE function. Even without these modifications,

the diagnostic REXAMINE function was able to avoid the blind searching used by

the depth-first search strategy. The diagnosis and remedial action selection adds

to the complexity of the search strategy and as a result, forfeits simplicity for

selectivity.

5.5 USE. PLAN

The USE.PLAN function generates the alternatives to be used. If a simple

exhaustive approach is used, a large number of alternatives are created. If in

Block-Problem-I an alternative is generated for each grid point of an eight-by-five

array (representing the box), forty alternatives are generated at each stage as

compared to four or five generated by the USE.PLAN function. For the Living

Room-Problems the grid array would be 216 by 180 and the number of alternatives

per stage would be 38,880.

39

USE.PLAN used information from the spatial representation of the layout to

generate a small set of likely alternatives -- i.e., alternatives placing objects

in corners of available space. While USE.PLAN generates fewer alternatives for

the examples run, this is not guaranteed. Duplicate alternatives can be generated,

the order that objects enter becomes important, and more requirements are placed

on the spatial representation. The convex polygon representation is capable of

handling these added requirements. USE.PLAN tries to prevent duplicate alter-

natives from being created while PROCESS.ALT discards any duplicate alternatives

from being created while PROCESS.ALT discards any duplicate alternatives it finds.

USE.PLAN also attempts to minimize the number of alternatives it generates,

without discarding alternatives necessary for a solution.

The major difficulties of USE.PLAN resulted because of FORM.MACRO. In Office

A-I, FORM.MACRO's inability to build a simple macro-object out of two file cabinets

and a desk caused DPS to give up. In Computer-Room-l, the system built four macro-objects

for the two memory modules and generated 160 alterantives. This, plus REXAMINE's

tendency to tear macro-objects down quickly and FORM.MACRO's habit of rebuilding

all macro-objects from scratch, caused the system to expend a great deal of time with-

out progressing very far. These limitations are mainly in the FORM.MACRO routine.

The limitations of FORM.MACRO are described in more detail in conjunction with

FORM.MACRO's use in REXAMINE. The limitations discussed there apply to USE.PLAN

also.

In addition to the limitations of FORM.MACRO, simple problems can be defined

which the system is unable to solve because of USE.PLAN. For instance, a problem

requiring a small object to be placed in the center of a large room is unsolvable

by the system. To solve this problem an additional alternative generator would

have to be added to USE.PLAN which would generate alternatives for placing objects

in the center of space blocks or groups of space blocks.

4O

While additional generators allow additional problems to be solved, they

increase the number of alternatives to be generated per stage. To get around

this problem, USE.PLAN could restrict the number of generators used per stage,

but this requires USE.PLAN to decide which generators to use. This set of decisions

could be made by USE.PLAN independently or in conjunction with PLAN and REXAMINE.

The objective in USE.PLAN has been to be very selective in generating and examining

alternatives.

5.6 TEST

The TEST function performs two basic functions. It determines whether the

design is complete, and if not, whether to continue forward by calling USE.PLAN,

or to back-up by calling REXAMINE. Its current implementation is very simple.

To test whether a solution has been generated, it checks if all the required objects

are in. This requires checking sub-objects of macro-objects and the alternative

objects of an "OR-SET". If the design is not finished, it checks if ADVANCE.DESIGN

actually advanced the design. If not, it transfers control to REXAMINE; otherwise,

it transfers control to USE.PLAN.

5..6.1 Try-List Capability

One way of extending TEST is to add a try-list capability. Currently, DPS

generates a set of alternatives, picks one, advances the design, and repeats the

process. This continues until a solution is found, or the design cannot be advan-

ced. Instead of blindly charging down a path until a dead-end is reached, TEST

could compare the current alternative against the best one on the TRYLIST which is

an ordered list of all the previously created, but unexplored, satisfactory alter-

natives (tip nodes of the partial-design tree). If the best one on the TRYLIST

is sufficiently better than the current one, REXAMINE could be a called to place the

current alternative on the TRYLIST, and implement the best one from the TRYLIST.

4]

The diagnostic REXAMINE function will do this if the name of the desired alternative

on the TRYLIST is passed to it. The try-list capability requires the static-

evaluation function to accurately predict the best alternative to explore. This

capability, if used properly, would allow the system to suspend exploration of

unfavorable looking design paths to examine more favorable looking ones. If the

expectations of the favorable path are not met, the system can return to the sus-

pended path. This capability saves exploring unfavorable ones to the bitter end.

5.6.2 Decision Analysis (Layout and Partial-Design Tree)

Blind alleys and unfavorable paths can also be detected by having TEST

analyze the design description, in particular, the layout and the partial-design

tree. In Block-Problem-i (Fig. 4.1), the system entered Block B23 at alternative

-8 and continued forward only to return by backtracking after trying to enter BB23

and BBB23. If TEST had been able to examine the layout and realize that it was

impossible to generate a solution from alterantives -8 or -9, the system could

have saved all the effort expended getting to alternative -i0. In addition

to checking for blind alleys. TEST could also defer exploration of unpromising

paths using analysis of the design description. These modifications add a great

deal of complexity to the simple TEST function currently used, and are warranted

only if they aliow new problems to be solved, or significantly reduce the amount

of search necessary to solve old problems.

5.7 Pre- and Post-Processors for DPS

DPS can also be extended by adding new pre- and post-processing functions.

After a solution is generated, a "smoothing" function could examine the final

solution to make minor improvements. This function could add minor pieces of

furniture in available space: lamps in livingrooms, waste baskets and coat trees

in offices, or tables and chairs in computer rooms. It could also center pieces of

furniture along walls, turn chairs to face the center of the room, and line-up com-

puter equipment on floor panels. The actions taken would not change the topological

arrangements of the original objects in the room, but would only perform local

42

adjustments to improve the general layout.

5.8 Conclusions and Directions for Future Research

DPS was written to explore the task of using the computer as a designer.

The objective of this empirical research was to identify key technical problems,

to provide tentative solutions, to provide guidance in developing new design

systems, and to suggest areas for further research.

DPS demonstrates that the computer can perform simple design tasks. While

DPS is slow and limited in scope, the ideas behind it are general. It demonstrates

the need for selectivity in controlling search, and has the facilities for achieving

a reasonable degree of selectivity. These facilities include planning, selective

alternative generation (enter objects in corners of available space), diagnostic

procedures, and remedial actions. These methods use task specific information:

constraint descriptions in planning, the spatial representation in alternative

generation, the constraints in the diagnostic procedures, and the design descrip-

tion in the remedial actions. The current implementation of these features is

simple and can both be extended and applied to other tasks. Other techniques dis-

cussed that can be used include new planning strategies, additional alternative

generators, special problem solvers, and layout and design analysis routines.

In the process of developing DPS, numerous questions involving spatial

representations were examined. The convex polygon representation compares :favor-

ably with existing space planning representations, and the ideas behind it should

be applicable to a wide variety of tasks in architecture, engineering, urban-planning,

and natural resource management.

DPS can be used as a model for developing new design problem-solving systems,

but additional research will be required before large scale design systems can be

implemented. When a human designer approaches even _ simple problem, he has a

large store of general knowledge which he can draw on to solve the current problem.

43

If the computer is to compete, it must also have access to such information.

"How should this information be represented in the computer?", "How should it

be organized?" and "How should design programs use it?" are all questions

which must be answered if design programs are to become effective designers.

Empirical investigation of these questions and other design problems should provide

new insights. These insights should allow an ever-widening range of interesting

and sophisticated design programs to be developed.

44

Appendix - A

Constraints Used by DPS

To specify the solutions desired when running the examples, twelve

different constraints were implemented by DPS.

Distance (CABLE and OPER)

Two distance constraints were used: CABLE and OPER. Both measured the

distance between a point on one object in the layout and a point on a second

object in the layout. The two routines differed in the attribute used to

locate the points in the object descriptions.

Position (LEFTIND and BELOWIND)

Two position constraints were used: LEFTIND and BLEOWIND. Both

received the names of two objects, where the objects could be rooms. LEFTIND

compared the x-coordinates of the centers of two objects, while BELOWIND

compared the y-coordinates. If the first object's coordinate was less than

the second object's, the routine returned a value of TRUE, otherwise a value

of FALSE(NIL).

Orientation (ORT and FACE)

Two orientation constraints were used: ORT and FACE. The orientation

constraint ORT compared the relative position of two objects, but this time

it considered the position of the first object relative to the direction the

second object faced. It checked if the first object was to the front, left,

right, or behind the second object. It could also test if an object was

horizontal (left or right) or vertical (front or behind) in relation to

the second object. The check was made by comparing the angle between the

direction line of the second object and the line from the center of the second

object to the center of the first. If the angle was within the appropriate

range, the evaluation range, the evaluation routine returned a value of

TRUE, otherwise a value of FALSE(NIL).

45

The evaluation routine for FACE received the name of two objects, an

attribute, and an angle. The attribute was used to locate a list of points

on the second object. These points usually defined a window, but could

define a blackboard, door, or the front of a piece of equipment. Again the

angle between line segments was compared to see if the angle was in a specific

range. Each line from the center of the first object to one of the points

specified on the second object was compared to the direction of the first

object rotated by the angle passed to the routine. All of the angles checked

had to be within the range of plus or minus ninety degrees. This routine was

used to check if a desk faced the window, or away from it.

Adjacency (ADJ)

The adjacency constraint, ADJ, checked to see if a list of points on one

object lay on the boundary of a second object. The list of points is located

using an attribute passed to the evaluation routines. The boundary used

depends on whether the second object is a room, or not. If it is a room, the

boundary is of ACCESS-0PEN space, and if not, it is of CLOSED space. This

routine was used to check if the back of a piece of furniture was against the

wall, or if a particular side of an object was next to another object.

Spatial (CHECKSPACE)

The spatial constraint CHECKSPACE uses the ENTER.OBJECT routine.

CHECKSPACE works with three types of space: OPEN, ACCESS, and CLOSED. When

CHECKSPACE calls on ENTER.0BJECT, it passes only the ACCESS and CLOSED layout

space. It also provides an FCHECK routine for ENTER.OBJECT which stops

ENTER.OBJECT as soon as it tries to overlay CLOSED or ACCESS space. If

ENTER.OBJECT returns NIL, then CHECKSPACE returns NIL. If ENTER.OBJECT

returns a list of space blocks, CHECKSPACE checks the validity of their types.

If they are valid, CHECKSPACE returns TRUE, otherwise NIL.

46

View (VIEW)

The view constraint VIEW checks if certain specific points on a second

object can be seen from a given point on the first object when both objects

are in the layout. The points are located by searching the description of

the two objects using the two attributes which are passed to the evaluation

routine. The points found are used to form a space block. A check is then

made to see if this block overlays any CLOSED layout space blocks using the

ENTER.SB routine (a subroutine of the ENTER.OBJECT routine>. If it does, the

constraint fails.%

Path - Connectivity (CAOS and CAOS.R)

In the problems used, it was undesirable to specify each and every

possible desirable path, therefore, a general connectivity constraint was

required instead of a set of constraints requiring a passage from point Ai

to B.. The simplest connectivity constraint, CAOS, locates all isolated1

areas of ACCESS or OPEN space. This can be done using the spatial representation

routines to build up lists of adjacent space blocks from the adjacency

information stored in the spatial representation. If more than one list is

required for the ACCESS-0PEN space blocks, there is more than one isolated

area of ACCESS-0PEN space. This constraint is sufficient for problems in

which all the dimensions are in integer multiples.

If small, narrow, space blocks can be generated, the problem is more

complex, because a small, narrow passage will allow space connectivity but

prevent passage of any real object. In this case, a second description for

each object and the layout is required. In its second description, each

object space block has the same shape, but is slightly enlarged. These larger

objects are entered into the second layout representation in the same location

that they entered the primary representation. In this representation, CLOSED

areas are allowed to overlap. Any narrow passages which exist in the primary

47

representation will be covered in the secondary representation expansion

of the objects and the contraction of the rooms. The connectivity check

of the second layout description will detect if any remaining ACCESS-OPEN

areas are isolated. If not, all the ACCESS areas are connected by paths

whose width is twice the amount that the space blocks were enlarged by.

This checking technique does not guarantee the movement of a rectangular

cart down the remaining passages. It only guarantees that a circular

object of radius R can move from one point to another.

48

Footnote

IThe LISP system when run interpretively required approximately one

millisecond per iteration of a loop which added one to a variable. The LISP

system had a compiler which increased the speed of the simple loop by an

order of magnitude. Unfortunately, this compiler had "bugs" which preventedit from being used on DPS.

49

BIBLIOGRAPHY

Alexander, C. (1964) Notes on the Synthesis of Form. Harvard Univ. Press,

Cambridge, Mass., 1964.

(1965) The theory and invention of form. Architectural Record

Vol. 139, (April 1965), 177-186.

Davis, C. F., and Kennedy, M. D., (1970) "EPS: a computer program for the

evaluation of problem structure, in Emerging Methods of Environmental

Design and Planning, G. J. Moore (ed), The MIT Press, Cambridge, Mass.,1970.

Eastman, C. M. (1970) Representations for space planning. CACM, 13, 4,

(April 1970), 242-250.

(1972) Preliminary report on a system for general space planning.

CACM, 15, 2 (Feb. 1972), 76-87.

Feldman, J. A., Feldman, G.M., Falk, G., Grape, G., Pearlman, J., Sobel, I.,

and Jenebaum, J. M. (1969) The Stanford Hand-Eye Project. Proc. First

Joint International conference on Artificial Intelligence, 1969.

Gilmore, P. C. and Gomory, R. E. (1961) A linear programming approach to the

cutting stock problem. Operations Research 9, (1961), 849-859.

(1963) A linear programming approach to

the cutting stock problem -- part II. Operations Research ii, (1963),863-888.

Milne, M. (1970) CLUSTER: a structure finding algorithm, in Emerging

Methods of Environmental Design and Planning. G. J. Moore(ed), MIT

Press, Cambridge, Mass., 1970.

Moore, G. J. (ed.) (1970) 5m_ M_ in Environme_a!_ Desi_/__i_

_lannin_. MIT Press, Cambridge, Mass. 1970.

Newell, A. (1969) Heuristic programming: ill-structured problems. Progress

in Operations Research Vol. III, J. Aronsfsky (ed.), Wiley, 1969.

Newell, A. and Ernst, G. (1965) The search for generality. IFIPS 65. Vol. i,

Spartan Books, Washington, D.C., 1965. 17-24.

Newell, A. and Simon, If. A. (1963) GPS, a program that simulates human thought,

in Computers and Thought, E. Feigenbaum and J. Feldman (ed.),McGraw-Hill, 1963, 279-293.

(1972) Human Problem Solving. Prentice-Hall, Inc.

Englewood Cliffs, New Jersey, 1972.

5O

Nilson, N. J. (1969) A mobile automaton: an application of artificial

intelligence techniques. Proc. First Joint International Conference

on Artificial Intelligence. 1969.

(1971) Problem-Solving Methods in Artificial Intelligence.

McGraw-Hill, New York, 1971.

{)wen, C. L. (1970) DCMPOS: an algorithm for the decomposition of

nondirected graphs, in Emerging Methods of Environmental Design and

Planning, G. J. Moore (ed.), MIT Press, Cambridge, Mass., 1970.

Pfefferkorn, C. E. (1971) Computer Design of Equipment Layouts Using theDesign Problem Solver (DPS). Ph.D. Thesis, Carnegie-Mellon University,1971.

Pingle, K. K., Singer, J. A., and Wichman, W. M. (1968) Computer controlof mechanical arm through visual input. IFIP 68, Edinburgh, Scotland,

August 1968.

Raphail, B. (1968) Programming a robot. IFIP 68, Edinburgh, Scotland,August, 1968.

Simon, H. A. (1969) The Sciences of the Artificial. MIT Press, Cambridge,Mass. 1969.

(1971) The theory of problem solving. IFIPS 71. Invited

Papers, Vol. I, North Holland Publishing Co., Amsterdam, 1971, 249-266.

Slagle, J. R. (1971) Artificial Intelligence: The Heuristic Programming

Approach. McGraw-Hill, New York, 1971.

Sutherland, I. E. (1963a) SKETCHPAD: A Man-Machine Graphical Communication

System. Technical Report No. 296, Lincoln Laboratory, MIT, 30 January1963.

(1963b) SKETCHPAD: A machine graphical communication system.

Proc. SJCC: 63. Vol. 23, Spartan Books, New York, 329-346.

Tonge, F. M. (1961) A Heuristic Program for Assembly Line Balancing. Ph.D.Thesis, Carnegielnst. of Tech., Prentice-Hall, Englewood Cliffs, N.J., 1961.

(1963) Summary of a heuristic line balancing procedure, in

Computers and Thought, E. Feigenbaum and J. Feldman (ed.), McGraw-Hill,New York, 1963, 168-190.

Warnock, J. E. (1968) A Hidden Line Algorithm for Halftone Picture Representation.

Technical Report 4-5, Comp. Sci. Dept., Univ. of Utah, May 20, 1968.

Whitney, D. E. (1969) State space models of remote manipulations task. Proc.First Joint International Conference on Artificial Intelligence, 1969.

, Pfefferkorn -5]

Figure 1.

Examples of Different Constraints

Distance

The memory-bus cable between the central processor and the

memory module must be less than fifteen feet.

The operator should not walk more than twenty-five feet to

get from the computer console to the card reader.

The distance between the elevator door and the card reader

should be less than twenty feet.

Position

The computer should be in the left half of the room.The table should be to the left of the lamp.

Orientation

The memory unit should be behind the central processor.The desk should face the window.

The tape controller should be in line with the tape unitsand face the same direction

AdJacency

The bookcase should be against the wall.

The corner table should be placed in a corner.The table should be next to the terminal's left side.

Spatial

Two pieces of equipment cannot occupy the same space.

Access-areas of computer equipment may overlap.

View

You should be able to see the window from the door.

You should be able to see the television from the couch.

Path

You should be able to reach all access-areas from the door.

You should be able to walk from the console to the card reader.

, Pfefferkorn

Figure i.2 52

Constraint for the Living Room Problem

Distance Constraints

C1 must be less than 45 inches from CT

C2 must be less than 45 inches from CT

Ad_Jacency _Constraints

The back of T must be against the wall

The back of C1 must be against the wall

The back of C2 must be against the wall

The back of P must be against the wall

The back of BC must be against the wall

The back of BCA must be against the wall

The left side of CI must be against T

The right side of C__2must be against T

Final Layout for Living-Room-i

P._' "_ ,,'4, X /"-7""//-/ . -,.

,,-///f/////.. ,PP

Objects . .Space types

T --Corner Table Closed __

C2 --Couch __CT --Coffee Table Access .P --Piano

BC --Bookcase Open ! 'Ii ......BCA--Bookcase

Pfe£ferkorn

• ' Figure I.13 53

Constraints for Computer-Room-i

Distance

CABLE - Distance between the cable connections on OBJI and OBJ2 is less

than MAXD

OPER - Distance between the operator consoles on OBJI and OBJ2 is lessthan MAXD

CABLE OPER

OBJI OBJ2 MAXD OBJI OBJ2 MAXD

CP MI 2 CP CR 5

M1 M2 2 CP PR i0

TC TI 2 TI T2 5

TI T2 2 T2 T3 5

T2 T3 2 T3 TI 5

CP TC i0 CR PR 3

CP CR 5 CR PR 3

Room CR 4

Position

LEFTIND BELOWIND

M1 in left half of Room PR in lower half of Room

142 in left half of Room CR in lower half of Room

Orientation

FACE ORT

CP face console of T1 T1 horizontal with T2

CP face console of T2 T1 horizontal with T3

CP face console of T3 T1 horizontal with TC

CP face console of CR T2 horizontal with T1

CP face console of PR TC horizontal with T1

T1 face console of CP CR horizontal with PR

T2 face console of CP CR in front of CP

CR face console of CP M2 behind CP

PR face console of CP M2 behind CP

Final Layout Computer-Room-2

/,. /77-i / / / /fI / . . / ,_,J' - ×j" i _x"\ "k'_

! ." -,/. ,' ,,K, ,

Z// " /' '/ /. _ / ' ' '/ ,

Object Space TypeCP - Central Processor Closed

M1 - Memory Module J--7.,'.,'1I // ,

M2 - Memory Module Access ;,,__JCR- Card Reader [ iPR- Printer Open [__]

r Jk_l I _rc_u l-ll

• , J

54

Figure 21.i

Spatial Representation Property Lists

Element Attribute Value or Description of the Value

Object TYPE OBJECT or ROOM

SBLIST List of the convex polygons which define

the object or the room

PTLIST List of all the points associated with

the obJectXMAX The value of the maximum x-coordlnate of

the point defining the object

YMAX Maximum y-coordlnateXMIN Minimum x-coordlnate

YMIN Minimum y-coordlnate

DIR List of two points defining the direction

of the object

Space Block TYPE SBLOCK

SPACE TYPE The type of space this polygon representsSIDELIST The llst of sides in counter-clockwlse

order which defines the convex polygonXMAX The value of the maximum x-coordlnate of

the points defining the polygon

YMAX Maximum y-coordlnateXMIN Minimum x-coordinate

YMIN Minimum y-coordinate

UNL List of objects which overlay this

space block

Side TYPE SIDE

ENDPOINTS List of two points which define the sidein counter-clockwise order

NEXTTO The name of the side adjacent to this side

in the layout

UPSB The name of the convex polygon which th_s

side is part of

Point TYPE POINT

XCORD X-coordinate

YCORD Y-coordinate

. . Pfefferkorn55

49o

.r-3

0 _q' II- e-

O_ m

._ 04 o o• :>_ o ,-4

o

_r4 ...... r.D

, t

tl.

. Pfef£erkorn

56

Figure _._(Cone. )

e) Internal Representation Showing Some of the Interconnecttons

Kr

SBLISTCABLE

DIR /

SBI I" SB2

S_'_'_ _ _S 4 ' _'-_"_ _-"_S _"-'_S 8_'--"_ 9

E EP EP EP EP EP _ EP EP

PI_-'_PT2 P_3 --_T4____ PT5 -PT6 PTT_ CPT

I d) Internal Representation Showing More Interconnectlons

MTi SBLIST_ CABLE

i PTL_S>_ .

' 9 -

. /

_T_I _PT2 ._P_T4._.. PTS__PT6 p_CPT_=---"_

Figure 2.3 Pfefferkorn

Object Entering the Layout 57

Object I "'

o.t

i

i II .,I

III ,

I _

...... _- .. , i .......................... .J s_1_

Pfefferkorn• I,

58

Figure 2.4

Constraint Representation Property Lists

Element Attribute Value or Description

Constraint TYPE CONSTDEF

Definition FNI Name of the heuristic difficulty function

FN2 Name of the evaluation function

TYPEFNI Type difficulty function (SATV, OPTV, etc.)

TYPEFN2 Type evaluation function (SATV, OPTV, etc.)VKCTFNI Vector to be used in quantizing the difficulty

function

VECTFN2 Vector to be used in quantizing the evaluation

function

SEV Severity of the constraint

CILIST List of the constraint instances using thisdefinition

Constraint TYPE CONSTINST

Instance DEF Name of the constraint definition

CIT Constraint type (Distance, Position, etc.)

DEPVARL Dependent variable list (usually a list ofobjects)

INVARLFNI Independent variable list for the difficultyfunction

INVARLFN2 Independent variable list for the evaluationfunction

Pfefferkorn -

Figure 2;5 59

Internal Design Representation Property Lists

Element Attribute Value or Description of the Value

Design Description TYPE DESIGN

INITDESIGN Head of the description llst describing the

. initial problem

PLAN The current plan

OBJLIST List of objects in the design (layout

BOBJLIST List of base (lowest level) sub-objects in

the designDSTEP The current alternative

MTRYLIST List of acceptable alternatives generated

during the current stage

HISTALT List of unacceptable alternatives generated

during the current stage

TRYLIST List of unexplored alternatives

NRALT Number of alternatives generated so far

SBLIST List of the space blocks defining the layout

OPENCl List of open constraints

READYCI List of ready constraintsLAEVAL Name of the local-static-evaluation function

THRESHEN Name of the threshold function used in EVAL.

DESIGN.STEP

Initial Problem TYPE INITDESIGN

ROOMLIST List of rooms (usually one) to enter the design

OBJLIST List of objects to enter designCDLIST List of constraint definitions

CILIST List of constraint instances which must be

evaluated once

MCI List of constraint instances which must be

evaluated at each stage

Alternative TYPE ALT

OBJ Name of the object entering the designID The alternative's identification number

XCORD Value of the x-coordinate of the object'scenter

YCORD Value of the y-coordinate of the obJect'scenter

DIRL The direction the object facesPREVSTEP The name Of the alternative the current

alternative was created from

LAEVAL Value of the alternative's local-static

evaluation

TFAIL Name of the constraint causing the alternative

to be unsatisfactory

Pfefferkorn .

63

Figure 3.

The DPS Problem Solver

!

PLAN - _ USE.PLAN _ ADVANCE.DESIGN[

]Ki;__ !,_oc_._,I.......

tf == = l .

j _on',ou_ "/ TEST "_ _o'.

REDESIGN !_" REXAMINE ;_o Sol . __>

Figure 4. I65

Block-Prob lem- 1

I) Initial Problem

A) Objects

a) One 6x2 block b) One 4x2 block c] Three 2x3blocks B) Room- i' .C)n_ _qx_ /lax_ ......

d) One 2xl block

, ..i

I "II) Partial-Design Tree Box 85" 1

3 4 5

6 8 9 I0

11 13 16 32 36 37 53 55 57 58

17 18 22 23 25 26 27 31 38 43 44 46 47 48 50 52 5_9 61 63

* NO Alternatives Generated 64 6_ 68

F /_ FB21

III) Partial Designs _ 72

F

Alt 8 Alt 18 Alt 38 Alt I0

IV) Final Solution

Aft 69

66Figure 4.2

Solution T-Problem-i

A) Partial-Design Tree

+

T-Enclosure1

2 26 27 29

T

30 3.1 45

46 48 61

62 "_ 73F F

B) Final Layout -Alt.63

1" ,"I / /b'/,q

V /| /_-_ /<' Ii>}iIk"." /,"// /. _ /b</.." .....-,,,...., i".--/ /,-" .'"' i " / /" < .,

r//,.'." .,"i / i /.. . , .,)I / ,. / ; .' ,.. " / , "_// ,.....-,..!,/ i/ ,....,..,....-,.-I

/".' ." ' ' '""! i '" /.'/ iIV,,..,.......,.,-..,,,.........-J-JlIG'/.-"..".,! i.",,",'>,'.//,7.-./J//.,-. . I..".,,/."//'.//I

i.-//" i /" t .. / .." .,' .,"/ / / ..

V/..,,,"" // " ' '-"//'</ -"/,"/,,".II,....../ . .,i /_ <, .,/ .,,....,./ / . !

I.// .'///" ,/,"/..,".,...." '.,-" I

67

Figure 4.3

T - Pr ob 1era- 2

A) Objects

B) Partial-Design Tree t T-Enclosure

2 26 27 56 57

T3or \,.

58 75 89

I='- /_, VT2orT5 _

90 108 121

122 _ 133_ F

C) Final Layout the same as T-Problem-1 (Figure 4.2)

69

Figure 4.5

A) Final Layouts without Connectivity Constraints

i) Test Case 2) Small-Computer-Room-5

t,7-/!,f • - /' • . - //"

i / , //'/

B) Final Layouts using Connectivity Constraints

l) Small-Computer-Room-2 2) Small-Computer-Room-4.... d

.._ .Y" .i --'"--.Jl-"

Tree _ Smal l-Computer-Room-4C) Partial-Design

1

/_ CR .7_ 72 73

Ii 20 22 24 26 29 32 34 36 38 39 _4 79 80 84 102 104 106 I07

M PR , ,.

/ \40 69 F108 113 114 125F F ,..-Tn_ F

CP - Central Processor _ Closed SpaceM - Memory Module ,.----ICR - Card Reader _ Access Space

r---_

PR - Printer l......._ Open Space(CP,M) - Central Processor Memory Macro

Figure 4.6 70

Compu ter-Room- I

A) Objects and Room

ObJects Room

i., -

B) Constraints

Distance

CABLE - Distance between the cable connections on OBJI and OBJ2 is less than MAXD

OPER - Distance between the operator consoles on OBJI and OBJ2 is less than MAXD

CABLE OPER

OBJI OBJ2 MAXD OBJI OBJ2 MAXD

CP MI 2 CP CR 5

MI M2 2 CP PR I0

TC TI 2 TI T2 5

TI T2 2 T2 T3 5

T2 T3 2 T3 TI 5

CP TC I0 CR PR 3

CP CR 5 CR PR 3CP PR i0

Room CR 4

Position

LEFTIND BELOWIND

MI in left half of Room PR in lower half of Room

M2 in left half of Room CR in lower half of Room

Orientation

FACE ORT

CP faces console of TI TI horizontal with T2

CP faces console of T2 TI horizontal with T3

CP faces console of T3 TI horizontal with TC

CP faces console of CR T2 horizontal with TI

CP faces console of PR TC horizontal with TI

TI faces console of CP CR horizontal with PR

T2 faces console of CP PR horizontal ,with CR

T3 faces console of CP CR in front of CP

CR faces console of CP MI behind CP

PR faces console of CP M2 behind CP

71Figure 4.7

Set Decomposition by SPLAN

/ - .\(Cab ie, I) .... iC_a_ble, 3)......

i I (Cable, l)/ / !

, (Cable,i)/. , [ \ _.// / T1/

/ / 1

Set 1 M2 ,<" .// I_ (Oper, 2) I (Cable,l)

(Oper,2) / / (Cable,S) T!21

(Cable ,2_(Oper,3) ,,/ (Oper'2)il (Cable'1) 1// T3 ,

CR PR _(Oper, 1) z/'

--/r ............... \/"Remove Easy Constraints \

Set 2 /

M1 {Cable, I.]...........CP Set 3 TC

(Oper, 2) i (Cable,l)z

I '/" /

(Cable,i) / , T1

' /' / (Cable'2) l ; II M2 //." (Oper, 2) , (Cable,l), I" /// (Oper I)'\ ' T2

CR PR ,/................._ (Oper 2)'!7 .......... \ " • , ] (Cable,l)

/ , \_, T3

Set 4 Set 5 "\

" ',"// CRI/ M1 / "'./ t CP i

/

i I(Cable,1) '"..___ ,' (Oper,1) "_, / I ). / ; /

/

M2 / " /, ,. ¢

" _---_ 1 PR1 /"

Figure 4.8 72

Modifications to Handle Pre-built .Macros

A) Modified Versiop of DPS

PLAN ' i OBJECTS and i _ I _ !DESICN

' SIMPLIFY i ' 1i CONSLRAIN2Z__J ;

i J, , )sol......>, , [I t ._,, =

_odlfications I -- DESIGN REXAMINEi

B) Original Object-New Macro Objects

Original Objects _ New Macro Objects [_,lii'J_Q'I

C) The Reduced Constraints (Computer-Room-2)

Distance ,,

CABLE - Distance between the cable connections on OBJI and OBJ2 is less than MAXD

OPER - Distance between the operator consoles on OBJI and OBJ2 is *less than MAXD

CABLE OPER

OBJI OBJ2' MAXD OBJI OBJ2 MAXD

CP _il 2 CP CR-PR 5

CP T i0

CP CR-PR 5

Room CR-PR 4

Position

LEFT IND BELOWIND

M in left half of Room CR-PR in lower half of Room

Orientation

ORT

FA_ faces console of T CR-PR in front of CP

CP faces console of CR-PR M behind CPT faces console of CP

CR-PR faces console of P

Figure 4.10 74

Office A-2

A) Objects

Furniture Room

Desk Table Office •

Bookcase File Cabinets 3o ">\ ' . ...." ,," ' >"

' ,> ,.I_ 3_ . K 4_t >,I

30

B) Constraints Office A-2

Distance CPT of D to CPT of F2 < 45CPT of F1 to CPT of F2 < 20

Orientation F1 horizontal with DF2 horizontal with DT left of D

Adjacency Back of D against wallBack of FI against wall

Back of F2 against wall

C) Partial-Design Tree

1

" . . .

_- I 300 _3_. 3_i 33o 3si

el4 to5 _jo _i) 4ac_-,i _, 4_,,f,aq3f q_o qq3 q_ .5.5- F"

F g g /_---_ D) Final Layout

_,zL,........ ,

_'3u _/$7wS_ - _9'" ". ":-- .....-D - Desk . _, _. _,...=- ..>......

/ / /

FI - File cabinet (D, FI) Macro of D and FI ,.:", ,/F2- File cabinet (_,, F2) Macro of FI and F2 _ // ""BC - Bookcase

T-Table [.__!Open _ Closed _-,[qAcces s

76

Figure 4.13 77

Office B-I

A) Objects

i) Furniture 2) Office B

Desk Table ,K_, '7'-.',.""'"'_" _i"':

,ID,"\:"30 ..,..|...,, ......, .<:/

• So , It:¢'''_

_ ..:" ) "-;." ,

I \ .,.i/ I

Terminal File Cabinets K---_°---_/ _N_

B) Constraints

Distance F1 to F2 < 20 D) Final LayoutD to T < 50

T to office B < 90

Orientation FI horizontal with D I/-i-!, _IF2 horizontal with D ._" '" N,i./ ":-: !

T horizontal with rer _L ....K".....II" . '",_,_:

Back of F1 against wall

Back of F2 against wall i: " ,1_=£_']Right side of Ter next to T [ < "..J_:_,'

.View See Ter from D

C) Partial,<DesiEn Tree

2 3 _ 8 9 _o _ _1F:

q3 q? _

_q q_ /o_ /m:_t_5 -_? _,_' _ _i D - Deskr - :_.. -- ' . ..... = F1 - File Cabinet

,,, --_ T_ F2 - File Cabinet.......-- Ter- Terminal

/#_, /57 /,_ /./ :vc) :_:_ ,;'t _:_ ..i] 3_ 3_ J_ _23 _.;) T - Table

l _ BC - Bookcase1\,

Figure 4.1478

Office B-3, -4, and -S

A) Prebuilt Macro-objects

(D-T) - (Desk and Table)

F - (File-1 and File-2)

B) Common Constraints

Position (D-T) must be in the upper half of the room

Orientation (D-T) left of F

F right of '(D-T)

D horizontal with Ter

Ad_acencz, ' Back of (D-T) against wall

Back of F against wall

Back of BC against wall

View See Ter from (D-T)

C) Additional Constraints and Final Layouts

I) Office B-3 2) Office B-4Orientation D face window Orienatation D face away from window

,._¢_ o_J _ __- _,,1 4 .:,'_L_ - . -. \ ,\ _,, , ,

/t" i

3) Office B-5 Macro objects

Ad'acenc) , y Right side of Ter next" _Io,,J

_.._,'_'2L___._,_.__.t o (D-T) ... ,.... ,

r. JL4*'I "in-_ . t __ i _ _._ "__k!i _ I. . l,IJ,,l

I, _" /'] ' 'I Desk = (Desk and Table) File = (Filel and File2)

8O

Figure 4.16

TV-Room Problems

A) Constraints

Orientations C, C1, and C2 must be in front of the TVThe TV must be in front of C1 and C2

The backs of CT, TV, C1, C2, and C must be against the wall

View One must be able to see the TV from C, C1, and C2

B) Partial-Design Trees using different plans

1) TV-Room-1 2) TV-Room-3PLAN (C2, C1, C, T, TV) PLAN (T, C1, C2, TV,C)

(T C2) - Macro-object of T and C2 ;__o_o_ _o_ 2:_" 3_'IV - Television set

T - Corner table , 0b)ectsC1 - Couch TV - Television setC2 - Couch T - Corner tableC - Chair C1 - Couch

C2 - CouchC - Chair

C) Final Layout

A "/ ,

/" j/

82

Figure 4.18

Pattern Trim Problems

A) Objects B) Room

/ .< ./ / / / // / ,/......

C) Layouts Using MENV local staticevaluation function (minimum envelop)

Pattern-Trim-1

Pattern-Trim-2

D) Layouts Using MINX local static evaluation function (minimum X distance)

Pattern-Trim-4

Pattern-Trim-5

83

Figure 4.19

Assembly Line Balancing Problems

A) Eleven Unit Task Problem Final Layout

I ' iL"

!! l_i _o,ulo u1 Ul/]I

l....: I

/' ii ,q,l

I

iu_ ' --1, U5

, t uS_4

3---;

I i | .-_

Unused Space

B) Twenty-one Unit Task ProblemFinal Layout

i

i-----_

!

- --i"'"' ' i iUlI_l

, _i_i.... ,._\,/_---,---_ t" - , U_lui_,l I

1

Pfe fferkorn

Figuro .5.1 84

.omp_ri_on oE Dii'ferent _i)_tia] Representations

C) Hierarchical Array D) Adjacency 2;tructure

....:_:_.:'_:_:;i-_;.;:_-.r, m.:__S_-'/:L!:::-i/:i----_-4........................._...........4-:I

- -L. ' ' -+__.._.............................................. .---_I-

" _-_' "': ' ' _ _ ' _ -l::-_:q:_.__:-):-::_----,.......L -::__ !_7-'_--:--_-

__'_;--.... i__d'-ii...... i.:3-3-Z-;-"1,.1.':-[-;..-:-.-_....., _;-. i!.____;1__;__1_#_!7, ili ! ! !

H , " _ 1

: i J _ _ _"" _ I : :I H_ ! ! '_......_ .................................-----

__-< ; , .....t ' '-" I i i

-II/::_i_:!i;...._ ......I....- -'_, ,..................................................

Pfefferkorn

85

Figure 5.1(ccJr_t, )

E} String Representation F) Convc,× PolygonRepresentations

G) Comparison of Space Planning Representations using Eastlrian'sSample Layout

i

Number of Max. Max. Domains ! Structure !_epresentations Domains Zrror non- Error Require 'Simi.!ar i

Required psrrallel . Paral]e] Redef. in both !_axes ...... axg.._ 9xe_ ............;

iPlain array 1089 q•5 6.0 no y,_':_ !

i

_4ierarchical -[_iI 'q.5 6.0 ' yes yes 'array .......... ,

_d_acency 225 _. 5 0.0 yes yess tructur9 .... i

3tring ...._5 I 4.2 O. 0 yes l norepresent. 1 ' ., I_onvex "" 16 I 0 0 0 0 : yes yesI i •

polygon .......... ! ! ................... ,

86

Pfefferkorn

87

, Pfefferkorn 88