List of bugfree, opensource Linux and MacOSX engines

[OliverBr]

I have just pushed a new patch for Fairy-Max to my on-line repository. This should rigorously prevent any time losses, as it now will abort the search whenever it runs out of time. I set this 'cold-turkey timeout' at 3 times the nominal move time, which is now calculated as timeLeft/(movesLeft+2). The +2 in the denominator makes sure the factor 3 overrun will not cause flagging even when movesLeft = 1. And after the calculation I subtract 32 msec to allow for 2 clock ticks (which happen every 16ms on most systems). I tested it by artificially setting a very short cold-turkey timeout in a long TC game, so that every move gets aborted, and this worked fine. It just plays the last bestMove it found, (which could be from the aborted iteration, or the preceding one), after the abort.

If it forfeits now it can only be due to a genuine crash. But I would be very surprised if Fairy-Max could suffer from those. It seems way too smal to hide any bugs.

It looks good now. 2000 games without any issue, no timeout, no stalling etc.

[Roland Chastain]

I have just pushed a new patch for Fairy-Max to my on-line repository. This should rigorously prevent any time losses, as it now will abort the search whenever it runs out of time. I set this 'cold-turkey timeout' at 3 times the nominal move time, which is now calculated as timeLeft/(movesLeft+2). The +2 in the denominator makes sure the factor 3 overrun will not cause flagging even when movesLeft = 1. And after the calculation I subtract 32 msec to allow for 2 clock ticks (which happen every 16ms on most systems). I tested it by artificially setting a very short cold-turkey timeout in a long TC game, so that every move gets aborted, and this worked fine. It just plays the last bestMove it found, (which could be from the aborted iteration, or the preceding one), after the abort.

If it forfeits now it can only be due to a genuine crash. But I would be very surprised if Fairy-Max could suffer from those. It seems way too smal to hide any bugs.

Thank you for the new version of Fairy-Max. I could compile and test it successfully on Linux and on Windows.

I don't want to bore you but, unless I did something wrong, there is still a little issue (for CuteChess users) with the missing promotion suffix. If ever you had time to fix it...

Code: Select all

Finished game 9 (Hippocampe vs Fairy-Max 5.0): 1-0 {Black makes an illegal move: b2b1}

Maybe Oliver didn't see it because he opposed (I guess) Fairy-Max to stronger engines, where Fairy-Max hadn't occasions to promote.

[Roland Chastain]

Hello! I fixed the name issue for Hippocampe, and the issue of the missing promotion suffix. IIRC there is also a problem of illegal castling move (I am not sure, but I believe that the program doesn't check that the castling is not under attack): I will try to fix it later.

Hi! The addition with the name is great and works.
Still there is the castling issue..:

Thank you for your test. I believe I fixed the castling issue. In fact the rule was already implemented: there was just one line missing in the code. I didn't have time to do a methodical test, but I think it should work now.

hippocampe.zip

The new package includes an alternative Makefile for 32-bit compilation, and logos for Hippocampe by Norbert Raimund Leisner.

[hgm]

I don't want to bore you but, unless I did something wrong, there is still a little issue (for CuteChess users) with the missing promotion suffix. If ever you had time to fix it...

Code: Select all

Finished game 9 (Hippocampe vs Fairy-Max 5.0): 1-0 {Black makes an illegal move: b2b1}

Maybe Oliver didn't see it because he opposed (I guess) Fairy-Max to stronger engines, where Fairy-Max hadn't occasions to promote.

Do you have the entire game? I could not reproduce this in a KPK position. Fairy-Max should print promotion suffixes; when it 'confirms' a move at game level (i.e. refrains from its UnMake in the root), it checks if the piece at the to-square is different from the piece it was moving, and if so, it possibly corrects that piece to conform to a promotion choice given as input (and leaves it at Queen if it was his own move), and remembers the resulting piece code (which for non-promotions would be left at 0).

Code: Select all

          // here prom = 0, and PromPiece a possible correction to the default promotion choice Q
          if(board[toSqr]-piece & 15) prom = board[toSqr] -= PromPiece,   /* (under-)promotion:       */

After return from the root the move-printing code then does

Code: Select all

			    if(prom) printf("%c", piecename[prom]+'a'-1);

I don't see how this could ever omit the promotion suffix. Even if the piecename[] table is not properly initialized (which depends on the variant definition in the fmax.ini file) it should print something.

[Roland Chastain]

I don't see how this could ever omit the promotion suffix. Even if the piecename[] table is not properly initialized (which depends on the variant definition in the fmax.ini file) it should print something.

Thank you for your detailed answer. No, I didn't keep the game. I will make other tests, and will post here the game if this happens again.

[Roland Chastain]

Do you have the entire game?

Here is another game (PGN attached).

Maybe I did something wrong when compiling Fairy-Max? I copied fmax.ini in the directory of the executable. I didn't install Fairy-Max. (I prefer to keep all the programs that I compiled myself in my own directories.)

[OliverBr]

Maybe Oliver didn't see it because he opposed (I guess) Fairy-Max to stronger engines, where Fairy-Max hadn't occasions to promote.

I let Fairy-Max play 2000 games against OliThink 4.1.3 and it won quite a number of games and for sure, promoted.

[hgm]

I loaded that game, and set Fairy-Max thinking, which produced the following output:

Code: Select all

19104 >first : time 6000
19104 >first : otim 6000
19104 >first : black
19104 >first : go
19114 <first : # times @ 10422301
19114 <first : # 11+14 pieces, centr = (1,1) R=23
19114 <first :  1   2014        0          3 g2h1
19121 <first :  2   2113        0        108 g2h1 e1f2 h1h2
19122 <first :  3   2113        0        358 g2h1 e1f2 h1h2
19123 <first :  4   2322        0       1802 g2h1 e1f1 h1g2 f1e1
19130 <first :  5   2631        3      13286 g2h1 e1f1 h1g2 f1e1 g2g1 e1e2 g1c1
19152 <first :  6   2857        4      32548 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4a1
19177 <first :  7 100005        7      65841 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
19200 <first :  8 100005        9      97065 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
19288 <first :  9 100005       18     207249 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
19408 <first : 10 100005       31     410064 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
19599 <first : 11 100005       50     752847 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
20124 <first : 12 100005      103    1563927 g2h1 d2d3 h1g1 e1d2 c7h2 d2c3 g1d4 c3b3 d4b4
20606 <first : # times @ 10423799: real=1498 cpu=1502
20606 <first : # promo = 7 (q) GT = 0
20606 <first : move g2h1q

So the promotion suffix is there, as required.

Are you doing this on Windows or Linux? Only the Windows compile should expect the fmax.ini in the current directory; in Linux it expects it in /usr/local/share/games/fairymax/ . So perhaps it is using a different fmax.ini, with incompatible piece naming. It is difficult to guess what is going on without having a log that shows what the engine printed.

[Edit] This depends on how you compile: the Makefile will define the path to fmax.ini. If the fairymax.c file finds the macro FAIRYDIR undefined, it #defines it as ".".

[OliverBr]

Thank you for your test. I believe I fixed the castling issue. In fact the rule was already implemented: there was just one line missing in the code. I didn't have time to do a methodical test, but I think it should work now.

hippocampe.zip

The new package includes an alternative Makefile for 32-bit compilation, and logos for Hippocampe by Norbert Raimund Leisner.

Congratulations, it looks as you actually have fixed the castling issue. The linux executable you provide in your link is running now against OliPow 2.2.3 and there are no issues until now.

But I some suggestions for further improvement:

1) it would be nice to have a fix link to hippocampe's sources. Google drive is not the best option. Much better would be github or gitlab.
2) I see that your version number didn't change. It's obvious to change e.g. from 0.4.2.0.1 to 0.4.2.0.2, if there is a new version that plays differently.

Code: Select all

Started game 39 of 2000 (Hippocampe 0.4.2.0.1 vs OliPow 2.2.3)

3) Sometimes, I am having problems interrupting cutechess-cli when hippocampe is playing. It looks as it may having problems being interrupted (with "quit" or SIGNAL). It is quite important that engines interrupt their search when die GUI/manager wants them, too.

EDIT: Looks as 3) is happening quite often and when it's happening, it's really annoying because then you have to kill all processes manually.
You may want to have a look into it.

PS: Hippocampe's playing strength is really something. It is really the first and only stable engine in this "sector".

[OliverBr]

So the promotion suffix is there, as required.

It's there on my systems, too. Of course!

Some different fmax.ini may be an explanation somewhere else if this suffix is missing.