After WinBoard is loaded, I setup an endgame test position, with just five pieces.

When I chose MODE - TWO MACHINES, both machines instantly carry out their respective best moves. Upon checking that initial position that I set up, I confirm the endgame table bases are working. So far so good.

However, after setting up the position, if instead I chose MODE - ANALYSIS MODE, I briefly, for a quick second, see output in the analysis engine pane window. (I think that's what that window is called.) And then, that output disappears completely and doesn't return.

If I make a move on the board, the same thing happens - for a very brief quick second, barely enough time to read it, I see output appear in the window pane and then disappear.

What I'm hoping to see, of course, is a mate announcement of some kind. (That stays there, naturally.)

Upon checking the logfile that is produced, I can see that the # of moves to mate is listed in the file. This also confirms that polyglot/the engine are using the tablebases and that they are working as they should. But shouldn't that mate announcement be shown in the pane?

Can you post the section of the debug file that shows what the engine prints as analysis output for a single tablebase move? (Everything from feeding it the move that reaches the position up to the move that brings it to the next position.)

Ah, I do need to learn to remember to use debug more, before I ask questions. That's a great tool.

I see the message "didn't work, not enough space 512" in the debug file. That gives me a clue.

The endgame position is a real cool five-piece ending that is a mate for black in exactly 115 moves. (It's one of those tablebase positions where the winning side has to make a whole bunch of perfect moves to win. Any deviation and it's a draw.)

When two engines go head to head, no problem.But when in Analysis Mode, I'm now guessing the string is too long to fit into the pane, or probably into a string buffer set aside for that?

Note the engine's suggested move, that I saw flashed in the pane for a brief second, was Ne3, and that's not the correct move, which is Ne7. So it's not just a matter of not not seeing things in the pane... the engine didn't recognize the proper move, unless going head to head.

So clearly the engine sends two PVs, the second one only a single move long (Ne3), with a draw score. So presumably that is the best move of the 1-ply iteration, as the score of the long PV was rather low. After that the engine is polled for periodic updates,which also contain a depth=1 value. If Ne3 is not the best move, it is the engine that is in error for sending it.

Now I think part of your problem is that WinBoard will clear the engine-output display when it gets a PV of depth 1, because it thinks it starts a new search. It could be that the stat01 messages for the periodic updates also have this effect, which would then be the reason the Ne3 disappears. You can test that by switching periodic updates off. Then the Ne3 should at least hang there forever. You would still lose the Ne7 PV, but it was not the best move of the iteration anyway, so that is forgivable.

I think the main problem is that the engine is lying about its depth. It should not present a PV of more than 100 moves as 1 ply. It is clear that it is aware that it is lying, because otherwise, why wouldn't it continue with a 2-ply search? It knows that what it has is already worth more than 1 ply (or in fact valid to infinite depth), and this is why it stops deepening. So there is no excuse for claiming it is only a 1 ply result.

Correct. When I turn periodic updates off, 1...Ne3 appears in the pane and stays there. (Again, while in Analysis Mode.)

And then switching from "Analysis Mode" to "Two Machines" does, as mentioned before, begin the long sequence of both engine following their best moves, which leads to mate in 115 for Black, beginning with 1...Ne7, and not 1...Ne3.

Correct again - it does appear to be an engine specific problem. When I switch from Houdini to Critter, an engine which also uses the Gaviota tablebases, Analysis Mode works fine. The mate sequence appears immediately in the window, and stays there, with no other engine analysis.

Title: I suspect gaviota tablebases contain errors.----------------------------------------------------------I've had problems too, though I am new to this, so it may well be something I have done (or not done) myself that is causing my problems.

I once downloaded the chess engine gaviota-0.83-windows, and at some point in time decided that having some tablesbases would be a good idea too.I have written a chess engine - currently rubbish in performance - and wanted to know how to add tablebases. Gaviota seemed to have some softwaresource code for probing its tablebases, so I downloaded that.

On one of these forums someone asked about downloading tablesbases and there was a reply - generate your own. The reply was criticised: don't do that, it will take days. But I thought my computer was a reasonable speed and didn't want to download lots of files. One day I saw there was an option in Gaviota to generate the tablebases, so I let my computer run for a week and it gave me 5 men tablebases.

I then managed to get Houdini to consult my new tablebases and was happy when I tested it with Bishop and Knight versus nothing.I beat Houdini, putting up what should have been best resistance, and thought that all was well. Then for comparison I let Houdini loosein DEMO mode (on GUI Arena) to see what it would play for the winning side. I was surprised to find the game was DRAWN. Arrggghh!

Suspicion 1.I suspected there might be a problem with the way Houdini was accessing the tables bases.To rule that out, I loaded the Gaviota chess engine and let it run in Demo mode on the same starting position.(Demo mode means that chess engines play both the black and the white moves.) I had a single engine loaded so the same engine was playing both sides.Since [I assume] the tablesbases give some metric on positions rather than a move to play, there is a choice of "best" movesto be made by the chess engines and different engines are entitled to play different "optimatal" lines from a given position.I was initially startled when Gaviota using the same Gaviota tablesbases made different moves to Houdini, but a after a moments reflection it made sense. But then Gaviota went on to reach a draw playing against itself too.Gaviota's sraw was by repetition. Houdini's draw was due to insufficient material after allowing a piece to be captured.

You might think that I had just picked a drawn starting position, but remember that I myself beat Houdinifrom the same starting position with Houdini using the tablesbases for its defence.

So I think that narrows the problem to the tablesbases or the software that accesses them (if forexample Houdini uses some access routines taken from Gaviota rather than home-made routines based on a tablebase description).Is there a Gaviota tablebase format specification anywhere?Do competition chess engines need A. Their own tablebase format.B. Standard (=copied?) format but generated with own code.C. Standard format and copied is acceptable, but must be accessed by own code.D. Standard format and accessed by a standard interface is acceptable. My first experiments with tablebases are option D. But that smacks of plagiarism to me.

Unfortunately, it didn't seem to say what values it expected for the checksums and what the checksums are.If GTB_cp4_checksum was written before the tablebases were error free, it may well be verifying if the tablebasesare buggy rather than clean.

I believe there is a more lengthy tablebase verification procedure, but I haven't got round to that yet.I am debating whether to find more details, eg a FEN to post here, or whether to try to verify the tablebasesomehow, or maybe even just move on to opening books and come back to this when tablebases are smaller,more standard and more stable.

Conclusion------------My gut feeling is that there is a glitch in the Gaviota tablebases or their access routines caused by a minor programming error.Gaviota and Houdini seems to play out some difficult wins eg Two knights beating a pawn instantansously (showing the tablebases are installed and working), and counts down the distance to mate one step at a time against another tablebase engine,or monotonically decreasing against a thinking engine. So it seems the vast majority of the tablebase content and access software is giving correct results.

I am thinking of putting a video on youtube showing the problem.Since I am doing this first, I can't give you a link. But if I invent a hopefully unique string (B6012D52) for search engines to home in on, it should be easy to find.

I am still confused. (And still using the same chess engines and Gaviota tablebases.)

I expected I'd be able to find the problem FEN and post it here - the position where the chess engine switches from thinking that the game is won to deciding that it can only draw. I copied the starting position from my youtube video of 'Houdini using the tablebases to draw a theoretically won position' entitled "Gaviota tablebase problem B6012D52 Houdini".

Today it plays through the game and manages to win.I very much doubt that Houdini has learnt from its mistakes - if it did that it would have learnt from its mistakes yesterday.

So I have chess engines using tablebases and that are doing different things from one day to another

I'd say the best thing to do here is for me to ignore the whole sequence of events unless my chess engines have another bad-hair-day,and let's hope it doesn't happen to anyone else. Maybe it was a M$ windoze problem that went go away with an automatic update.

FEN=8/4K2k/8/4N3/8/1B6/8/8 w - - 0 1

If anyone wants to try their engines, this is FEN of the position (give or take a move number) that confused Houdini and Gaviota last night, but that behaves better now that my computer is sober.

I'll add a youtube video of Houdini managing to checkmate itself with the tablebases, where yesterday it could only manage a draw.

I guess you would have a better chance getting your question answered if you posted in in the general section of the forum. This section is mainly for reporting / solving bugs and discussing featurerequests for the WinBoard GUI (and itseems you are not even using that). So not everyone might read here.

I don't know anything about Gaviota tablebases specifically, but I think there are no drawn KBNK positions with white to move except those where the black King is forking (unprotected and unprotectable) B+N, or where it has N trapped in a corner, or where moving a hanging piece away leaves a stalemate. Anyway, only positions where it is obvious within two ply that the game has ended in a draw. So if an engine fails to win KBNK, there must be an error, either in the tablebase or in the probing code.

Today I just tried Houdini versus Gaviota, Gaviota versus Gaviota and Houdini versus Houdini.8/4K2k/8/4N3/8/1B6/8/8 w - - 0 1 I used the position which had resulted in drawn games in the past and all three resulted in Mate in 21via different paths. I played the winning side against Houdini myself and that was mate in 21 too. I started with Kf6like Gaviota (Houdini Kf7) but don't have the same confidence as Gaviota in letting the eneny king come away from theedge of the board.

The fact that the tablesbases are giving wins today andgave wins yesterday means that the problem I had when I first installed the tablebases was some sort of glitch, eg windows giving the same chunk of memory to two programs, or an uninitialised variable type of bugin the tablebase probing code.

The tablebases themselves must be fine for them to work correctly today.---------------------------------------------------------------------------------------

So as things stand, I don't think any action is really required by anyone, and its not an issue (more of an advantage maybe) if I'm posting on a rarely read thread.My concern that I was using dodgy tablebases has gone, and I can now adapt the probing code to my board layout and piece values etc.

I am likely to start messing about with the tablebases again soon - I want to shift them from the Gaviota engine directory where the engine created themto somewhere more logical, where Arena (a GUI) and other engines can access them. I'd like to back them up - 5 men Gaviota tablebases, and I think that in CP4 format they are just to big for a DVD - I need to check. If they are too big, they are only a little too big, and it will irritate me. Slightly better compression might solve that.

I wonder if there are options for the CP4 compression that can be tweaked to give me smaller files without the tablebase probing code needing to be changed.Comments on CP4 compression are welcome!

crystalclear wrote:The fact that the tablesbases are giving wins today andgave wins yesterday means that the problem I had when I first installed the tablebases was some sort of glitch, eg windows giving the same chunk of memory to two programs, or an uninitialised variable type of bugin the tablebase probing code.

That cannot really be concluded with certainty. There are often many path with the same length to mate, and it could be that only one of the paths is corrupted. So if the engine happens to pick the uncorrupted path one day, and the corrupted one the other day, it could find the mate sometimes, but other times getstuck in a loop.

Loops can occur when there exists a position in the tablebase that is listed with too low a DTM. This could divert the play from the correct path, because it promises a lower DTM than the correct move from the predecessor. But once arrived there, all legal moves would then lead to positions with larger DTM, and the best of those could be up-stream in the original path.

Today I just tried Houdini versus Gaviota, Gaviota versus Gaviota and Houdini versus Houdini.8/4K2k/8/4N3/8/1B6/8/8 w - - 0 1 I used the position which had resulted in drawn games in the past and all three resulted in Mate in 21via different paths. I played the winning side against Houdini myself and that was mate in 21 too. I started with Kf6like Gaviota (Houdini Kf7) but don't have the same confidence as Gaviota in letting the eneny king come away from theedge of the board.

The fact that the tablesbases are giving wins today andgave wins yesterday means that the problem I had when I first installed the tablebases was some sort of glitch, eg windows giving the same chunk of memory to two programs, or an uninitialised variable type of bugin the tablebase probing code.

The tablebases themselves must be fine for them to work correctly today.---------------------------------------------------------------------------------------

So as things stand, I don't think any action is really required by anyone, and its not an issue (more of an advantage maybe) if I'm posting on a rarely read thread.My concern that I was using dodgy tablebases has gone, and I can now adapt the probing code to my board layout and piece values etc.

I am likely to start messing about with the tablebases again soon - I want to shift them from the Gaviota engine directory where the engine created themto somewhere more logical, where Arena (a GUI) and other engines can access them. I'd like to back them up - 5 men Gaviota tablebases, and I think that in CP4 format they are just to big for a DVD - I need to check. If they are too big, they are only a little too big, and it will irritate me. Slightly better compression might solve that.

I wonder if there are options for the CP4 compression that can be tweaked to give me smaller files without the tablebase probing code needing to be changed.Comments on CP4 compression are welcome!

This is the position in your video that is not handled properly. Gaviota played Ne5 which is horrible. If you send the command 'bk' in the console (or the book options in winboard) you will see that the TBs are fine. If you type 'analyze', gaviota plays Kg5 announcing mate in 10.

If you want to compress the TBs for archival purposes, and you have all the uncompressed files in one folder, I think that compressing the whole thing with 7z will give you just above 4 GiB. Someone reported that some time ago. You cannot have such a good compression with the "compressed and ready to play" TBs because they need to be compressed in small chunks, hurting efficiency.