NEW Computer Chess Idea! middlegame books

[mainsworthy2]

Hello

I hope I explane this well , here goes.

Engines come with external files(books & tablebases) that make moves accross the board without the engine's help. My idea is If external forces govern oppenings & endgames, can an external file hold positions many ply deep that could arrise from a large book or Endgame file but instead holds JUST positions! way into a game not connected with oppening books or endgame files. It would be a middlegame book, you would never get all the positions in it but as new info comes up against say another engine you can fill it with a killer resonce NOT derived from a oppening book.

so what Im saying is; middlegame file filled with problem positions and responses, it would push chess engines to develop random play, and I think it would be a good thing.

Anyway what do you think?

Mark Ainsworth

[Dann Corbit]

Hello

I hope I explane this well , here goes.

Engines come with external files(books & tablebases) that make moves accross the board without the engine's help. My idea is If external forces govern oppenings & endgames, can an external file hold positions many ply deep that could arrise from a large book or Endgame file but instead holds JUST positions! way into a game not connected with oppening books or endgame files. It would be a middlegame book, you would never get all the positions in it but as new info comes up against say another engine you can fill it with a killer resonce NOT derived from a oppening book.

so what Im saying is; middlegame file filled with problem positions and responses, it would push chess engines to develop random play, and I think it would be a good thing.

Anyway what do you think?

Mark Ainsworth

Sounds like a form of position learning to me.

[mainsworthy2]

Well thought Id say it. but Im not uptodate with position learning, you know better than me

[rjgibert]

If I understand you correctly, you are storing specific positions of the middlegame and associating specific responses with each. The trouble with this is the hit rate would be minuscule and not worth the effort. It would have to be closely tied to the opening book to get a decent hit rate, but then you might as well make it part of the opening book. I once approximately calculated the hit rate for such a database consisting of 8-man endgame positions to be less than something like 1%.

An idea I am interested in is to store "types of positions" instead. For example, you would look up in a database using a signature based on pawn structure and material balance. In the database would be stored eval scores for the combination of pawn structure and material. In addition, eval parameters to score other aspects of the given type of position would be stored. These would be based on statistical information mined from a database of games.

[bob]

If I understand you correctly, you are storing specific positions of the middlegame and associating specific responses with each. The trouble with this is the hit rate would be minuscule and not worth the effort. It would have to be closely tied to the opening book to get a decent hit rate, but then you might as well make it part of the opening book. I once approximately calculated the hit rate for such a database consisting of 8-man endgame positions to be less than something like 1%.

An idea I am interested in is to store "types of positions" instead. For example, you would look up in a database using a signature based on pawn structure and material balance. In the database would be stored eval scores for the combination of pawn structure and material. In addition, eval parameters to score other aspects of the given type of position would be stored. These would be based on statistical information mined from a database of games.

If you could figure out how to do that it would be a world-class idea. Right now everyone uses "exact match" which means that the typical position-learning idea is all but useless. But if this were extended so that a "fuzzy match" could occur, and the "fuzziness" was such that it encapsulates the key features while excluding the unrelated stuff, then this could/would be an extremely powerful idea.

But doing so has eluded those that have tried for many years now..

[mainsworthy2]

the hit rate would be minuscule for different engines vs different Engines, but would be high if the middlegamebook would be specific to each engine vs all other engines I think

fuzzy idea is great

[Matthias Gemuh]

the hit rate would be minuscule for different engines vs different Engines, but would be high if the middlegamebook would be specific to each engine vs all other engines I think

The hit rate is approximately zero in both cases.
Hash tables in middle game search are astronomically more fruitful.

Matthias.

[mainsworthy2]

the hit rate would be minuscule for different engines vs different Engines, but would be high if the middlegamebook would be specific to each engine vs all other engines I think

The hit rate is approximately zero in both cases.
Hash tables in middle game search are astronomically more fruitful.

Matthias.

Sorry Matt, What I was trying to say was you have a single engine, and when its beaten by another engine, you the book builder would analyse and add the position in Question to the book with a response and hope the game goes better next time after the position is passed, so the hit rate would be 100% untill the other engine plays differently. and engines would maybe have to adapt to a more random move eval() giveing more exciteing engine matches.

the theoetricle battle of mid game positions going on infintely just like oppening books

I think the position learning may be something like this I dont know but I will look into it

[Matthias Gemuh]

the hit rate would be minuscule for different engines vs different Engines, but would be high if the middlegamebook would be specific to each engine vs all other engines I think

The hit rate is approximately zero in both cases.
Hash tables in middle game search are astronomically more fruitful.

Matthias.

Sorry Matt, What I was trying to say was you have a single engine, and when its beaten by another engine, you the book builder would analyse and add the position in Question to the book with a response and hope the game goes better next time after the position is passed, so the hit rate would be 100% untill the other engine plays differently. and engines would maybe have to adapt to a more random move eval() giveing more exciteing engine matches.

the theoetricle battle of mid game positions going on infintely just like oppening books

I think the position learning may be something like this I dont know but I will look into it

Midgame is so broad that you have to expect a hit rate of near zero.
Even if you merely extend an opening book into midgame, that does not help. During a game, you will regularly be thrown out of book before mid-midgame. If your midgame book is 100 terabytes thick, it may help a little bit.

Matthias.

[bob]

the hit rate would be minuscule for different engines vs different Engines, but would be high if the middlegamebook would be specific to each engine vs all other engines I think

fuzzy idea is great

Hit rate would be low. Extremely low. So close to zero as to be called zero, unless a good fuzzy matching scheme can be developed. A 10 ply search diverges into 38^10 different endpoints, making exact matches across games practically nonexistant. If you want to develop a _very_ small book, then you might get some hits right out of book, but after 10 moves the game has diverged impossibly...