A few days back I wrote a big long message about how types != data  
types.  Check it out.  In short: types are merely mechanisms by which  
you can constrain who's allowed to connect to whom as a child node.

If you only have two variables, you might do things this way.  Let's  
say that your > function only accepts variable nodes, and not larger  
subtrees, as children.  Then you could state that variable A returns  
type A and variable B returns type B, and you have TWO different >  
functions:

	>AB has child types A and B
	>BA has child types B and A

Other nodes which accept both A and B can do this by having as child  
type the SET type {A, B}.

You'll probably find, though, that more complex typing may be  
difficult to do with ECJ's typing strategy -- you may need a  
polymorphic type mechanism, and ECJ doesn't support that.  I think EO  
might, at least with Maarten's extensions.

A lot of the problems here are also that though it's straightforward  
to define typing from a grammatical standpoint, it's much harder to  
do so in a way that still allows sufficient leeway on behalf of  
mutation and crossover to allow for an evolutionary system to operate  
successfully.  More typing = more constraints = fewer options for the  
EC system.  Another approach is to go with Grammatical Evolution  
(GE), Conor Ryan's approach, which you may find to be pretty useful  
if your typing needs get high.

Sean


On Apr 16, 2008, at 9:47 AM, Shane wrote:

> In gp:  I have a boolean function GreaterThan that I use to compare  
> two variables, but I want to make sure that I am not comparing the  
> same two variables.  In other words,
>
> > var1  var2  is ok, and
> > var1  var2  is ok, but
> > var1 var1 is not ok, and
> > var2 var2 is not ok either.
>
> Here is the node constraint for the boolean function (from params  
> file):
>
> gp.nc.4 = ec.gp.GPNodeConstraints
> gp.nc.4.name = ncBool-Child1Nil-Child2Nil
> gp.nc.4.returns = bool
> gp.nc.4.size = 2
> gp.nc.4.child.0 = nil
> gp.nc.4.child.1 = nil
>
> Is there a way to restrict this behavior in the params file?  The  
> children will be of the same type, but can't be the same variable.   
> Or do I have to do something in the checkConstraints method of the  
> GPNode?
>
> Shane
>