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,
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
How to fix this? You need to do two things:
- Find or create a tree building algorithm which is robust against
- 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?