TESLACOIL wrote:Sometimes it is unable to checkmate the lone white king when it has a queen and rook

Roland Chastain wrote: Yes, that problem is well known by chess programmers, and isn't so easy to solve. I have heard of endgame tablebases, but I haven't found time to study it.

Actually, it shouldn't be too difficult and doesn't need tablebases - R or Q v K is possible to find via search and specifically adapted endgame piece square tables (PST). For example, for Numpty if it recognises R or Q v K it deploys the following PST for the King in the evaluation function:

Unlike the normal PST for King in the endgame, the values are designed to force the King towards the edge of the Board (ie bonus is higher if opponent king is on one of the outer squares) from here even quite a shallow search should find the mate.

Its sad but true, that chess, in the final analysis is mostly about brute force. The complexities of a position cannot be tackled via a book of ' good rules and known principles' because there are a near infinite amount of exceptions to that 'best practice'.

Most high level games are won or lost when a player spots a position in which 'best practice' does not lead to 'best outcomes'

A powerful computer chess engine will often play a series of arcane moves which defy casual description. The wisdom of such moves only becomes apparent to human observers AFTER they have deeply examined the landscape...beyond a certain level of strength it gets hard for humans to judge if the computer has A) played a profoundly strong move or B) a profoundly screwy move due to the horizon effect or some weird nuance in evaluation.

Very strong computer chess programs play in a different way from human players. This means it can be quite difficult for a human coder to envisage the best way forward. Letting your chess engine play against many others and collecting statistics about freedoms of movement, swings in evaluation etc is one way forward.

The best way to improve your engine

Get the engine to spit out a list of legal moves and have a second program read that list and brute force as deep as it can given CPU and time constraints. Every ply you can brute force massively increases it playing strength even if the 'evaluation' is basic.

At a guess id would say that 80% of computing power should be set aside for brute force and 10% for basic evaluation.

The last 10% can be used for deeper evaluation, ie has the pendulum swung a large amount in the preceding couple of moves. If so then allow the brute force engine extra time.

Thus time management + simple brute force will be the next big leap.

Eg if a pawn is queened then double or quadruple the time allowed for that particular move.

Games are often one or lost on a handful of critical moves, a tiny blunder can have exponential consequences so it totally correct to apply exponential resources at key moments....the opening book saves you many seconds and minutes, you can invest that saved time in 'key' moments.

Just letting the computer stop at random every dozen moves and chew the cud for a minute or so will help your engine get out of a pickle or spot a win.

There are many ways to improve a basic engine, but brute force, while a boring approach will REALLY pack a punch and, far more importantly give a TRULY SOLID FOUNDATION to any 'fancy evaluation methods' you might wish to indulge in.

This is one of the strongest engines on the planet running on one of the more powerful desktop computers

Houdini had 3mins 11sec left on the clock, i was manually entering moves on both engines (two boards)

evaluation was level until Whites pawn to B4 changed the evaluation to 0.8 pawns in blacks favor. Whites queen was chased around while black went on a knight rampage. Houdini then crept forwards evaluation wise for a few moves and then started slinging piece exchanges in whites face. For a few moves it seemed as if the evaluation was slightly swinging back in Eschecs favor but this was Houdini merely 'tidying up'

The White bishop taking the pawn on D4 was an instant blunder that allowed Houdini to spot a forced checkmate in 22 moves, moments later Houdini saw a forced mate in 16, and in fact checkmated Eschecs within 6 moves rather than the 22 first indicated.

Eschecs took hardly anytime at all deciding its moves, letting the engine chew the cud for 3 to 10 seconds per move in a Blitz game is perfectly acceptable. Increasing the brute force ply by 2,3 or 4 should be possible without leaving human players twiddling thier thumbs waiting.

While the outcome was a forgone conclusion i felt that Eschecs had become worthy of a true test against hardware and software which is a 'default standard' in the chess computing world. It was going up against a 10kilanode a second machine that is quite capable of beating the reigning human world champion.

Houdini does a great deal of basic brute force as a foundation but has also been highly tuned to seek deeper convoluted advantages should they appear on the search horizon. It is seldom conservative against weaker opponents and writhing worms are bait to the beast !...its named after the Famous Escape artiste but when the tide is in its favor it will tie its opponents limbs in knots long before they hit the floor !

I haven't yet integrated animated pieces (see my previous message), but I made a lot of modifications, visible or invisible. I believe I have found why the engine froze when I increased the search depth: it seems it was an issue of memory. So I modified the data types, to avoid memory waste, and now the engine seems to work correctly with a higher search depth. But it still would need confirmation.

With your chessSet.bas program my thoughts were it allows clicking the same square twice and clicking outside the board area with funny results. I assume correct inputs are checked and generated by the chess engine so it isn't an issue? As your coding techniques are a little bit advanced for me I can't follow it to suggest any code improvements. When I read animated I at first thought your pieces actually walked and swung weapons :)

Your chess program seems to get better and better? It would be nice however to save and load games and have undo and redo move buttons.

Another nice feature would be for pieces taken being placed on the side of the board.

I wrote some code to generate your chess set pieces so it could be used on forums such as this where there is no means to store images with the text.

dim as string datumfor k as integer = 0 to 11 for j as integer = 0 to 39 read datum for i as integer = 0 to 39 pset pieces(k),(i,j),rgb(244,244,0) if mid(datum,i+1,1)="." then pset pieces(k),(i,j),rgb(255,0,255) end if if mid(datum,i+1,1)="#" then pset pieces(k),(i,j),rgb(0,0,0) end if if mid(datum,i+1,1)=" " then pset pieces(k),(i,j),rgb(255,255,255) end if next i next jnext k

flipFlag = 1for j as integer = 0 to 7 flipFlag = -flipFlag for i as integer = 0 to 7 flipFlag = -flipFlag if flipFlag = 1 then line chessBoard,(i*40+40,j*40+40)-(i*40+79,j*40+79),rgb(255,255,255),bf end if next inext j

BasicCoder2 wrote:With your chessSet.bas program my thoughts were it allows clicking the same square twice and clicking outside the board area with funny results. I assume correct inputs are checked and generated by the chess engine so it isn't an issue?

Yes, it will be the responsibility of the calling program to call the functions with correct values. The program you tried is just like wood pieces. But I should have checked the click outside the board area! I will make the correction.

' Converts the first field of an FEN string to an HTML document.' The default font is Chess Alfonso-X by Armando H. Marroquin.' If you want to use another chess font by the same author, you just have to' change the font name, otherwise you must also change the character set,' because each author uses a different one.' The FEN string is assumed to be valid!

Chess programmers often set up their program to compete in automated tournaments vs other chess programs as a way to find bugs and generally improve the performance.

It is a bit of a hassle getting the protocols right the upside once done there are dozens if not hundreds of compatible chess engines to test yours against.

Even the best chess programs still need about 20mins per game in order to play fairly tight chess. Some positions are arcane and there is no general set of chess guidelines that apply to these positions because of the unique complexity embedded in that unique position. Here brute force is required to look far ahead in order to try and find a more obvious (good/bad) decidable path. The programmer then has the option to play safe, and via internal code biases, encourage their chess engine to play towards a position which is 'more easily decidable' using broader chess principles.

Brute force is so revealing, especially in weird positions, that it is the default method for improvement. The faster the machine the more true this becomes. Humans being a bit slow and unable to compute deeply or accurately are forced to play chess using general principles. The fact that a 'dumb but fast' brute force chess engine can beat most humans most of the time is a testament to this over arching theme.

Even Grandmasters with computers can get it wrong :-p Classic example of where Principle says yes but Brute force says no

Lecture with GM-Elect Irina Krush https://www.youtube.com/watch?v=tGqaixsLGt8At 8 minutes she correctly highlights a good principle, knight to F5 blows blacks pawn structure after the white bishops exchanges with the black knight on F5. However due to the uniqueness of the position it is actually a draw !!! even though white's king looks as though it can swing left then right again to sweep up victory.

So the GM had obviously found what she thought was a good example to demonstrate for her lecture, her deep instinct AND the initial computer evaluation both said win/big advantage for white but in reality its a draw. Both were wrong. It took almost an hour for me to figure this out. (with the aid of a computer)

The take away point here is that tweaking a chess engines code is fruitless without extensive brute force testing, 100+ games. Thus the value of automatic tournaments and some detailed method of logging 'how & why' your engine lost or won is also critical to advancement.

The ability to play chess at a certain level, the ability to code at a certain level and perhaps more importantly than this ' a deep experience' with chess engines. For this reason 'chess anything' will remain a non trivial problem for us humans even with uber fast computers to aid us.

From now on, the engine and the GUI can be developed separately. The engine can even be used separately, by anyone who would want to use it. So I believe it deserves an independant release.

To use it, you just have to load the library and call the EngineMove function, with a FEN record as first parameter, and the name of the log file if you want a log file. It returns a string like "e2e4".

Here is Eschecs 0.9.0. Not really new features, but important modifications. The engine is now a DLL. The pieces glide over the board. The promotion dialog which was ugly (I had made it myself) has been replaced by radiobuttons.