public abstract class GPType extends Object implements Clique
In STGP, each function node has a return-type, and each of its arguments also have assigned types. Furthermore, the tree itself has a predefined "tree type". STGP permits crossover and mutation of trees only with the constraint that each node's return type "fits" with the corresponding argument type in the node's parent; further, the root node's return type must "fit" with the tree type.
The simplest definition of "fit" is that the types must be the same. Montana calls this "Basic" STGP (see section 2.1). This is the form of STGP that most implementations do, and it's not very powerful.
Montana further defined generic functions (ones with polymorphic data types). Such beasts "fit" only if the trees involved can be unified to make them fit, an expensive proceedure which ECJ does not support. However, ECJ's does support a compromise between simple "Basic" STGP and STGP with polymorphic types: providing both atomic types (basic STGP) and a more powerful notion of set types.
An atomic type is a basic GP type. Atomic types "fit" only if they're the same object (this implementation uses == ). A problem domain that only uses atomic types is essentially doing "Basic" STGP.
Set types are sets of atomic types. A set type "fits" with an atomic type only if it contains the atomic type in its set. A set type "fits" with another set type only if they share at least one atomic type in common (that is, the intersection of their sets is nonempty).
Set types allow for types which can fit in several different generic places -- an object can now say that it "fits" with types A or B or C, but not D or E.
GPTypes are a Clique, and they set themselves up as a group; in general you should not create any new GPTypes. You should also not attempt to clone them, since type equivalence is determined partially by pointer equivalence.
What Set and Atomic Types Can Do. Set and Atomic types can be used for most of the existing literature (major exceptions: Tina Yu's work, and also work on multiplying matricies with GP). For example, I am fairly certain that atomic types and set types can be used to implement any mechanism devisable using type inheritance along the lines of (Thomas Haynes, Dale Schoenefeld, and Roger Wainwright, "Type Inheritance in Strongly Typed Genetic Programming", Advances in Genetic Progrmming 2, pp. 359-376. Let's say that you wanted to define some classes a-la Haynes et al with multiple inheritance, say, a Vehicle, a Red-Thing, a Car (which is a Vehicle), a Truck (which is a Vehicle), and a Fire-Truck (which is a Truck and a Red-Thing). Now, you want to guarantee that children nodes fit with parents only if the return value of the children node is a subclass of the parents' argument slot. You can do this as follows: first, you create an atomic type for each of the classes above. Then you create the set types: Vehicle-S = {Vehicle}, Red-Thing-S = {Red-Thing}, Car-S = {Car,Vehicle}, Truck-S = {Truck,Vehicle}, and Fire-Truck-S = {Fire-Truck,Truck,Red-Thing}. Then you set up your function sets so that the return type of each node is an atomic type, and the argument types of nodes are set types. For example, if the function FOO is supposed to take a Fire Truck and a Car and return another Car, then you set the return type to Car, the first argument type to Fire-Truck-S, and the second return type to Car-S. The rest is left up to the reader as an excercise :-)
I also believe that set types and atomic types can handle most grammar-based mechanisms I've seen, which in general appear reducable to STGP anyway; for example, in Eric Jones and William Joines, "Genetic Design of Electronic Circuits". Late-Breaking Papers at the 1999 Genetic and Evolutionary Computatiokn Conference. 124-133.
Parameters
| base.a.size int >= 1 |
(number of atomic types) |
| base.s.size int >= 0 |
(number of set types) |
| base.a.n.name String |
(name of atomic type n. Must be different from other GPType names) |
| base.s.n.name String |
(name of set type n. Must be different from other GPType names) |
| base.s.n.size int >= 1 |
(number of atomic types in the set type n's set) |
| base.s.n.member.m String |
(name of atomic type member m in set type n) |
| Modifier and Type | Field and Description |
|---|---|
String |
name
The name of the type
|
static String |
P_NAME |
int |
type
The preassigned integer value for the type
|
| Constructor and Description |
|---|
GPType() |
| Modifier and Type | Method and Description |
|---|---|
abstract boolean |
compatibleWith(GPInitializer initializer,
GPType t)
Am I compatible with ("fit" with) t? For two atomic
types, this is done by direct pointer equality.
|
void |
setup(EvolutionState state,
Parameter base)
Sets up the object by reading it from the parameters stored
in state, built off of the parameter base base.
|
String |
toString()
Returns the type's name
|
static GPType |
typeFor(String typeName,
EvolutionState state)
Returns a type for a given name.
|
public static final String P_NAME
public String name
public int type
public abstract boolean compatibleWith(GPInitializer initializer, GPType t)
public void setup(EvolutionState state, Parameter base)
Setuppublic static GPType typeFor(String typeName, EvolutionState state)
Copyright © 2014 Evolutionary Computation Laboratory at George Mason University. All rights reserved.