Print

Print


Dear Sean,

Thanks for the prompt reply which does make sense.  I am also short of time
and as a nasty work around I include a Boolean terminal in the function set
but then penalise any GP which uses it.  Seems to work fine!  I will get
back to this later and will inform the list if I find a good solution.  Any
info from others still appreciated,

Regards,

Laurie


-----Original Message-----
From: Sean Luke [mailto:[log in to unmask]]
Sent: 07 July 2004 16:55
To: [log in to unmask]
Subject: Re: Terminals in Strongly Typed GP

On Jul 7, 2004, at 6:30 AM, Hirsch Laurence wrote:

> My question is probably very basic as I am just getting to grips with
> the system (and learning Java as I go).  I am trying to build a
> strongly typed GP system where the terminals are of type String, some
> functions take string arguments and return Booleans and others take
> Boolean arguments and return Booleans.  Each GP returns a Boolean.
> When I try to implement this I get an error from GPTreeConstraints
> saying that: "no terminals are given with the return type Boolean
> which is required by other functions in the function set. PARAMETER:
> gp.tc.0 ".  But in my case I don't want to have any Boolean terminals.

ECJ has a restriction which can be a gotcha for some: generally
speaking, there must exist a terminal which returns every possible
return type.  This restriction can be lifted, but first some
explanation.  The problem is that ECJ doesn't know what kind of
tree-generation algorithm you're planning to use beforehand.  Many such
algorithms (GROW, FULL, PTC1, PTC2, RAMPED-HALF-HALF, come to mind
immediately) need to be able to attach terminals at *any* *time*.  To
do this, ECJ has to be able to have a terminal available for any
possible situation.  This isn't a misfeature in ECJ: it's an
unfortunate consequence of the tree-building algorithms in use right
now.

How to fix this?  You need to do two things:
        - Find or create a tree building algorithm which is robust against
missing terminals
        - Release ECJ's restriction.

The second is easy: just hack out the relevant error in
GPTreeConstraints.java.  The first may not be so easy.  I think that
Uniform may be able to already handle missing terminals but I'm not
sure -- I've never tried it.  PTC2 could be modified so that when the
algorithm needs to add a terminal, it *tries* to add a terminal, but if
it can't, it adds a nonterminal and then tries again recursively to add
terminals.  PTC1/GROW might be similarly modifiable.

Unfortunately I do not have much time to think about which tree
builders could be used/modified: certain NSF grants loom.  But I know
that other people have asked this question in the past and may have
come up with a workaround already (thus faster than I will). I'm cc:ing
David Chan here because I know he had had the same gotcha a while back.

In the mean time, anyone in the discussion list -- solutions?

Sean