[Retros] "half" proof games

[Francois Labelle]

Noam Elkies wrote:


> I simply hadn't expected that you'd answer my post by feeding my moves

> into your program! I guess that your I/O routine happens to just ignore

> ":", as well as stray characters like the 6 in Richard's typo B6d8.


If you think about it for a moment, this doesn't make much sense. It would
make sense if there were a few ":" hidden somewhere in a big list of
problems. But in this case there were many colons and few problems so I
obviously saw the colons, and I know that my program doesn't accept ":"
(because I wrote the program), so I would never feed those moves into my
program without a fix.

For some reason I was determined to solve these problems by computer
without spending even one second to try to understand what was going on. I
am regretting it now, because those compositions were ingenious.


> 1) What move generating routines do you use for your investigation?


My own move generator. I also wrote a Standard Algebraic Notation engine,
but I didn't use it for this: it was faster to hardcode each problem. I
admit I did one mistake while doing it, which led me to say that this
problem had only 1 solution:

1.g4 ...    2.gh5 ... 3.hg6 ... 4.g7 ... 5.gh8Q+ ...
6.Qxg8+ ... 7.Qxf8+ ... 8.d3 ... 9.Bd2 ... 10.Ba5 ...
11.Bxd8 ... 12.Qc1 ...#

while it had 2 (as pointed out by Joost de Heer and later by Richard
Stanley).

If you guys ask me to check 20 more problems of this type, then it'll be
worth using my SAN engine instead, and there won't be any mistake.


> 2) Have you tried to adapt your methods to "one-sided proof games" --

> White series from either the opening array (16+16) or only White's men

> (16+0)?


No I didn't try. The fact that there are two natural versions of one-sided
proof games (16+16 and 16+0) turns me off, but ok, it wouldn't be too hard
to program such problems.

Exactly which "one-sided proof game" questions would you like me to
answer?


oliver sick wrote:


> In my opinion there is a principal question in the 'truth' of your

> numerical statements.  If we see your counting results as mathematical

> results (and they are of mathematical nature), then we need a base to

> check the truth of the statements. And as far as I can see this can only

> be done by writing an own program and rechecking the results or by

> checking and testing your source code. Do you intend to publish it?


For chess enumeration problems, I believe that only a totally independent
reimplementation is a satisfactory test for correctness. I encourage
anyone to write their own program (or adapt one of the hundreds of
available chess engines) and confirm my results. This is partly why my
source code isn't available, to make sure that any confirmation someone
makes is totally independent.

So although the results are "mathematical", I think that in this case the
best approach to get to the "truth" is closer to what is done in
experimental physics.


> Or did I miss the point and it is actually published to some other

> people currently checking it ??


Well, in a lot of cases the numbers have been computed by other people
first, and I'm the one who is checking them! Notably this is the case for
the number of chess games after 10 plies (69352859712417) and the number
of distinct chess positions after 8 plies (988187354). Check the credits
in the Encyclopedia of Integer Sequences, you'll see many different
contributors.

In cases where I'm the first one to compute something, I need to publish
it so that other people can confirm it. Or if you prefer, I'm leaving
myself open to attacks by publishing as many falsifiable claims as
possible. I'm definitely also interested in the "truth". When I didn't get
the expected number of massacre SPGs, I didn't try to hide this
embarrassing fact, instead I went forward with my weird result. It turns
out I had discovered a new SPG.

	Francois