Progress on Rustic

[maksimKorzh]

PS: With regard to the search: I've now implemented a simple struct with one thread, which will can accept Start, Stop, and Quit from the engine's thread. The implementation has been simplified a lot.

The search thread just runs Iterative Deepening and Alpha/Beta as usual.

The difference with (for example) VICE is that I don't have to peek into the keyboard buffer to get incoming input. Because everything is threaded, the main engine thread can receive reports from any module (such as Comm or Search), and send output or commands accordingly.

This won't be multi-threaded of course, because iterative deepning and alpha/beta are both in the same Search thread for now, but I can split off things later, after the search is complete.

Now I just have to fill in the Id and A/B functions. (And Qsearch obviously.)

Great! And thanks for explaining the reason behind creating a website. Now it's perfectly clear. And also you're right about the way I'm using youtube serves about the same idea as having a website - just to stand out of other engines.

[mvanthoor]

Rustic now has a skeleton setup for iterative deepening and alpha/beta.

As far as I can see, I only need to "fill in" alpha/beta (and qsearch) now to actually make the thing play its first moves. I should then be able to play a full game in the console; and after I add UCI, the engine should be able to play through a GUI as well.

Code: Select all

================================================

8   r n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        819aa694337673fb
Active Color:       White
Castling:           KQkq
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > start		<= I type this in the console
Depth: 1
done.
Depth: 2
Depth: 1
done.
Depth: 3
Depth: 2
Depth: 1
done.
Depth: 4
Depth: 3
Depth: 2
stop				<= I type this in the console
stopping search

... no output ...
... engine idle ...

start				<= I type this in the console
Depth: 1
done.
Depth: 2
Depth: 1
done.
Depth: 3
Depth: 2
Depth: 1
done.
Depth: 4
Depth: 3
Depth: 2
Depth: 1
done.
Depth: 5
Depth: 4
quit				<= I type this in the console
quitting search

(engine quits here)

[BlueStar]

Wow! Just read this entire thread (after I just posted in the perft thread)--I've been heads down for a few weeks now and not on talkchess, now I know just how close we really are. I'm very happy to hear about the good outcome of your eye surgery! I'm struggling with health myself. I'm glad your as stubborn at making progress as I am.

Cheers man!
Keep up the great work.

CHoibakk

[mvanthoor]

Wow! Just read this entire thread (after I just posted in the perft thread)--I've been heads down for a few weeks now and not on talkchess, now I know just how close we really are. I'm very happy to hear about the good outcome of your eye surgery! I'm struggling with health myself. I'm glad your as stubborn at making progress as I am.

Cheers man!
Keep up the great work.

CHoibakk

Thanks for checking in

The cataract surgery went without issue and results are as planned. Next week I'll (finally) have the measurements for my new glasses done. (For seeing in the distance; for me, correction was done for close range, because I use computers most of the day, so I can do that without glasses now.) Fortunately, I don't have any health problems apart from my vision. I've had poor vision from birth, so I don't know anything different.

Is your engine's code in some repository somewhere? I'd love to have a look at it some time.
Rustic is here: https://github.com/mvanthoor/rustic

[Gabor Szots]

for me, correction was done for close range, because I use computers most of the day, so I can do that without glasses now.

That's funny. When I had a laser surgery to correct my eye-sight, I had it corrected for long range. I myself spend a lot of time in front of the computer but I hated to wipe my glasses when entering a place in the winter, or let the glasses slide down when sweating in the summer. I also hated not to recognize my acquaintances approaching me.
Now I must use two glasses, one for the computer and one for reading and I hate having th switch between them all the time...

[mvanthoor]

Progress is going well. Now implemented:

- Search can be started and stopped from the console (and thus, through all Comm interfaces)
- Make a move and take back from the console
- Help function in the console, displaying all comamnds
- Evaluation request from the console (to verify eval is working)
- Implemented the scoring table for MVV-LVA (functions yet to come)

Last two things to do:
- Write alpha/beta, qsearch, and move scoring functions
- Write the UCI Comm module

Also...

I've been watching CMK's (Maksim's) video's, and the test he showed with regard to nodes saved (= being beta-cut) because of MVV-LVA were impresive; the impact was _MUCH_ higher than I anticipated. (I went back to the Bluefever video's, and he had a similar test, also with huge impact.)

I've also written a Transposition Table somewhere around March or so and tested this in Perft, and the speedup was _HUGE_ (76% time saved on a perft run.) Therefore I've decided that MVV-LVA (needed for fast cut-offs) and the TT (needed for speed / avoiding re-analyzing positions) are part of the basics / essentials of a chess program, and thus have to be in Rustic 1.

Fortunately MVV-LVA is easy to implement (it's already half written), and the TT is already done (only needs to be made consistent with the current version of the code), so it won't take much extra time.

To be honest, I'm quite happy with how this engine is turning out after some back-and-forth and experimenting with how to organize the threads. The threading model with message passing between Comm <-> Engine and and Engine <-> Search works well, and it's very easy to add functionality. No flags or states; just add a report to the CommReport enum, add the transformation from the typed (or received) command to create_report(), and off it goes; when the engine receives it, it does its thing (make / take a move, do an evaluation, start/stop the search by notifying the Search module/control thread, and so on...), and it sends back the result in a CommControl. So... just add the result (if any, for a functionality) to the CommControl enum, and the handler in the thread receiving the CommControl message. Because taking back a move is a function of the engine (actually, the board, within the engine), implementing the Takeback command was actually less time than I needed to type this paragraph

Code: Select all

$ ./target/release/rustic.exe

d888888b                      dP   oo
88     88                     88
88oooo88  88    88  d8888b  d8888P dP d88888b
88    88  88    88  8ooooo    88   88 88
88     88 88    88       88   88   88 88
88     88  88888P  888888P    dP   dP 888888P
ooooooooooooooooooooooooooooooooooooooooooooo

Engine: Rustic Alpha 1
Author: Marcel Vanthoor
EMail: mail@marcelvanthoor.nl
Website: https://rustic-chess.org/
Threads: 1

================================================

8   r n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        819aa694337673fb
Active Color:       White
Castling:           KQkq
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > h
The console supports both long and short commands:

Long        Short     Description
=================================================================
a6a7q                 Moves in long algebraic notation.
help        h         This help information.
search      s         Start searching for the best move.
takeback    t         Take back the last move.
cancel      c         Cancel search and report the best move.
evaluate    e         Evaluate the position.
quit        q         Quit the console.
exit        x         Quit the console.

Rustic >

Now I must use two glasses, one for the computer and one for reading and I hate having th switch between them all the time...

Well... let's just say I'm going to have to need glasses for:
- Far sight (3m -> infinity)
- pinao playing (~arm's length)
- possibly for watching tv, if far sight glasses aren't good enough
- maybe for reading paper books (fonts often too small)
- And I might decide to try and sit a bit further away from the computer screen than what is possible without glasses...

So there will be at least 2, possibly 5... I hope it's not going to be that mutch.

[mvanthoor]

BTW: the reason why I put so much time into creating the console, is because it's my main testing platform for new functionality. I want to be able to test new functions man-to-engine; just me, and the program. No UCI commands, no user interface, no nothing that is in between the engine and the new function. And I don't want to test by having to test by putting different scenario's into main() to call the new function, recompile, and run; I want to test in in the running engine as well. Basically, I'm taking the place of the GUI; if a function works when I type the command, it WILL work through the UCI or XBoard interface as well... or the implementation of the UCI / XBoard stuff is incorrect.

[hgm]

But your console mode does not really differ from CECP in any essential way. It just uses different commands to activate the same functions as CECP also has commands for. You now have to type 'search', in CECP you could have typed 'go'. You have to type 'takeback', in CECP you would type 'undo'. You have to type 'cancel', in CECP you would have had to type '?'. So it still seems a waste of time.

In fact CECP is just the console mode of GNU Chess.

[mvanthoor]

Well, in that case it's very easy to convert Console Mode into CECP and be done with that part very quickly by copying the Console module and changing a few commands. If they really are that similar, I can always remove the separate console mode afterward.

Then it just comes down to me implementing CEPC / xBoard before UCI... which wasn't what I intended to, but that doesn't matter.

(I never looked at CECP, because when I got into PC / Computer chess, I did so through the Chessbase / Fritz GUI. They had their own engines, and later swtiched to UCI, so I never even used any xBoard / CECP engine up until now.)

[emadsen]

BTW: the reason why I put so much time into creating the console, is because it's my main testing platform for new functionality. I want to be able to test new functions man-to-engine; just me, and the program. No UCI commands, no user interface, no nothing that is in between the engine and the new function.

To each their own. But I think you'd be better served by dogfooding your UCI implementation when testing your engine. By that I mean test your engine by directly entering UCI commands in a terminal window. This mimics what a UCI-compliant GUI will do and eliminates the possibility of bugs introduced by differences between your custom console and UCI. Besides, nothing prevents you from supporting non-standard UCI commands. That's what I do in my engine.

Code: Select all

PS C:\Users\Erik\Documents\Chess\Engines\MadChess\3.0> .\MadChess.Engine.exe
uci
id name MadChess 3.0
id author Erik Madsen
option name UCI_EngineAbout type string default MadChess by Erik Madsen.  See https://www.madchess.net.
option name Debug type check default false
option name Log type check default false
option name Hash type spin default 128 min 0 max 1024
option name ClearHash type button
option name UCI_AnalyseMode type check default false
option name Analyze type check default false
option name MultiPV type spin default 1 min 1 max 128
option name PieceLocation type check default true
option name PassedPawns type check default true
option name Mobility type check default true
option name NPS type spin default 0 min 0 max 1000000
option name MoveError type spin default 0 min 0 max 1000
option name BlunderError type spin default 0 min 0 max 1000
option name BlunderPercent type spin default 0 min 0 max 100
option name UCI_LimitStrength type check default false
option name LimitStrength type check default false
option name UCI_Elo type spin default 400 min 400 max 2200
option name ELO type spin default 400 min 400 max 2200
uciok

isready
readyok

?
MadChess by Erik Madsen.  See https://www.madchess.net.

In addition to standard UCI commands, MadChess supports the following custom commands.

showboard                             Display current position.

findmagics                            Find magic multipliers not already hard-coded into engine.  Not useful without first
                                      removing hard-coded magic multipliers from source code, then recompiling.

countmoves [depth]                    Count legal moves at given depth.   Count only leaf nodes, not internal nodes.
                                      Known by chess programmers as perft.

dividemoves [depth]                   Count legal moves following each legal root move.  Count only leaf nodes.

listmoves                             List moves in order of priority.  Display history heuristics for each move.

shiftkillermoves [depth]              Shift killer moves deeper by given depth.
                                      Useful after go command followed by a position command that includes moves.
                                      Without shifting killer moves, the listmoves command will display incorrect killer values.

showevalparams                        Display evaluation parameters used to calculate static score for a position.

staticscore                           Display evaluation details of current position.

exchangescore [move]                  Display static score if pieces are traded on the destination square of the given move.
                                      Move must be specified in long algebraic notation.

testpositions [filename]              Calculate legal moves for positions in given file and compare to expected results.
                                      Each line of file must be formatted as [FEN]|[Depth]|[Legal Move Count].

analyzepositions [filename] [msec]    Search for best move for positions in given file and compare to expected results.
                                      File must be in EPD format.  Search of each move is limited to given time in milliseconds.

analyzeexchangepositions [filename]   Determine material score after exchanging pieces on destination square of given move.
                                      Pawn = 100, Knight and Bishop = 300, Rook = 500, Queen = 900.

tune [pgn] [ps] [pps] [wps] [i]       Tune evaluation parameters using a particle swarm algorithm.
                                      pgn = PGN filename, ps = Particle Swarms, pps = Particles Per Swarm.
                                      wps = Win Percent Scale, i = Iterations.

tunewinpercentscale [pgn]             Compute a scaling constant used in the sigmoid function of the tuning algorithm.
                                      The sigmoid function maps evaluation score to expected winning percentage.