WELD%MIT-OZ@MIT-MC.ARPA (04/09/84)
From: "Daniel S. Weld" <WELD%MIT-OZ@MIT-MC.ARPA>
[Forwarded from the MIT bboard by SASW@MIT-MC.]
AI Revolving Seminar
Wednesday, April 11, 4:00pm 8th floor playroom
Jerry Roylance -- "Programs that Design Circuits"
People can design circuits; this task -- at least partially --
can be done by computers. I'll talk about how designers think about
circuits and how to make computers think that way, too. While the talk
will be directed toward circuit design, that is not the sole intent.
How will building problem solvers in one engineering domain help us
build them in other domains? What "domain-independent" facts can be
carried across?
Engineering domains (such as circuit design) are good ones to
teach computers. They have well defined models that let the machine
verify and debug its designs (thus allowing some chance at creativity).
Engineering domains also have many "standard problems" with cookbook
solutions. If the computer can be clever about recognizing instances of
these problems and combining them together, it can produce nontrivial
designs. The quality of a design in an engineering domain is also easy
to assess.
The circuit design domain is not simple, however. Hierarchical
expansion of abstract components fails to account for many designs. The
parts of a design are not independent and that makes it difficult for
the knowledge sources to be modular. Arithmetic constraints solve some
of these problems; some others can be solved by manipulating mechanism
constraints.
An important perspective: when teaching a system a new trick,
find out why the some one thought of that trick in the first place.