Will you use hash saving?

cdani · Post by **cdani** » Sun Jul 30, 2017 7:39 am

I'm curious if this will be used.

Arpad Rusz · Post by **Arpad Rusz** » Sun Jul 30, 2017 2:38 pm

What about saving the hash (or part of it) to a pgn-file? Then we could use some mining tools (like CQL http://gadycosteff.com/cql/doc/introduction.html) to find interesting positions or lines.

D Sceviour · Post by **D Sceviour** » Sun Jul 30, 2017 6:03 pm

cdani wrote:I'm curious if this will be used.

What is hash saving? Is this another name for persistent hash?
http://chessprogramming.wikispaces.com/ ... Hash+Table

cdani · Post by **cdani** » Sun Jul 30, 2017 6:11 pm

D Sceviour wrote:
cdani wrote:I'm curious if this will be used.
What is hash saving? Is this another name for persistent hash?
http://chessprogramming.wikispaces.com/ ... Hash+Table

No, is just to save the whole main hash to disk:
http://talkchess.com/forum/viewtopic.php?t=64720

So saving the transposition table, if you prefer:
https://chessprogramming.wikispaces.com ... tion+Table

cdani · Post by **cdani** » Sun Jul 30, 2017 6:15 pm

Arpad Rusz wrote:What about saving the hash (or part of it) to a pgn-file? Then we could use some mining tools (like CQL http://gadycosteff.com/cql/doc/introduction.html) to find interesting positions or lines.

A hash table can contain several millions of entries. So a pgn file seems not to be a good container for it. Also there are a lot of other drawbacks.

https://chessprogramming.wikispaces.com ... tion+Table

Arpad Rusz · Post by **Arpad Rusz** » Sun Jul 30, 2017 10:26 pm

cdani wrote:
A hash table can contain several millions of entries. So a pgn file seems not to be a good container for it. Also there are a lot of other drawbacks.

Pgn databases can also contain millions of games and even more positions. But I was thinking mainly to save only parts of the hash (by material "slices" if I am interested in - for example - rook endgames, or by depth).
Of course the information in the hash is full of noise and gaps but it would be nice to have a peek.

cdani · Post by **cdani** » Sun Jul 30, 2017 11:18 pm

Arpad Rusz wrote:
cdani wrote:
A hash table can contain several millions of entries. So a pgn file seems not to be a good container for it. Also there are a lot of other drawbacks.

Pgn databases can also contain millions of games and even more positions. But I was thinking mainly to save only parts of the hash (by material "slices" if I am interested in - for example - rook endgames, or by depth).
Of course the information in the hash is full of noise and gaps but it would be nice to have a peek.

A hash viewer/searcher can be done, but is quite a lot of work. Many people should ask for it so maybe some programmer decides to do it. But I'm not sure if it will be very valuable.

kbhearn · Post by **kbhearn** » Mon Jul 31, 2017 8:59 pm

cdani wrote:
Arpad Rusz wrote:
cdani wrote:
A hash table can contain several millions of entries. So a pgn file seems not to be a good container for it. Also there are a lot of other drawbacks.

Pgn databases can also contain millions of games and even more positions. But I was thinking mainly to save only parts of the hash (by material "slices" if I am interested in - for example - rook endgames, or by depth).
Of course the information in the hash is full of noise and gaps but it would be nice to have a peek.
A hash viewer/searcher can be done, but is quite a lot of work. Many people should ask for it so maybe some programmer decides to do it. But I'm not sure if it will be very valuable.

A hashtable as tree viewer should be of great value to developers themself at least as a quick way to view why an engine's not finding a particular move and make the right attempt to create a patch to try and solve the problem. In a lot of cases it might be usable by experienced end users who simply want to know 'why not move X?' without interrupting the current search - but that use case is a bit more questionable. It really ought to be done as a gui feature + protocol extension to be interactive at any point in the search.

Rodolfo Leoni · Post by **Rodolfo Leoni** » Mon Jul 31, 2017 9:41 pm

kbhearn wrote: A hashtable as tree viewer should be of great value to developers themself at least as a quick way to view why an engine's not finding a particular move and make the right attempt to create a patch to try and solve the problem. In a lot of cases it might be usable by experienced end users who simply want to know 'why not move X?' without interrupting the current search - but that use case is a bit more questionable. It really ought to be done as a gui feature + protocol extension to be interactive at any point in the search.

My two cents here. I'm not a programmer and I don't know if this makes some senses: 99% of hashed positions are of no importance. They're stored there only because of possible trasposition and it could take a lot of time to study them to understand if theres a problem with search.

Anyway, I guess the fastest way to "read" the hash contents could be to convert them to an EPD file, and to use an utility to get a tree out of them. I don't know if such an utility exists, anyway.

(Please someone could tell me if I'm writing idiocies?)