Why no standard for (exchange of) position learning?

[Eelco de Groot]

To start of maybe a poll question, to see what you guys would think of anything like this, if maybe something like an exchange standard for position learning could ever be developed, some input from the programmers would be much appreciated!

Thanks, Eelco

[Dann Corbit]

To start of maybe a poll question, to see what you guys would think of anything like this, if maybe something like an exchange standard for position learning could ever be developed, some input from the programmers would be much appreciated!

Thanks, Eelco

An EPD record could be considered an open standard for positional learning.

In fact, previous crafty versions could read EPD records into its learn file. I don't know if the current version can still do that.

[Dirt]

What do you think should be stored such that the data would be of use among different programs? The only thing I can really see as being clearly useful would be to store part of the PV for move ordering, but the maximum benefit from that seems too limited to get excited about.

[Dann Corbit]

1. ce
2. depth searched
3. bm
4. am
etc.

Anything you can put in an EPD record is fair game.

It is especially useful for things near the origin where there was a massive fail high or fail low on a pv node.

[Eelco de Groot]

To start of maybe a poll question, to see what you guys would think of anything like this, if maybe something like an exchange standard for position learning could ever be developed, some input from the programmers would be much appreciated!

Thanks, Eelco

An EPD record could be considered an open standard for positional learning.

In fact, previous crafty versions could read EPD records into its learn file. I don't know if the current version can still do that.

Thanks Dann, I did not know that Crafty could use EPD records as position learning! It is very interesting, I think it means Bob thinks it is not a waste of time to implement this!

I was going to suggest at first that for a more useful learn result across programs you would probably need to store all the positions in a PV separately, not just the one eval because the eval alone is not enough, especially if the result is coming from another program. With a whole PV available the program can use this PV at least for move ordering and an eval by another program can be replaced I think with the own eval of the final, leaf-, position in the PV. It would not be perfect but at least this gets rid of large eval discrepancies between programs. There is no way to ascertain quickly the accuracy of a PV but for the lower, worse, move candidates I think this becomes increasingly less important? I hope so at least...

In the case of EPD records there is a full PV already stored there, so all the separate PV positions can be reconstructed from that and the benefit is that is more compact and readable!

What could be added I think is a way of identifying in the EPD record which program made each analysis. A second program could make some intelligent use of that, in discarding lower depth searches from the same program only keeping the deepest searches for instance, and in case of different programs coming more or less to the same conclusions, separate results corroborate each other. Results from programs that are not so strong or not known could be treated more carefully or restrictively than those of stronger programs or better known programs.

It is more my intuition, I'm lacking the programming insight I'm afraid to back it up but I think it should be possible somehow to use say a 20 ply result from a strong program, but with a different playing style, as something equally good as say a 16 ply result from your own program?

From an AI perspective, - yes I'm getting ambitious here we, as humans have almost infinite ways of communicating our knowledge and experiences to other human beings to great effect and efficiency, we can interpret really a lot from little, so we don't have to reinvent every wheel each by ourselves, everytime.

At this point I think chess programming is still very poorly developed; a program can at one end of the spectrum communicate to another what it found as best move in a position after a long search. The second program can then either accept this as a "bookmove", or start its own search completely from scratch. At the other end of the communication spectrum the first program could maybe transfer its whole hashtable, and the second program, if it is fairly identical, could then use this "core-dump" to start the next iteration to get a more reliable result for instance. At least in principle this could be done. But that is all, there is nothing in between in the communication spectrum! If the two programs are different the second option is not even possible, and even if it was, it is not practical to save or transfer a complete hashtable to a new search!

So from the AI point of view I think this is still a very poor state of affairs. The EPD records may fill some of the gap but what programs can use this?

The AI question then I think is more or less this; 'Is there a way to condense the contents of a search, say the complete hashtable results, not necessarily for chess only but any type of alpha-beta search, maybe augmented with organizing the search a bit differently than standard alpha-beta, so that the condensed information can help a second, different program to continue the iterated search, to the next depth for instance, without having to start from zero again?'

You can't possibly save all the data from the hashtable but what could be most useful? Again, I am lacking the programming skills here but what I was thinking could be used is that 99% or so of this search tree is nonsense variations, somehow I think it must be possible to condense that, maybe you need extra searches for that but that is not important, what is important is maximum useful information density in the "message" you are composing. So far this maximum information density and maximum usefulness, I think you actually need to focus more on the bad moves than on the good moves. If the bad moves, or the LMR-candidates as another term for those moves, are proven sufficiently bad it does not matter very much anymore I think which program did the searches! For the good moves it is much more likely that these need to be re-searched by the second program, because it has different preferences and strengths, there you can always use the PVs for moveordering at the least, but maybe not much more. The very worst continuations can even be pruned completely I think in the "message", although Vas has said in this respect that you would probably quickly find out that a programs that completely stops searching certain variations is not a program that you will like.

Intuitively it could be useful to have more precise variations on lower LMR candidates than normal alpha-beta provides (as far as I understand this) because this allows you to do deeper LMR reductions further on.

But it is up to the second program I think how much the "worst", lowest, variations are still allowed to grow.

So, an example maybe in the case there is no opening book, and Junior would search the position after 1. e2-e4 e7-e5 2. Ke1-e2?? to say twentyfive plies completely, this would be pretty useful still for any other program starting in the ground position, because the eval is probably so bad, a twentyfive ply result could probably still be safely used under LMR reduction conditions in a hypothetical 40 ply search! In principle then, this variation would probably never have to be searched again! Just translate the leaf position to an eval by the own program and the result should be bad enough to need no further searching. By no program, ever again! I think this saves some cycles!

This is from the starting position so not really practical but for typical opening postions I think this same principle can be used? Just intuitively I think this must speed up the search, allow the program to concentrate on the variations that matter and that are truest to its own style, and not just opening book moves it follows blindly.

So another thought here, along similar lines, for the lower LMR candidates, at any interior node too, I think you can use a simpler search, sufficient depth is more important here than finesse in the eval.

I just read on the Rybka forum about somebody who let his Rybka compute for thirteen days just in order to compute a known best move! Is it not a waste that there is not yet a good way to preserve some of this analysis, not just the final move but some information that can help another program confirm this result for instance?

In this way we can in theory at least save some time and joules although in the case of chess I think it will just be used for more analysis But maybe if applicable in more practical appplications it will help actually against Global Warming a bit

Eelco

[Eelco de Groot]

What do you think should be stored such that the data would be of use among different programs? The only thing I can really see as being clearly useful would be to store part of the PV for move ordering, but the maximum benefit from that seems too limited to get excited about.

Hi Greg, thanks much for your input, see my reply to Dann above, I tried to give my best answer, I think what Dann is saying is a bit along the same lines? Benefit depends on the quality and completeness of the learnresults I think.

Eelco

[bob]

I don't think the idea is useful. In fact, I have removed position learning from Crafty completely. Minor changes to the search or evaluation make positional scores change, and make using old scores problematic. DIfferent hardware makes such data invalid, any program changes do. And position learning is used primarily during analysis rather than when actually playing a game, which makes it less important to most.

[bob]

To start of maybe a poll question, to see what you guys would think of anything like this, if maybe something like an exchange standard for position learning could ever be developed, some input from the programmers would be much appreciated!

Thanks, Eelco

An EPD record could be considered an open standard for positional learning.

In fact, previous crafty versions could read EPD records into its learn file. I don't know if the current version can still do that.

Into the book learning, not into the position learning. I have removed position learning in fact, as it caused more questions than it answered since one could not run the same position multiple times without deleting the file, else the results would change.