Add files via upload

changes17nov23.txt

@@ -0,0 +1,60 @@
+
+17nov23
+
+hbox4 idea for adding consideration of totmovz:
+redefine new pri0 as int[ 0.9*pri0+ 0.1*(totmovz/4) ]
+and continue to use p2range 0..600. The "4" is a rough
+estimate of the typical ratio of moves to pushes, so
+I try to equilibrate moves & pushes, then give pushes
+90% weighting. Seems to work as intended:
+
+NEW method 3:
+hbox4_gnu games/takaken_14.sok 7 7.5 3
+...produces 2-519/58
+
+===================================================================
+updated method 0:
+hbox4_gnu games/takaken_14.sok 7 7.5 0
+...produces 2-693/58
+
+####################################################################
+
+Other changes for 2023:
+
+1) made nonHungarian method 2 "pure", i.e. I no longer use Hungarian
+ estimates for BOG (boxes on goals). I simply count them.
+2) added access to "baseline" methods. By adding 10 to the method number
+ selected, the endgame is immediate, i.e. only the first of four
+ priority measurands are used.
+3) I was already doing a calculation that could discern whether
+ the puller was in the corral of its goal, but was not using this
+ information. Now, if it is NOT, I add 1 to itpul (pri0). This
+ gives a slight penalty in that case, that turns out to be
+ significant, especially toward the "endgame" of the reverse
+ solution where it often happens that the puller is blocked
+ from its goal position by boxes.
+4) Finally, I am now more careful about when to declare the
+ "endgame". That is the point in the solution where I drop
+ 3 of 4 measurands. Now I track a running average of the last
+ four BOGs popped off the #1 priority queue, which optimizes
+ BOGs. If this average exceeds half the total boxes, then I
+ declare endgame.
+
+The last 2 changes reflect a common scenario in sokoban puzzles. It
+often happens that near the beginning and ending of the solution
+there are significant blockages: blocked boxes & blocked rooms. These
+blockages create corrals. So in the reverse game it often happens
+that the puller is trapped and cannot reach its goal, which is its
+starting position of the forward game. Forward solvers do not have
+this problem because the final position of the pusher does not matter.
+FoghNum #7 is a perfect example of this.
+
+Hence, I began to treat the puller goal more like the box goals by
+including it in priority zero. Recall that priority zero is used to
+break ties in the 4 "feature" queues (using the language of festival).
+
+Those blockages at both ends also explain why I discard 3 features
+at the halfway point: #corrals, #blockedRooms, #blockedBoxes. If I
+were to continue to try to minimize them, I would be resisting the 
+final configuration.
+