Content-Type: |
text/plain; charset="us-ascii" |
Date: |
Sat, 11 Jan 2014 09:42:09 -0500 |
Reply-To: |
|
Subject: |
|
From: |
|
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
|
MIME-Version: |
1.0 (Apple Message framework v1085) |
Sender: |
|
Parts/Attachments: |
|
|
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
|
|
|