First fail high drops in endgame

[Tony]

Hi all,

I think I broke something in my engine, but I'm not sure what. Maybe someone has a clue.

When I go towards the endgame, the percentage first fail high drops to below 80% ( normally above 90%)

I'm not sure how to test/ where to look. I switched off bitbases (thought they were corrupt), switched off lazy eval. No improvement.

anybody had this before ?

Cheers,

Tony

[hgm]

Did you ever measure this quantity before (with different result)? It seems normal to me that it is more difficult to find cut-moves in an end-game, as the information that distinguishes the winning from the losing moves is much more distant. In the middle game it is often decided by what is on the to-square, but in end-games it is what is on the square you are heading to in a number of moves.

[Tony]

Did you ever measure this quantity before (with different result)? It seems normal to me that it is more difficult to find cut-moves in an end-game, as the information that distinguishes the winning from the losing moves is much more distant. In the middle game it is often decided by what is on the to-square, but in end-games it is what is on the square you are heading to in a number of moves.

Yes,
otoh, in the endgame, you accidently choose the right (good enough) move more often.

But in fine 70 , 78% is way too low. that should be 98% or something. (No nullmove, no lmr)
I've never seen it that low. It almost looks like a random choice. I'm overlooking something obvious, but I haven't got a clue.

Tony

[Gerd Isenberg]

Hi all,

I think I broke something in my engine, but I'm not sure what. Maybe someone has a clue.

When I go towards the endgame, the percentage first fail high drops to below 80% ( normally above 90%)

I'm not sure how to test/ where to look. I switched off bitbases (thought they were corrupt), switched off lazy eval. No improvement.

anybody had this before ?

Cheers,

Tony

You may count fail high % for depth left > N, > 0, <= 0 to eventually get a better picture of what happens. If you cut late, log the moves tried before.

Gerd

[Tony]

Hi all,

I think I broke something in my engine, but I'm not sure what. Maybe someone has a clue.

When I go towards the endgame, the percentage first fail high drops to below 80% ( normally above 90%)

I'm not sure how to test/ where to look. I switched off bitbases (thought they were corrupt), switched off lazy eval. No improvement.

anybody had this before ?

Cheers,

Tony

You may count fail high % for depth left > N, > 0, <= 0 to eventually get a better picture of what happens. If you cut late, log the moves tried before.

Gerd

Hi Gerd,

problem is that the first 8 plies still give a decent percentage. So logging kind of blows up. I don't seem to be able to find a specific position that goes wrong immediatly.

I'll try with splitting the counters, that might give some more information.

Thanks,

Tony

[Gerd Isenberg]

The professional approach would be to get your older sources from CVS or similar repositories to find the changes that cause the damage

Good luck,
Gerd

[Tony]

The professional approach would be to get your older sources from CVS or similar repositories to find the changes that cause the damage

Good luck,
Gerd

Unfortunately, that would be about my complete source code

I made quite a few really big changes.

Tony

[Chan Rasjid]

Hello,

I think I broke something in my engine, but I'm not sure what. Maybe someone has a clue.

When I go towards the endgame, the percentage first fail high drops to below 80% ( normally above 90%)

For me, the cause of most bugs seems to be traceable to a "direct" source. In your case it may be hashing a wrong move, failure to order / retrieve the proper moves front. Is there any related endgame specific routines? Is your printf % corrupted?

Best Regards,
Rasjid

[Jose Carlos]

Did you ever measure this quantity before (with different result)? It seems normal to me that it is more difficult to find cut-moves in an end-game, as the information that distinguishes the winning from the losing moves is much more distant. In the middle game it is often decided by what is on the to-square, but in end-games it is what is on the square you are heading to in a number of moves.

Yes,
otoh, in the endgame, you accidently choose the right (good enough) move more often.

But in fine 70 , 78% is way too low. that should be 98% or something. (No nullmove, no lmr)
I've never seen it that low. It almost looks like a random choice. I'm overlooking something obvious, but I haven't got a clue.

Tony

I think that's normal behaviour due to hashing. If you prune much more due to hashing (like in Fine 70), you have less good-and-easy moves to search that would otherwise rise the FH at fist move rate.

[Tony]

I seem to have found it.

I have created a function that converts the hashtable score to a search score (basicly adjusting for checkmates)

Unfortunately, I didn't send in the found hashtablescore, but a value initialised to +/- inf (depending on upper or lower bound), meaning it would get a hashtable cutoff with a checkmate score, any time the depth was sufficient (but never when in PV).

That will wreck your search. The only thing I don't understand is that it was able to play something resembling chess at all.

Thanks all,

Tony