root move ordering

[AlvaroBegue]

We also observed the program during games, and it was clear that the very last move searched turned out to be chosen surprisingly often.

Are you sure it wasn't just the last move to be *finished* searching, as opposed to the last move in the array?

I ask because I've been seeing that when splitting searches at the root only. One thread will be busy calculating by itself when all the other root moves are already searched, and then after a while this thread will announce a new best move.

In my case it didn't mean it was the last move in the array, it just meant that this move took quite long to search (which makes sense considering the "many nodes" = "hard to refute" = " good move" heuristic that many are discussing here).

Yes, I am sure. This was a single-threaded program, so what you are describing is not possible.

[bob]

We also observed the program during games, and it was clear that the very last move searched turned out to be chosen surprisingly often.

Are you sure it wasn't just the last move to be *finished* searching, as opposed to the last move in the array?

I ask because I've been seeing that when splitting searches at the root only. One thread will be busy calculating by itself when all the other root moves are already searched, and then after a while this thread will announce a new best move.

In my case it didn't mean it was the last move in the array, it just meant that this move took quite long to search (which makes sense considering the "many nodes" = "hard to refute" = " good move" heuristic that many are discussing here).

Yes, I am sure. This was a single-threaded program, so what you are describing is not possible.

His point still stands. If you do incomplete iterations (stop when time runs out rather than when an iteration ends) then this is not that unusual. You search some of the root moves, get stuck on what will be the new best move, time runs out (and if you do a Crafty does and insist that the incomplete move be finished before the search is stopped) then the "last move" you search will be best for that reason.

If the move sorted last at the root is best, a significant part of the time, that would suggest _major_ problems in ordering those moves.

[AlvaroBegue]

We also observed the program during games, and it was clear that the very last move searched turned out to be chosen surprisingly often.

Are you sure it wasn't just the last move to be *finished* searching, as opposed to the last move in the array?

I ask because I've been seeing that when splitting searches at the root only. One thread will be busy calculating by itself when all the other root moves are already searched, and then after a while this thread will announce a new best move.

In my case it didn't mean it was the last move in the array, it just meant that this move took quite long to search (which makes sense considering the "many nodes" = "hard to refute" = " good move" heuristic that many are discussing here).

Yes, I am sure. This was a single-threaded program, so what you are describing is not possible.

His point still stands. If you do incomplete iterations (stop when time runs out rather than when an iteration ends) then this is not that unusual. You search some of the root moves, get stuck on what will be the new best move, time runs out (and if you do a Crafty does and insist that the incomplete move be finished before the search is stopped) then the "last move" you search will be best for that reason.

If the move sorted last at the root is best, a significant part of the time, that would suggest _major_ problems in ordering those moves.

That's not it either. And I know what it is, so I'll just explain the details.

As I mentioned before, we had an aggressive forward pruning heuristic that created the situation. This pruning would reduce the search depth of many moves by a full ply. Sometimes this would mean that a move that had already been searched to depth 10 in the previous iteration of deepening (when it wasn't reduced, because it looked promising) will now have to be searched to depth 10 again. Hash tables kick in, and the move is refuted in a single node.

Sorting by node count was pushing this move all the way to the end. By only allowing a move to be pushed back a maximum of 3 positions, the order didn't suffer from this.

[Ralph Stoesser]

Regarding your change, well it is interesting, our is tiny, but not so tiny

I have not analyzed yet why it is better, but I would assume a better load factor for the history table. Unknown non-capture moves will recieve a history score earlier than before and this may help in later move orderings.

Anyhow, it seems the move ordering alchemy has still room for good improvements.
What is your change? Or is it secret because of competition considerations?

[mcostalba]

Regarding your change, well it is interesting, our is tiny, but not so tiny

I have not analyzed yet why it is better, but I would assume a better load factor for the history table. Unknown non-capture moves will recieve a history score earlier than before and this may help in later move orderings.

Anyhow, it seems the move ordering alchemy has still room for good improvements.
What is your change? Or is it secret because of competition considerations?

Sorry, you'll see in next release

P.S: Very far away in the future, I add this to avoid annoying questions on planned next release date.

[Ralph Stoesser]

Regarding your change, well it is interesting, our is tiny, but not so tiny

I have not analyzed yet why it is better, but I would assume a better load factor for the history table. Unknown non-capture moves will recieve a history score earlier than before and this may help in later move orderings.

Anyhow, it seems the move ordering alchemy has still room for good improvements.
What is your change? Or is it secret because of competition considerations?

Sorry, you'll see in next release

P.S: Very far away in the future, I add this to avoid annoying questions on planned next release date.

The little secrets of open source kick in again.

Instead of *very far away in the future* you could avoid to tell publicly about +10 Elo changes regarding move ordering of non-captures in the present. Maybe this could help on annoying questions *in the present*?

[Uri Blass]

Regarding your change, well it is interesting, our is tiny, but not so tiny

I have not analyzed yet why it is better, but I would assume a better load factor for the history table. Unknown non-capture moves will recieve a history score earlier than before and this may help in later move orderings.

Anyhow, it seems the move ordering alchemy has still room for good improvements.
What is your change? Or is it secret because of competition considerations?

Sorry, you'll see in next release

P.S: Very far away in the future, I add this to avoid annoying questions on planned next release date.

Sorry but I do not understand what do you earn from keeping your improvements as secret.

It may be better if you release every new version(even if the improvement is only 1 elo)

Maybe in this case more people can help in testing and you make a bigger improvement(when part of the help may be finding cases when the changes that you believe to be good are bad at slower time control or with more games or against other opponents).

Uri

[mcostalba]

Sorry but I do not understand what do you earn from keeping your improvements as secret.

It may be better if you release every new version(even if the improvement is only 1 elo)

Maybe in this case more people can help in testing and you make a bigger improvement(when part of the help may be finding cases when the changes that you believe to be good are bad at slower time control or with more games or against other opponents).

Uri

Releasing each 4-5 month only help testers and avoids caos. You can already experience the few weeks of pseudo-forks that spurs at every release, normaly this is a decay process so that there is a peak just after release time then things calm down, in case we open our repository (because that's what you are asking for) I think the confusion would be overhelming and the originated noise would cover the little signal of an actually new release.

I am quite scared by the idea of a couple of "new" SFxxx compiles every week that materialize out of the blue. In this way your project quickly disappears in the garbage.

If people is seriously interested in developing (as can be Vratko, just to make a name) there are plenty of ways to contribute with patches _and_ serious tests. We have published this small ELO increase / big code change release just for this only reason.

[Don]

Regarding your change, well it is interesting, our is tiny, but not so tiny

I have not analyzed yet why it is better, but I would assume a better load factor for the history table. Unknown non-capture moves will recieve a history score earlier than before and this may help in later move orderings.

Anyhow, it seems the move ordering alchemy has still room for good improvements.
What is your change? Or is it secret because of competition considerations?

Sorry, you'll see in next release

P.S: Very far away in the future, I add this to avoid annoying questions on planned next release date.

Sorry but I do not understand what do you earn from keeping your improvements as secret.

It may be better if you release every new version(even if the improvement is only 1 elo)

Maybe in this case more people can help in testing and you make a bigger improvement(when part of the help may be finding cases when the changes that you believe to be good are bad at slower time control or with more games or against other opponents).

Uri

Uri,

The process of making a release is very stressful - and also involved a flurry of emails and other distractions that you have to deal with. I would say that each release slows down the development process a little. They can also help the development process if they are not done too frequently.

One could just open up the development repository of course, but then there would be mass confusion about which version to use and start testing and again this would lead to a lot of extra communication and distraction for the developers.

This might work if the developers can avoid these distractions and basically declare the code to be what you see is what you get, use at your own risk, etc.

But do you honestly believe this would reduce the amount of questions that they would receive?

[Ralph Stoesser]

If people is seriously interested in developing (as can be Vratko, just to make a name) there are plenty of ways to contribute with patches _and_ serious tests.

I cannot find the name Vratko Polák in the 1.8 sources. Either he has not contributed much or it was one-side trade. Others contribute patches, bug fixes, ideas and you put your name under it. Maybe this your understanding of "open source"?

To open up the git repo for public read access would be appropriate. People who contribute to the SF development should know what's going on.