Performance is not good enough on large fillomino problems

[T0nyX1ang]

Performance is not good enough on large fillomino problems

[T0nyX1ang]

The new methods can be somewhat faster, but there are edge cases for the original solvers and new solvers.
I added two examples to demonstrate the issue.

[T0nyX1ang]

After trying out some approaches, we decide to introduce a "fast mode" where the solutions will be restricted on a certain range.

• The numbers are taken from (1-5 + the given clues on board) to limit to solution space.

The method can work well on all cases, and the worst case takes about 2.5x time than the original solver.
The development of fillomino is postponed now.

[T0nyX1ang]

Here is another edge case: https://github.com/tomvbussel/fillomino/blob/master/problems/p76.fillomino
We may assume that the solver will degrade when there are many long "snakes" in it.

[T0nyX1ang]

The same problem exists for heteromino puzzles.

Some changes are made to resolve heteromino issues.

[T0nyX1ang]

For a full analysis, solver is slow on large problems of:

• fillomino
• haisu
• kurotto
• shikaku

[T0nyX1ang]

shikaku problems have been greatly optimized by latest commit af7bd76
haisu problems have been greatly optimized (but have some edge cases) by recent commit 3849683

[zhuyaoyu]

The edge case for haisu is solved by recent commit 2e05066, by adding
rule += ":- clue_area(A), grid(R, C), haisu_count(R, C, A, N1), haisu_count(R, C, A, N2), N1 < N2.\n".

The only remaining slow puzzle is fillomino.

[T0nyX1ang]

The edge case for fillomino becomes faster by recent commit 48ddc1b, by using grid_src_color_connected instead of grid_branch_color_connected in initial points.

[T0nyX1ang]

After some approaches, we decided to set the problem aside for a while.