Using Polyglot Hash Value = Clone / Deriving?

[Steve Maughan]

I'm starting to think about implementing the hash code in Maverick. One option would be to use Polyglot's hash values. This would then save time when implementing Polyglot opening book support. Of course I don't want to step on anyone's toes. Would anyone think this is tantamount to "deriving" from Polyglot. I cannot really see how one can implement Polygot compatibility without using the hash code but I thought it's worth asking

Steve

[Evert]

I cannot really see how one can implement Polygot compatibility without using the hash code but I thought it's worth asking

You can't. You need to construct the polyglot key to probe the book and for that you need the hash values from polyglot.

So

I'm starting to think about implementing the hash code in Maverick. One option would be to use Polyglot's hash values. This would then save time when implementing Polyglot opening book support. Of course I don't want to step on anyone's toes. Would anyone think this is tantamount to "deriving" from Polyglot.

I don't think so. I would just call it being efficient/consistent.

The only reason I don't use polyglot keys for my hash table is that I implemented my own first and I'm too stubborn to switch over for no good reason. It means I waste time when probing the opening book, but you only do that once, at the beginning of the search (and you can skip it if you've been out-of-book for long enough that you don't expect to transpose back into it). It's not a time-critical piece of code.

[mar]

I'm starting to think about implementing the hash code in Maverick. One option would be to use Polyglot's hash values. This would then save time when implementing Polyglot opening book support. Of course I don't want to step on anyone's toes. Would anyone think this is tantamount to "deriving" from Polyglot. I cannot really see how one can implement Polygot compatibility without using the hash code but I thought it's worth asking

Steve

Polyglot is not a chess engine in the first place, so using its pseudorandom hashes is absolutely ok IMHO, it has zero effect on the engine itself. Anyone HAS to do that in fact in order to read polyglot books. The problem is that the books can be discontinuous (you can't reach all positions simply by starting at root and tracing the moves associated with it).
Because I recently wanted my own book format and import from polyglot, I tried wild things like recurively expanding all reachable leaf nodes, hoping to find a collision later, because you can't simply take a hash and trasform it into another - that's impossible.
Of course this was very slow and I never was able to go deep enough to reach all positions in the book.
So the ONLY way is to use polyglot keys (and hash exactly the way polyglot does). There is no workaround unfortunately.
I wonder how bookmakers handle these discontinuities themselves.
In theory a full path to each position in the book could be stored in polyglot format (simply connect by using moves with zero count) but there are actually very few (none) such polyglot books. Perhaps polyglot even does this optimization itself by removing such moves to be as small and compact as possible.

[hgm]

In the description of Polyglot book format Michel van den Bergh remarks that it is likely not possible to copyright a table of random numbers, and I tend to agree with him. Supporting Polyglot books in your engine necessitates using that table to generate keys. Thus doing so does not make your engine a derivative anymore than supporting WB protocol would make your engine a derivative.

Not sure about the probing code. I think the code on Michel's page is explicitly placed in the public domain, (so it is different from what Polyglot contains, which is GPL'ed), but purists might require you wrote the code (e.g. for finding a (key,move) pair in the book file) yourself.

[Steve Maughan]

Thanks for the comments! I agree with them all. Basically Polyglot isn't an engine, there is nothing intrinsically special about the hash keys so I'll use them as my own hash keys but write the probing cod from scratch.

Thanks again,

Onward!

Steve

[Don]

I'm starting to think about implementing the hash code in Maverick. One option would be to use Polyglot's hash values. This would then save time when implementing Polyglot opening book support. Of course I don't want to step on anyone's toes. Would anyone think this is tantamount to "deriving" from Polyglot. I cannot really see how one can implement Polygot compatibility without using the hash code but I thought it's worth asking

Steve

Wow! In a field where many have ignored their conscience (or have no conscience) you are worried about this. It warms my heart to read this!

It is industry standard practice and perfectly acceptable to provide functionality that allows your software to interact with other tools or data formats. This applies even you have to reverse engineer the software, so it certainly applies in the GNU case. As long as you don't use the open source polyglot software you don't have a problem. Tables of random numbers are not subject to copyright anyway, as far as I know, and it would not be possible to provide support for polyglot books without this table.

If it really bothers you, you could create a book using your OWN format and also provide a tool to covert from polyglot format to your own format. The tool could be based on polyglot code and you could provide it under the same GNU General Public License. It would be a dirt simple thing to do as the only change would be a different table. But it is really not necessary to do that.

[Steve Maughan]

Hi Don,

Thanks! Yes I've come to the same conclusion - random numbers cannot be copyrighted.

Maverick's hash table is now calculating and uses the Polyglot random numbers.

Cheers,

Steve