On 03/07/2013 07:55, Sergii Dymchenko wrote: > > Strangely, doing search inside Gecode (with gfd:search(Qs, 0, > most_constrained, indomain_median, complete, []) ) eats memory very fast > compared to gfd_search:search(Qs, 0, most_constrained, indomain_median, > complete, []) with large cloning_distance. As I said, cloning_distance only applies to doing the search in ECLiPSe, because cloning and recomputation is then controlled by GFD. If you do the search within Gecode, i.e. using gfd:search/5, the search is controlled by Gecode, and you need to tell Gecode to change its cloning frequency -- you do this with the control(...) option with the commit_distance and adaptive_distance parameters: search(Xs, 0, most_constrained, indomain_media, complete, [control(gfd_control{commit_distance:100,adaptive_distance:100})]) You can find more information on gfd search/5 in the reference documentation (i.e. with help/1), but the two distance parameters are from Gecode itself, and you can get more information on them from the Gecode documentation. I would be surprised if the memory behaviour with doing search in Gecode would be very different from doing it in ECLiPSe, though (with the cloning frequency changed appropriately). If it is very different, then I would be very interested in hearing about it and figuring out why. Cheers, KishReceived on Wed Jul 03 2013 - 16:36:14 CEST
This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:20 CEST