ECJ-INTEREST-L Archives

June 2005

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Thu, 9 Jun 2005 15:41:00 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (158 lines)
Artur, I posted mail about this but I can't find a copy of it anywhere;
perhaps it didn't go through.  So to recap:

ECJ "requires" the existence of a terminal with every possible return
type because that's a requirement of almost all of the tree-builders in
the ECJ toolkit.  PTC1, PTC2, GROW, FULL, RAMPED HALF-HALF, etc. all
must be able to stick in a terminal at any time and for any reason, or
otherwise they will not operate properly.

But don't lose hope!  I *believe* that UNIFORM does not have this
restriction.  If you change your tree builder to UNIFORM, then just go
into GPTreeConstraints and change state.output.error(...) to
state.output.warning(...) and you should be good to go (knocks on
wood).

Sean

On Jun 9, 2005, at 6:25 AM, Artur Matos wrote:

> (Sorry, in my previous posting I forgot to add the subject line, and
> also the tree ASCII diagram got garbled. I am posting the corrected
> version now)
>
> Hi to all,
>
> I am trying to use ECJ's strongly-typed GP implementation, but I am
> having some issues with it. Currently, I
> am trying to evolve trees that look like this:
>
>                                    Par
>                                     |
>                            -----------------------
>                           |                       |
>                         Seq               Weight
>                           |                        |
>              ---------------               --------------------
>              |             |               |                   |
>           Weight  Weight        0.32            0.54
>              |              |
>    -----------          -------------
>   |          |          |           |
> 0.1     0.93     0.5       0.2
>
>
> Basically, there are 4 types of nodes: "Par", "Seq", "Weight", and
> Ephemeral Random Constants (represented by the numbers
> in the leaves). In this representation, the top node must always be an
> instance of either "Par", "Seq", or "Weight"; the leaves must
> always be ERCs. "Par" and "Seq" children must always be instances of
> either "Par", "Seq", or "Weight"; only "Weight" has ERCs (and
> can only have ERCs) as children. (In case you are familiar with it,
> this is just a simplified version of Gruau's cellular encoding model.)
>
> To model this, I have tried to define my parameter file like this.
> First I defined two atomic types, "edge" for the regular type
> (returned by "Par","Seq", and "Weight"), and "real" for the ERCs:
>
> ---------------------------------------------------------------
> gp.type.a.size = 2
> gp.type.s.size = 0
> gp.type.a.0.name = edge
> gp.type.a.1.name = real
> ---------------------------------------------------------------
>
> I defined my GP individuals with only one tree, returning the "edge"
> datatype at the topmost node:
>
> -----------------------------------------------------------------------
> -------------
> pop.subpop.0.species.ind.numtrees = 1
> pop.subpop.0.species.ind.tree.0 = ec.gp.GPTree
> pop.subpop.0.species.ind.tree.0.tc = tc0
>
>
> gp.tc.size = 1
> gp.tc.0 = ec.gp.GPTreeConstraints
> gp.tc.0.name = tc0
> gp.tc.0.fset = f0
> gp.tc.0.returns = edge
> -----------------------------------------------------------------------
> --------------
>
> And defined 3 node constraints. nc0 is used for the ERCs, nc1 for
> "Par" and "Seq"; nc2 for "Weight":
>
> -----------------------------------------------------------------------
> ---------------
> gp.nc.0 = ec.gp.GPNodeConstraints
> gp.nc.0.name = nc0
> gp.nc.0.returns = real
> gp.nc.0.size = 0
>
> gp.nc.1 = ec.gp.GPNodeConstraints
> gp.nc.1.name = nc1
> gp.nc.1.returns = edge
> gp.nc.1.size = 2
> gp.nc.1.child.0 = edge
> gp.nc.1.child.1 = edge
>
> gp.nc.2 = ec.gp.GPNodeConstraints
> gp.nc.2.name = nc2
> gp.nc.2.returns = edge
> gp.nc.2.size = 2
> gp.nc.2.child.0 = real
> gp.nc.2.child.1 = real
> -----------------------------------------------------------------------
> ---------------------
>
> Therefore my function set is like this:
>
> -----------------------------------------------------------------------
> ---------------------
> gp.fs.0.size = 4
> gp.fs.0.func.0 = org.amatos.evodevo.growthmodels.cellularencoder.Par
> gp.fs.0.func.0.nc = nc1
> gp.fs.0.func.1 = org.amatos.evodevo.growthmodels.cellularencoder.Seq
> gp.fs.0.func.1.nc = nc1
> gp.fs.0.func.2 = org.amatos.evodevo.growthmodels.cellularencoder.Weight
> gp.fs.0.func.2.nc = nc2
> gp.fs.0.func.3 =
> org.amatos.evodevo.growthmodels.cellularencoder.WeightERC
> gp.fs.0.func.3.nc = nc0
> -----------------------------------------------------------------------
> ----------------------
>
>
> Now, when I try to run ECJ with these params, I get the following
> error message:
>
> -----------------------------------------------------------------------
> ------------------------------------------
> ERROR:
> In function set f0 for the GPTreeConstraints tc0, no terminals are
> given with the return type edge which is required by other functions
> in the function set.
> PARAMETER: gp.tc.0
> WARNING:
> In function set f0 for the GPTreeConstraints tc0, no *nonterminals*
> are given with the return type real which is required by other
> functions in the function set.  This may or may not be a problem for
> you.
> PARAMETER: gp.tc.0
> SYSTEM EXITING FROM ERRORS
> -----------------------------------------------------------------------
> ------------------------------------------
>
> I really don't understand why in this case ECJ requires terminals
> returning edges (and conversely non-terminals returning reals).
> Shouldn't ECJ
> be able to generate trees even without these nodes defined? Is this
> related to the GPNodeBuilder used? or do I need to separate my
> functions into
> 2 different function sets?
>
> Best regards,
>
> Artur Matos.

ATOM RSS1 RSS2