--- In fc-solve-discuss_at_yahoogroups.com, Shlomi Fish <shlomif_at_...> wrote:
>
> One I multiplied the quota of every flare by 100 (by adding two zeros at the
> end), I reached a much shorter solution:
>
> --flares-choice fcpro
> Started at 1352801110.135407
> [[Num Iters]]=4927507
> [[Num FCS Moves]]=92
> [[Num FCPro Moves]]=44
> [[Start]]
> 3a 3b 3c 3d 37 38 d8 87 c3 5d
> 53 5c 56 a5 85 8a 8h 47 28 d2
> 27 42 4d 46 2h 36 17 41 78 7a
> 83 8h 7h dh a7 65 6d 6a 62 d2
> 27 1a 1d 13
> [[End]]
> Reached Board No. 6240 at 1352801147.647599 (total_num_iters=4927507)
>
> The problem is that this takes many seconds and consumes over 30% of my 8 GB
> of RAM.
>
> 2. Even if we take the original issue with these moves being redundant, then
> it would be hard to optimise them with the current architecture of the solver,
> because they fall in between two meta-moves:
>
> I could try working on a better optimisation scan (I have some ideas about how
> to create an improved one), but I solved this particular case for this board
> in mfi-with-2-more-scans.sh .
>
You have an excellent solution with 44 moves. I can understand that it took the extra execution time.
As for (2), maybe some of what I did in my solver can be applied to FCS. My solver is configured to run as many as three "passes" on a deal while looking for a solution. Pass_1 and Pass_2 have constraints that improve performance at the risk of a false-negative. On the first 1,000,000 deals, all but four solveable deals are found in Pass_1. The remaining four deals are found in Pass_2, with no deals needing to be processed in Pass_3.
Maybe adding some of my Pass_1 constraints to your solver's first level will reduce the number of layouts examined and the amount of memory used. I'm considering other constraints that may still keep my solver's Pass_1 results high while shortening solutions in the process. We can discuss them as well.
Received on Tue Nov 13 2012 - 08:27:17 IST