I guess it is a parsing bug I need to fix.
It's been a while, do the FRC rules say that all castling moves must be specified as either O-O or O-O-O? (then it would be a simple fix)
If not, how could Bright differentiate between the castling move and the plain king move?
My engine wanted to send a castle to Bright, but mistakenly format b1a1 as b1c1
So I too still have something to fix
This bug lets BigLion play legal but weak unintended moves.
Castle is always "King captures own Rook", here b1a1 .
Don't go the O-O-O way because of other problems there !!
When running all my test suites I got BIG surprise. bright 0.4a was better than Rybka 3 in 4 different suites! These were 3 tactical and 1 endgame suite.
Jouni wrote:When running all my test suites I got BIG surprise. bright 0.4a was better than Rybka 3 in 4 different suites! These were 3 tactical and 1 endgame suite.
Jouni
That's nice to hear.
Which suites were these btw?
If you ran more suites and bright 0.4a scored badly on them, i'd be interested to know too, as these could be indicative of area's to improve on.
You need to
1) use O-O and O-O-O format for pgn output.
2) for all other purposes, use "King captures own castling Rook", for example e1a1.
Best,
Matthias.
The way it is implemented is that O-notation is used for output and that
both O-notation and rook capturing as wll as Kc1/Kg1 are accepted as
input. The latter had the bug, 0.4a2 now requires that the king should
move at least two squares in order to indicate a castling move.
I prefer to keep Kc1/Ke1 in, as it would allow the frc version to play normal chess as well.
Could you or someone supply a specific position that reveals a bug?
Allard Siemelink wrote: 0.4a2 now requires that the king should
move at least two squares in order to indicate a castling move.
Usually FRC bugs hide in the cases where king does not move during castling or moves only one square to castle.
To support both normal chess and FRC, I think an
"if (FRC) ... else ..." when formating moves for GUI is unavoidable.
Best,
Matthias.
correct, that should have read: "0.4a2 now requires that the king should
move at least two squares in order to indicate a castling move with the Kc1/Kg1 method".
I'll have another look at these type of positions.
I agree that for output, O-O should be avoided when talking UCI.
I ran bright in some public (slightly modified may be) and private suites.
In all positional suites Rybka was as expected much better. BTW Allard have You written bright from zero? That must be some 1000 hours of work!
