ECJ-INTEREST-L Archives

February 2006

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show HTML 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:
George Coles <[log in to unmask]>
Reply To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Wed, 1 Feb 2006 16:19:03 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
Hi,
   I am pretty sure that this is not to be found in ECJ, but I wanted to 
run it by the list. Is there any way to constraint nodes so that you can 
prevent Node A from ever appearing within the "scope" of Node B, i.e. 
anywhere below it in the tree? I don't think a constraint based on 
return type is sufficient.

I was thinking that I would override checkConstraints to support 
knowledge of  illegal parent/child relationships such as this but when I 
looked more carefuly I realized that if constraints are violated the 
entire run fails. I had in mind something more along the lines of 
"before you try to add this node to this other node, call 
checkConstraints(), passing in the prospective child and get true/false 
back." But I guess the logic for checking to see whether one node should 
be added to another is scattered around. Another thing I have run up 
against is that I want to keep a node from evaluating itself unless any 
nodes have been added or changed below it. But GPNodes don't really know 
when they have been added to. I created an addNode() method that I added 
to GPNode. In addition I would like to change checkConstraints to return 
a bool, but it involves some work.

But to return to my originial question -- does anyone have a suggestion 
for expressing and enforcing the type constraint I referred to above? I 
guess you might call it a syntactic constraint?

ATOM RSS1 RSS2