[Retros] A new program to solve fairy proof games

CAILLAUD Michel caillaud1957 at gmail.com
Fri Nov 3 13:06:55 EDT 2017


I made further successful experiments ih solving proofgames with "mode
Tacu"..
With one misadventure :
after hours of solving and 100% exploration, there was no solution.
investigation showed that I made a mistake in entering the "phantom"
Forsyth : writing XX1 instead of X1X...
Maybe in a future version, François can make "mode Tacu" as an option,
generating automatically the data that otherwise are subject to human error?


On Thu, Nov 2, 2017 at 1:52 PM, CAILLAUD Michel <caillaud1957 at gmail.com>
wrote:

> Hi François,
>
> For a non specialist, the "double solving" with "Tacu trick" looks like
> black magic, but it works!!
> I tested it on another example where Jacobi underperforms compared to
> Popeye.
> The characteristic of underperformance cases I found was (near) homebase
> position, with rebirth or not.
> As it is without rebirth, maybe you would like to incorporate it in your
> tests :
> dia 10.5 1sbq2sr/p1pppp1p/8/8/8/5S2/2PP2PP/bSBQKB1R condition LosingChess
> These are the 10.5 first moves of PDB P1271173, a problem by Thomas
> Thannheiser.
> The performance I got are :
> Popeye 4.61 -maxmem 4000M : 1h20mn
> (I use older versions of Popeye as performances of solving are degradated
> with newer versions...)
> Jacobi 0.1 "double solving" : 1h40mn
> I stopped "regular Jacobi" after 1 hour and 3.3% exploring (!)
> (my computer is not the top : on the example by Dirk Borst, I got 3 times
> the time you indicate).
>
> Best,
> Michel
>
>
>
> On Thu, Nov 2, 2017 at 2:51 AM, François Labelle <flab at wismuth.com> wrote:
>
>> Marco Bonavoglia wrote:
>>
>>> Great program, thanks! I checked it with different fairy SPGs with
>>> excellent results, with one strange exception:
>>> PDB P1066705 (Initial position without BPh7 SPG4.0 Circe)
>>>
>>> Popeye solves it in abt 50 seconds, Jacobi takes a lot of time, after
>>> ten minutes it's at about 11% and has analyzed only 1. Sc3 1. Sa3 and was
>>> analyzing 1. Sh3 when I stopped it.
>>> I think it could take more than one hour. This on my laptop (with i7)
>>> using Chrome or Firefox (I tried both). Is it the homebase position that
>>> "confuses" Jacobi, or may be is a bug?
>>>
>>
>> Hi Marco,
>>
>> Thank you for this example. On my laptop Jacobi took 1339 s, and Popeye
>> 4.79 took 33 s. This is a huge difference!
>>
>> Currently the PG solver is not very smart. In Circe it doesn't assign any
>> cost to a rebirth, so if the final diagram is homebase it's playing pretty
>> much any move during the game.
>>
>> The good news is that Jacobi solves the "Tacu enigma" version of the same
>> problem in 10 s:
>>
>> stip dia 4.0 forsyth XXXXXXXX/XXXXXXX1/8/8/8/8/XXXXXXXX/XXXXXXXX
>> ColorThePieces
>> cond circe
>>
>> It finds 122 solutions, and the desired solution is among them.
>>
>> The Tacu enigma solver is calculating costs differently, which explains
>> why it can be faster. I'll see if I can incorporate some of its logic into
>> the generic solver.
>>
>> Actually it's already possible to run both solvers at the same time, and
>> when I do that Jacobi solves the original problem in 49 s:
>>
>> stip dia 4.0 forsyth rsbqkbsr/ppppppp1/8/8/8/8/PPPPPPPP/RSBQKBSR
>> test dia forsyth XXXXXXXX/XXXXXXX1/8/8/8/8/XXXXXXXX/XXXXXXXX
>> ColorThePieces
>> cond circe
>>
>> So this is a workaround that you can use while you're waiting for a
>> version of Jacobi with this performance fix integrated.
>>
>>
>> CAILLAUD Michel wrote:
>>
>>> I am not specialist but I wonder if the use of hash tables can help
>>> (François mentioned hash keys, not the same thing??!). By experience I know
>>> hash tables have spectacular influence on the solving time of these kinds
>>> of position by Natch (orthodox). I don't know if Jacobi uses them (?!).
>>> They are used in Euclide (fixed), Natch, Popeye and Gustav (dimensionable
>>> by user).
>>>
>>
>> Hi Michel,
>>
>> You're right that hash tables give an enormous speed boost for some
>> problems. Jacobi v0.1 uses a hash table with a fixed size of ~128 MB. I
>> think I'll be able to make it configurable in v0.2. I wanted the default
>> value to be on the small side to avoid causing problems on low end devices
>> (Jacobi runs on smartphones!)
>>
>> Solving Marco's problem with "py -maxmem 128M" took 38 s instead of 33 s,
>> so it appears that for this particular problem the smaller hash table size
>> of Jacobi wasn't responsible for much difference.
>>
>>
>>     François
>>
>> _______________________________________________
>> Retros mailing list
>> Retros at janko.at
>> https://pairlist1.pair.net/mailman/listinfo/retros
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/retros/attachments/20171103/c6663bf0/attachment.html>


More information about the Retros mailing list