Polyglot opening book specification

[H.G.Muller]

I know nothing of Chessbase GUI and PCC, but I did use a packet sniffer once to decode the protocol of the Gothic-Chess server (now deceased) which was using a browser-based client written in Java. I was surprised how simple this was, I did not even have to decompile the Java class files. But then, how complicated can a protocol for a Chess game be...

I wrote a WinBoard back-end to connect to this server, as a pseudo engine. It worked fine, except that the server itself was buggy and went out of business, so that the whole operation has been a waste of time.

[Michel]

the weight for Nf6 is 0%. The way I understand this is that my book should had never make this move if the weight is 0%. So, how is this possible?

The PG format does not allow a weight that is truly zero but rather something like 2^-16.

I have been been advocating that GUIs or engines using PG books discard moves with weights below a certain treshhold to solve this problem but H.G. Muller does not agree . So you should talk to him...

[matematiko]

Thanks for your answers/comments.

[H.G.Muller]

Well, it seems that this is a SCID error, so the logical solution would be to fix it in SCID.

If you want to set the probability of a move to a mathematical zero, the SCID should have removed it from the book. That is a very obvious solution, and I still have not heard a good argument why that would not be possible.

The alternative is to force a host of book-using programs to all change their operation, just to mask a bug in a single program... And that sounds like a very bad idea.

[Michel]

If you want to set the probability of a move to a mathematical zero, the SCID should have removed it from the book. That is a very obvious solution, and I still have not heard a good argument why that would not be possible.

We are talking about book tuning here.

Against another opponent you may want to raise the probability again from zero to something positive.

Deleting and inserting moves is cumbersome and very error prone (how would you remember which moves can be "reinserted")....

[Michel]

The alternative is to force a host of book-using programs to all change their operation, just to mask a bug in a single program... And that sounds like a very bad idea.

If there is a bug then it is in the polyglot book format, not Scid. When Fabien Letouzey created the PG format there were no GUI tools, so book tuning was not possible (you would have to regenerate the book if you wanted to change weights). This has now changed with Scid.

[H.G.Muller]

Deleting and inserting moves is cumbersome and very error prone (how would you remember which moves can be "reinserted")....

Well, I am no book-builder, but this seems a strange argument. How would you know which move is safe to turn up to a significant weight, even if it is there? It might have been a minor move for which the book is not really well developed, and people might tune it up to become the only move. Keeping the move with infinitesimal weight, rather than deleting it, does not seem to solve much in this respect.

If the problem is that the format specs are at fault, change the specs. I would be surprised if any book readers would crash on encountering a weight of zero. WinBoard would not, that's for sure. Only if the sum of all weights equals zero there could be a problem, and it is easy enough to prevent SCID from doing that.

Btw, it is easy enough to get If you want to completely surpress a move, while still being able to revive it: copy the move to the weight field (e.g. as a 12-bit, or even 8-bit encoding) and change the move to that of the move with the largest weight, and subtract the move encoding from the latter weight. Then the information of what moves were originally present is still there, hidden in the weights of duplicate moves.

[Michel]

If the problem is that the format specs are at fault, change the specs.

It is too late to change the specs in a non-backward compatible way.

EDIT: I meant to say: it is too late to change the file format in a non-backward compatible way.

[H.G.Muller]

Well, so do it in a non-backward-compatible way. Who cares if in practice it does not break anything backward? As I understand it, the weight 0 is not used for any other purpose, it is an unused ('reserved') code. Only pedantic backward software would suffer, and if people want to tune a book for such software, they should not set the weights to zero, but to 2^-16 in stead.

Make them aware that they are using a kludge which works imperfectly, (so they don't start to complain if it does not work once in a while)and offer them the possibility to use a non-backward-safe solution that most of the time will work perfectly in practice, at their own risk.

[Michel]

just to mask a bug in a single program...

I find this pretty offensive actually. Scid does not generate buggy books. Why do you keep insisting that it does?

[H.G.Muller]

Writing 2^-16 where you mean 0 is a bug. Airplanes have crashed because of less...

The Polyglot standard, for no discernable reason, seems to require that to give a move zero weight, you should delete it. Now if you take that standard seriously (I wouldn't, but that is another matter), it should do as it prescribes. So if I ask for zero weight, and SCID does not delete the move from the book, it should be considered a bug.

I cannot suger-coat that in any way, no matter how offensive it may be.

[Michel]

Writing 2^-16 where you mean 0 is a bug. Airplanes have crashed because of less...

The Polyglot standard, for no discernable reason, seems to require that to give a move zero weight, you should delete it. Now if you take that standard seriously (I wouldn't, but that is another matter), it should do as it prescribes. So if I ask for zero weight, and SCID does not delete the move from the book, it should be considered a bug.

I cannot suger-coat that in any way, no matter how offensive it may be.

Deleting a move when you want to temporarily disable it is not a good option.

Scid did the closest thing to zero weight permitted by the spec (as indicated by ASSERTS in the PG source).
This is not a bug. It works nearly perfectly. For it to be completely perfect it needs a minuscule modification of the mapping
weights->probabilities (which is not formally specified yet anyway). A few lines of C code are sufficient, far less than what is required to use PG books at all.

You are asking Scid to violate the spec. That would be a bug.

[H.G.Muller]

Deleting a move when you want to temporarily disable it is not a good option.

Scid did the closest thing to zero weight permitted by the spec (as indicated by ASSERTS in the PG source).
This is not a bug. It works nearly perfectly. For it to be completely perfect it needs a minuscule modification of the mapping
weights->probabilities (which is not formally specified yet anyway). A few lines of C code are sufficient, far less than what is required to use PG books at all.

You are asking Scid to violate the spec. That would be a bug.

Well, to me it seems a very good option. And, like I described above, if you think using a kludge to retain info on which moves are disabled and which aren't is better than deleting them, there are kludges available that achieve that purpose better. Or is it explicitly specified in the standard that each move should occur only once?

Where, actually, is this original standard described? It is not the description on your website, not? That was recently written by you, and you could just as easily delete the boldface restriction that zero weights are not allowed. Which book-using programs would you break if that was removed from the standard?

You make it sound if Scid has no choice. But, if you don't want to delete moves (which is a choice), I think that a proper implementation would be not to accept a user specification of a weight of zero without complaints or warnings. Scid could pop up a dialog box, explaining that it cannot implement a weight of zero without deleting the move, and offer the used the choice if the move should be deleted, if the user will settle for 0.015% weight in stead, or if he wants to violate the specs and run the risk that the resulting book might not be usable by everyone as a result.

I do not consider violating the specs of an old and obviously broken standard, and in stead conform to a new but incompatible one, on express order of the user, a bug. It is a very legitimate wish of a user to want that. If I were making a private book for Joker, I would say: "F*ck the standard! I want weight zero, and I don't apreciate stupid software to tell me what I can and can't do!"

[Michel]

Where, actually, is this original standard described?

As far as the file format is concerned I think we have no choice but to take
the polyglot source as a reference. Otherwise everybody can start
making random modifications on the specification.

There is an explicit ASSERT in book,cpp .

// pick this move?

ASSERT(score>0);

I think that this is sufficient to make it mandatory. You shouldn't blame Pascale Georges
for acting in a sane way.

Nothing prevents us however to play with the mapping weights->probabilities.
I am suggesting a minuscule, change.

I recall you were planning to make a far more drastic change with your power law.
This was what prompted this discussion if you remember.

[H.G.Muller]

Taking a source of an implementation as the definition of a standard? NEVER!

This would be tantamount to declaring by definition that that implementation cannot have bugs, and excercises all of the possibilities the standard offers. Especially when a program crashes in certain conditions, it would be plain ridiculous to require that other programs using that standard should mimic the crashing behavior.

The ASSERT you quote should be considered an obvious bug. ASSERTs are meant to catch conditions that would later cause improper functioning of the code (at a stage where the origin of the problem might be harder to diagnose). I don't think that this ASSERT can be said to serve that purpose. I have not seen the full code, but very likely nothing erroneous would happen when you offer it books with (some) zero weights after deleting this ASSERT. And Asserts are not supposed there for annoying the user and sabotage working of a program that would be correct if it were not for the ASSERT.

The situation is best described as that the programmer forgot to remove some diagnostic output for testing the book-making function of Polyglot. (Which, due to the algorithm used, would never include moves with zero weights.) As a result Polyglot crashes when presented with a book that contains zero weights, while it is (apparently) perfectly reasonable to want moves with zero weight in the book. I think this should count as a Polyglot bug. Not as the definition of a standard.

I will make sure, and guarantee and document, that WinBoard will be able to handle weight 0 in the GUI book, as long as not all weights from the position are zero. It does so now, but when in a later version I will take logarithms of the weights to implement weighting by a power, I will certainly intercept the case w=0 (and define 0^x = 0 for any x>0).

If a standard should be distilled from the Polyglot source, the way I would formulate it is like this: "The weight indicates the relative probability that the move is (was) played, but due to a bug Polyglot cannot handle a weight of exactly 0. But most other programs supporting Polyglot books, including WinBoard, can.". Of course it would be preferable if one could say "... due to a bug older versions of Polyglot cannot handle ..." in stead.

[Michel]

I can simply not understand your objections against a mapping weights->probs

if(weight< epsilon){
prob=0
}else{
prob=weight
}

but on the other hand consider

prob=weight^(1/2)

to be ok.

Both deviate from PG but the second one much more than the first one.

[H.G.Muller]

I view the power correction as on-the-fly book tuning, not as changing the meaning of the weights. A valid comparison would be:

Why would it be OK to use SCID to give 1. d2-d4 a weight of 0.0015%, and not raise all weights to the power 1/2?

A very good reason for wanting such a feature is that there would be no way for the user to obtain the same effect as taking the weights to some power in any other way than to re-do the entire book. Zero-weights, OTOH, can only occur because of a user intervention on that particular move anyway. There is no need to have some over-all knob to change global behavior.

That you get behavior that is very different from what PG does is good. It would be pointless to add controls to a piece of software that do things that in practice make no difference at all. This would just confuse the user, which I do consider a very undesirable trait in software.

[Michel]

You seem to be posting under my name now (and deleting my posts).

And can you please stop calling everyone else's code bugs.

[H.G.Muller]

Oops...

I am very sorry about this. I must have accidentally pressed 'edit' in stead of 'quote'. The problem is that there is hardly any visible difference when I do that; in both cases the text of the original message appears in the input text window.

I have deleted the message I messed up. Unfortunately there is no way to restore the original text I overwrote.

The problem is that I have moderasation rightson this board, to be able to adapt the posting with the WinBoard downloads, when needed. But it makes it very easy to make this mistake.

What I had written (this time posted onder my own name):

IMO the accidental behavior of a particular implementation is not automatically suitable as standard. A standard for general use should obey much higher requirements of logic, ease of use, predictable behavior, etc. While for an implementation the only requirement is that it works.

Polyglot saw no reason to make it work correctly for weight = 0, because at that time the only producer of books in Polyglot-format books was Polyglot itself. It did not allow book tuning, and its algorithm for making books out of collections of PGN games never would lead to a weight of zero, so there was no need to make Polyglot work correctly for such weights. Hece the weight>0, in stead of weight>=0 assert bug was without consequences.

But for a standard the Polyglot behavior (crashing on logical and perfectly reasonable input) is not acceptable. You are trying to elevate a bug to the status of standard, and that is always a bad idea.

I consider putting in code for no other reason than to make a program crash in situations where it would otherwise have worked without problems in the intended way a bug. And as long as I consider it a bug, I will continue to call it a bug... In fact this is already giving the programmer the benefit of the doubt, by assuming that this behavior was caused accidentally, and not by intentional criminal intent!

What you put on your website is an accurate description of the behavior of the original Polyglot, but IMO this behavior is not acceptable as standard. It fails on the requirement that the definition of the weights must be logical and intuitively obvious.


Considering the undesirable situation w.r.t. booktuning it seems better if I bypass Scid altogether, and equip WinBoard with a menu item to change the weights of all book moves from a given position.

[Roger Brown]

You seem to be posting under my name now (and deleting my posts).

And can you please stop calling everyone else's code bugs.

Hello Michel,

I apologise. Sight unseen, H.G. would never do that (delete posts etc.) deliberately. I assure you.

The man loves an argument far too much to ever post under any name but his and further, he would never take advantage of an opponent.

He is getting accustomed to the board and the moderation functions and buttons.

Should you suspect that you are being wronged, feel free to report to me instead of making unfortunate comments on the Forum.

H.G. does have a habit of getting under the skin but I have observed that there is more often than not, an advancing of knowledge. It is not so much that he is correct or not - it is that the process aggravates deeper thought about matters long thought settled.

Personally I would not like to be directly involved in discussions with the man (H.G. is rather, ah, firm in his positions) but a personal consideration is not a valid reason for thinking the worst of someone. I think that there will be good out of all of this. Hence my willingness to watch it evolve and to let you know that no-one is going to negatively impact your rights.

Let the debates continue!

Later.