Fatal error: exception Invalid_argument("Random.int") while processing IntroClass/smallest.c

[Dearth]

Hello,

I have been attempting to recreate a few repairs from the IntroClass, specifically using the smallest programs. I have attached the test suite, configuration, and source code below. I have been unable to run genprog for more than 2-3 generations before "Fatal error: exception Invalid_argument("Random.int")" occurs and stops the run. We have tested this on a 2.X version of genprog and on v3.2 (including the most recent version of master).

The error typically appears at the beginning of a new generation.

Is this a known issue and if so does there exist an effective work around?

Thanks for your time,

Padraic

smallest.tar.gz

[jlacomis]

This exception happens in the random function when size is 0. This is an invalid argument to the Random.int function. It looks like one of the calls to random in mutate is passing an empty set to random, and I believe this should be illegal (i.e., random shouldn't just return 0 in this case), but I'll have to debug more. A PR addressing this should also add exception handling to random to make the error less cryptic if this happens again.

genprog-code/src/search.ml

Lines 161 to 164 in 234d263

	let random atom_set =
	let elts = List.rev (List.rev_map fst (WeightSet.elements atom_set)) in
	let size = List.length elts in
	List.nth elts (Random.int size)

[jlacomis]

Also I've found that on my machine the seed 992046101 fails at the start of generation 2, which is relatively early. I'm not sure if the same seed behaves the same on all machines.

[jlacomis]

Well, there's your problem! I'll have to figure out what to do about this.

genprog-code/src/search.ml

Lines 361 to 368 in 234d263

	(* CLG changed this in March 2012. Where before atom_mutate would pick a
	mutation and, if there existed no legal sources to fill in the rest of a
	mutation (such as append or swap), call itself recursively, removing that
	mutation from consideration, now it asks the representation what is legal at
	a given faulty atom and selects from there. Thus, if it picks append, it
	assumes that there exist valid append sources in that representation and does
	not check that the returned set is non-empty. If such a set *is* empty, in
	other words, atom_mutate will fail. *)

[jlacomis]

This issue isn't fully solved by #21 (which doesn't use the cache), but that patch should avoid crashes because of this.