A new idea to index (and compress) bitbase EGTB

[Vinvin]

EGTB's bitbase currently use 3 values to store the value of a position : (win ; draw ; lose).

I propose the new idea to use only 2 values : (optimal result ; other results)

So, 1)when there's winning moves in the position, they will get the first value, other moves (drawing and losing will get the 2nd value).
And 2)when there's now win but drawing moves : all drawing moves will get 1st value and losing moves will get the 2nd value.

I hope it's a new idea, I didn't read about this before ...

My best,
Vincent

[PK]

How would You use it at non-root nodes, where You need a value, not just a move?

[Edmund]

There don't exist many bitbase formats so probably it hasn't been implemented yet, though I have read about similar thoughts.

you are right, it is common to have 2 bits per position (win;draw;lose;invalid)

But there are other ideas. Eg Draw-Tables (draw, !draw). Often this information will be enough, but on the other hand, the engine is still required to have certain endgame knowledge.

I once wrote a bitbase generator that only holds (win; !win) information. So this is quite similar to your idea, but always has win as a 'optimal result'. Obviously for certain endgames that is counterproductive.

My consideration was, that if one has such (win/not win) bitbases for both sides, he can determine the actual value of the position with a simple 1 ply search.
Eg.:
if (egtb_val=win) return win;
else if for any opp_move (egtb_val=win) return lose;
else return draw;

Another thing to keep in mind is that when a certain value is predominant in your egtb, it will compress very well anyway (eg. run length-compression)

You might want to have a look at this egtb forum for talks about different egtb formats.
http://kirill-kryukov.com/chess/discuss ... um.php?f=6

[Edmund]

How would You use it at non-root nodes, where You need a value, not just a move?

Hi Pawel!

only at root nodes you need a move. A value is just an approximation of the outcome. Knowing the actual outcome is always better. A won position would have a very large value, but not as large to conflict with mating values.

Bitbases are good during search, as they are some sort of internal node recognizer that can prune whole trees right after a capture to a certain endgame.

However the problem with Bitbases is that once the root-position enters such an endgame, it offers hardly any information and search is needed again.

[Zach Wegner]

The "winning moves in the position" has to be changed to "winning positions in the endgame". Both because you don't know what value the best move is (WLD), and because bitbases are position-based, not move-based. This is feasible if the bitbase probing function knows the possible outcomes for each side to move (e.g. in KPK white has W/D, black has D/L). I believe some have already done this, as Edmund said (win vs. not win). The compression will also reduce the usefulness of this idea...

[Vinvin]

Oops, you're right this system is impossible to implement

[Tony]

EGTB's bitbase currently use 3 values to store the value of a position : (win ; draw ; lose).

I propose the new idea to use only 2 values : (optimal result ; other results)

So, 1)when there's winning moves in the position, they will get the first value, other moves (drawing and losing will get the 2nd value).
And 2)when there's now win but drawing moves : all drawing moves will get 1st value and losing moves will get the 2nd value.

I hope it's a new idea, I didn't read about this before ...

My best,
Vincent

It has been mentioned a while back at the winboard forum. XiniX uses it, so does Shredder, and I think a few more.
You just need a function that ( depending on the piece combination) gives back an expected winner. If the pieces are the same you should return stm. Then you can use "expected winner wins", "expected winner does not win".

Tony