Types are not data passed between nodes.  They are merely constraints placed on the nodes to enforce rules about which nodes can connect to which nodes.

Now, it's true that types often are correlated with the kinds of data that nodes send to each other, but that's hardly a requirement.  For example, we're using types right now simply to force certain kinds of nodes to appear in the top area of a tree but not down near the leaf nodes.

The most common situation you'll find is argument types which are set types, and return types which are atomic types.  For example, you might have a node which returns int plugged into an argument which can accept int or double.  You've seen that before in real programming languages I'm sure: the + operator in most programming languages can take floats, ints, doubles, longs, bytes, indeed in some cases strings.

All you have to do is handle multiple kinds of data in your GPData object.  The typing mechanism merely guarantees that when a node receives a GPData object, what you receive has been constrained in a way that you had specified.  

Sean

On Jan 11, 2014, at 10:52 AM, Jake Ehrlich wrote:

> OK that explains more. Thanks for the clarification
> 
> As to the example, yes you understood. I am still confused however on how something of type {s, i} can be passed in to something expecting an integer. What if that something returned a string?
> 
> On Jan 11, 2014 8:59 AM, "Sean Luke" <[log in to unmask]> wrote:
> On Jan 11, 2014, at 2:00 AM, Jake Ehrlich wrote:
> 
> > In the documentation for ec.gp.koza.CrossoverPipeline it says "Then a random
> > node is chosen in each tree such that the two nodes have the same return
> > type". Does "same return type" in that quote mean that the types "fit" by
> > GType's compatibleWith method?
> 
> The documentation is misleading.  The correct form is:
> 
> Two nodes M and N are chosen.  Let R(N) and R(M) be the return types of
> M and N respective.  Let A(N) and A(M) be the types of the argument slots
> which N and M respectively fill in their parents.  Then M and N are only
> valid if R(N) is type compatible with A(M) and R(M) is type compatible
> with A(N).
> 
> > First off as I understand it GType.compatibleWith is assumed to be
> > commutative (that is t1.compatibleWith(init, t2) is true if and only if
> > t2.compatibleWith(init, t1) is true). Is this correct or is it just one way?
> 
> compatibleWith is commutative.
> 
> 
> > Say you have a node X of type {string, int} (a set type) and another node Y of
> > type int (an atomic type). X and Y are being passed in as parameters of type
> > {string, int} and int respeticvlly. These return types are "compatible" ("fit") by
> > the definition of compatibleWith for GPAtomicType and GPSetType yet you
> > shouldn't be allowed to swap them sense the parameter type of X's parent
> > can't handle a string, only an int.
> 
> Let me make sure I understand what you're saying.  Node X is of return type {s,i} and it's attached to an argument slot of type {s,i}.  And node Y is of return type i and is attached to an argument slot of type i. If you swapped them, then node X would now be in the argument slot i (which it is type-compatible with) and node Y would now be in argument slot {s,i} (which it is also type-compatible with) so everything would be fine.
> 
> Sean