Remove the speed optimisation in the stage 3 solver which makes the
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Fri, 1 Jun 2012 18:41:24 +0000 (18:41 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Fri, 1 Jun 2012 18:41:24 +0000 (18:41 +0000)
commit758fa9c36f68f6967f103169814c77070c99fed1
tree83371c33bf18b9e918f8ca36f7c256e22060f4f9
parent9706378d9b94cd7800c1c5fe5f3dded71b93f3e7
Remove the speed optimisation in the stage 3 solver which makes the
first loop only handle rightward or downward bridges (on the basis
that that way every bridge is looked at once rather than twice). This
seems to be breaking in the wake of recent changes to the solver, in
cases such as when island A is left of island B and has enough other
outgoing edges that only one bridge remains to potentially go to B,
but B is as yet unconstrained. In this situation the only code which
is able to adjust the maximum bridge count for that edge is the stage
3 solver (nothing else calls solve_join with is_max true), but it will
only do so if it _tries_ putting two bridges there and finds it
impossible, and when it starts from island A it won't even try.

Game ID which was insoluble just before this commit:
15x15m2:2a4d3b3c2h2d2a2a3c3w4a3m1d1a4a5a2d4d6e4q3e6a2a1e1b2g3a3o2g1d32l4b2c3a4c2b22l4a

This probably means I've done something else in recent checkins which
was not in accordance with the original solver design. However, this
fix will do for the moment.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9548 cda61777-01e9-0310-a592-d414129be87e
bridges.c