ECJ-INTEREST-L Archives

March 2017

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:
Tue, 14 Mar 2017 08:11:20 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (33 lines)
On Mar 14, 2017, at 1:53 AM, Warren Henning <[log in to unmask]> wrote:

> - Does ECJ have any functionality to achieve the above goals built in?

No.

> - If not, what would be the best way to accomplish these goals?

What I would do is edit the trees lazily during evaluation time.  I'd do something like this:

PROCEDURE EditNode(node)
	if node is a leaf, return FALSE
	else 
		changed = FALSE
		Foreach child of node
			changed = changed OR EditNode(child)
		Apply replacement rules on node and its immediate children
		If a rule applied, changed = TRUE
		return changed

For each tree in individual
	Repeat
		changed = EditNode(root of tree)
	Until changed = FALSE

If your transformation rules always have upwards effects you don't even have to return anything (it'd be one pass through the tree).

> - Would simplifying constant expressions be effective during evolution for bloat control? Doing this every generation to keep individuals small seems worth trying.

Maybe.  There's been a significant amount of past work on code editing as a bloat control mechanism.

Sean

ATOM RSS1 RSS2