On May 5, 2012, at 6:06 PM, James McDermott wrote:
> Should the limit apply during initialisation also?
Nah. Initialization uses a tree generation operator and such operators use a variety of techniques.
>> BTW, your setup() method uses getInt( rather than getIntWithMax( but you're talking about maximums. That doesn't look right.
> Not sure if I understand this...? There's no limit on how large the
> user might want to set the maxSize parameter.
> I used the same approach as maxDepth, for which the setup method uses
> getInt(). Except that I used -1 as the default value which indicates
> that there's no maxSize. Is that ok?
getInt(..., -1) doesn't mean that there's no maxSize. -1 means that -1 is the smallest legal minimum size. I think what you were looking for was getInt(..., 1), indicating that any size 1 or greater is allowed.
>> We'd either need to enable ECJ to run without the max-size parameter in a parameter file or include it in the koza.params file.
> I think it should just default to the existing no-size-limit behaviour
> if the parameter isn't specified.
Except in a few cases, ECJ traditionally has avoided defaults because they tend to create Mysterious Unexplained Behavior. But maybe in this case it makes sense. If that's so, we should probably also set up maxDepth to work the same way, even though in koza.params max-depth will be set to 17 anyway.