Persistent Hash

[Tony]

Everything you might have wanted to know about Rybka III's Persistent Hash.

"In addition, users can share persistent hash files, so that user A can benefit from the analysis done by user B. Persistent hash files can also be merged, so that user A can benefit from analysis done separately by users B and C. These various scenarios are the topic of this document."

also:

"1) Set the [Persistent Hash Path] engine parameter to some path on your hard drive where you want the persistent hash file to be placed."

This is why I asked about Ramdisk in my earlier post. My only remaining question is, is there really a 2 GB limit for Persistent Hash? Waiting for Vas to answer ...

Just for the record, this is not a "new feature". Crafty had this ability 10 years ago, the ability to share the "position.lrn" file (an ascii version of position.bin so that a user could combine persistent data from multiple users...

However I am not personally much of a fan of the idea and I even removed the persistent hash completely from version 22.0...


http://www.rybkachess.com/docs/Rybka_3_ ... t_hash.htm

Don't try to confuse the situation with facts Bob.
If Vas takes something existing and improves on it he should be called at least the inventor, if not God.

Tony

I know. looks to be a world based on hyperbole at times. In my case, we were exporting ascii "book.lrn" and "position.lrn" files that users could share easily and which could be combined if desired. The persistent hash idea is OK for analysis. For games it is worthless. I removed it because it causes more problems when testing because rerunning the same test can lead to false results if you forget to remove the position.bin file first. I forgot to do so enough times that it became more imporant to simplify testing than to try to help learn something about specific positions that is not applied generally in the tree.

I actually made some improvements on the idea. I have been using it for a while now as a selflearning opening book.
The idea is that it isn't really a hashentry anymore, but an entry that has a minscore, a maxscore and a lowest selfscore ( score that the last search gave back from here, excluding scores from moves that were minimaxed back to here)

I'll leave the rest for the interested...

Tony

[Dirt]

The persistent hash idea is OK for analysis.

From occasionally reading the discussions, that seems to have been the major motivation for it. Many customers are mainly interested in analysis. Its learning capability is why I occasionally turn to Spike 1.2, despite there being stronger free programs available.

[Eelco de Groot]

I actually made some improvements on the idea. I have been using it for a while now as a selflearning opening book.
The idea is that it isn't really a hashentry anymore, but an entry that has a minscore, a maxscore and a lowest selfscore ( score that the last search gave back from here, excluding scores from moves that were minimaxed back to here)

I'll leave the rest for the interested...

Tony

Hello Tony,

That sure sounds interesting, but I must admit your idea does not make a coin drop here in my mind, I more or less can understand the concept of a minscore and a maxscore as a lower bound and an upper bound, but when you go on about a lowest selfscore my imagination draws a total blank.

Could you maybe explain this a bit more? When you say that you are excluding moves that are minimaxed back to that point, I thought that more or less any search that is started in a node is about minimaxing moves back to that point, so I'm afraid I have really no idea in what direction you were trying to point us..

I hope that you could maybe give some pointer or, if that is easier maybe, a code example of what you mean?

Regards, Eelco