ECJ-INTEREST-L Archives

February 2014

ECJ-INTEREST-L@LISTSERV.GMU.EDU

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

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

Print Reply
Sender:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Sun, 16 Feb 2014 17:59:10 -0500
MIME-version:
1.0 (Mac OS X Mail 7.1 \(1827\))
Reply-To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Content-type:
text/plain; charset=iso-8859-1
Subject:
From:
Sean Luke <[log in to unmask]>
In-Reply-To:
Content-Transfer-Encoding:
8bit
Parts/Attachments:
text/plain (27 lines)
On Feb 16, 2014, at 3:17 PM, Raymond Shpeley <[log in to unmask]> wrote:

> I've run tutorial 4 with a run configuration of,
>  -file ec/app/tutorial4/tutorial4.params -p stat.gather-full=true
> on Eclipse.
> 
> The out.stat file has no final stats,

That's because the tutorial example does not implement the describe() method.  But all the stats are outputted.

I do note one oddity with the statistics you provided: though the system finds a solution that has a standardized fitness of 0.0, it's not the best individual of run!  This is for two reasons:

- Floating point error results in the both 0.0 and 1.6653345E-16 getting converted to an adjusted fitness of 1.0

- Comparison is done based on adjusted fitness; but determination of ideal individuals is done based on standardized fitness. [ In a perfect world, with no floating point error, this wouldn't be an issue]

So I think we should move the GP comparisons to be entirely based on standardized fitness.  Or alternatively swich to doubles.  Or both.

> The console didn't show any early termination.

Sure it did:

> Found Ideal Individual


Sean

ATOM RSS1 RSS2