							David Johnston
							CSE473


Welcome to Gate-World, where you let Prodigy design your ultimate computer
system.

1(a)- I was not able to model such circuits that responded to a clock, such
      as a clocked R-S flip-flop, or a counter.
      Also, if too many gates are present, Prodigy may wire them together
      in a fashion that is not the optimum.
      The language was NOT expressive enough for me to do what I wanted.
      Either that, or I don't know what I'm doing.  I generate two variables
      the same way to get all combinations of the two, but I did NOT want
      to check N1=A and N2=B if I already checked N1=B and N1=A.
1(b)- I thought at first it would be difficult to build the circuit first and
      test all possible inputs to see if they did what I wanted, but it
      turned out easy when I represented the logic as separate cases, each of
      which had separate outputs for separate inputs.
1(c)- It was useful to use the 'analyze' facility.  
1(d)- I would definately make a BETTER MANUAL.  One that actually describes
      in more detail, say, the search control meta-functions and how they
      work, and listed all of them with a description of each for example.

About the Domain:

Given a set of LS (left-side) RS (right-side) cases that describe what your
circuit is to accomplish, Prodigy will take the gates,inverters,switches,
and probes given to it, and assemble them in the right order to accomplish
your circuit description.
 
The goal should be several CASES of LS and RS clauses as follows:
(LS <Case#> <switch-name> <Truth-Value>)
(RS <Case#> <probe-name> <Truth-Value>)
Where the <Case#> is UNIQUE for a given line in a table representation of
truth values.  You would read it as: For Case#1, when (LS cases) are true,
then (RS cases) are true.  The following is a sample goal that Prodigy should
decide an Inverter would accomplish:
   (AND  (LS Case1 Switch-A L) (RS Case1 Probe-1 H)
	 (LS Case2 Switch-A H) (RS Case2 Probe-1 L))
The start state need only contain the gates, switches, and probes that MAY be
needed:
	(SWITCH Switch-A)
	(PROBE Probe-1)
	(INVERTER Inverter-1)
You can have more stuff, BUT, if you have switches in the start state that are
NOT mentioneed in your goal, Prodigy could use them to it's advantage and you
may not get the circuit you desired.  Extra probes, and gates are OK though.

Note:  I did have this represented as my own style of WHN clauses of the form
       (WHN ((cond1 val1) (cond2 val2)...) (result val-r)) but as Vaugn pointed
       out, he thought Prodigy would get confused since I was using lists as
       Individual items in my predicates.  I had lisp functions that looked
       into these lists and successfully binded them to prodigy variables,and
       Prodigy would solve one-step goals, but when it came time to put two
       goals together-- to satisfy a sub-goal, Prodigy would hick-up and say
       NO RELEVANT ALTS... So I changed the format  to the above, and it works.

All parts to be used must be specified in the state ahead of time, Prodigy will
not arbitrarily create them.  Parts are:
	(SWITCH my-switch)
	(AND-G my-and-gate)
	(OR-G my-or-gate)
	(INV-G my-invert-gate)
	(PROBE my-probe)

Prodigy connects these together, creating predicates of the form:
(CONN the-object input-number to-object)
 the-object = the object whose INPUT is being connected.
 input-number = 1 or 2, AND gates have 2 inputs, thus 2 CONN predicates.
 to-object = the object whose OUTPUT is going to the-object's inputs.

So (CONN And-1 1 Sw-1) reads Input 1 of and gate And-1 is connected to switch
sw-1.

Initially, Prodigy defines that all gates are connected to 'N'.

Switches do not have CONN's associated with them, because they only have an
output.  Probes, by the way, only have an input but no output.

Total Time So Far: 49hrs

Gate-World is part of NO other domain and was written from scratch.
Except for the function binding-list which was from page 59 of the manual.

--David Johnston
--johnston@wolf
