Singular extension tests

[Chan Rasjid]

Hello Michael,

Your scheme differs from that of Bob and it is not what he wants.

In an all-node, Bob's scheme either stores the original tt-move or the first move done,ie the move with the highest original ordering. In your scheme, the move stored might be way down in the original ordering. Such a move, if first searched in a hash hit in a subsequent search, will not be searching a move with the highest ordering and it would be a bad move to try.

Rasjid.

[Desperado]

...
If I fail low at any node, this is stored in the hash table as a "UPPER" position and there is obviously no best move to store. In Crafty, as a search is carried out, I save the first move searched (which may be the hash move, or the first capture tried, or the first killer (if there is no hash or safe capture move) or just the first move generated in the worst case. When I discover that this is a "UPPER" position with no best move, I store the first move searched as the best move. Why? The next time I hit this position, I will search that move without a move generation, and without a best move that is the move I would end up searching first anyway, so why not?
...
However, this now means that _every_ hash hit will have a best move (the EXACT/LOWER positions obviously would, and now UPPER also).
...

i agree that having a move available will improve the search,
and results in positive elo gain.

i dont agree that is has to be the first move given by the moveselector.
(as we all know,which tries: tMove,captures ...)

i am prettey sure, that using the move with the highest fail-lo score
is the better choice, at least it is more dynamic.Further i believe
that will result in smaller trees, and speed up the search more
than your approach.

Hello Michael,

Your scheme differs from that of Bob and it is not what he wants.

In an all-node, Bob's scheme either stores the original tt-move or the first move done,ie the move with the highest original ordering. In your scheme, the move stored might be way down in the original ordering. Such a move, if first searched in a hash hit in a subsequent search, will not be searching a move with the highest ordering and it would be a bad move to try.

Rasjid.

yes, i try a move a move which might be way down in _original_ move ordering. But there is no argument (for now),
that is telling us, it would be worse (both moves failed lo, the first
and move-n with the higher fail-lo score)

At the end, if we have a real allNode, which is now and for all revisits
an allNode, we might store a move by random.That would not hurt.
But my opinion is, if we dont do it by random then we need a _formular_
to pick a (best)move.

bobs formular: (1)
first move given by moveselection code

my formular: (2)
the value with the highest fail-lo score.(btw the most unimportant
thing is not to have _any_ extra code as advantage)

why should (1) be better than (2) ?

Michael

[Desperado]

...

and there is another issue on Bobs implementation.
Normally the transValue and the transMove are corresponding.
I mean the upperBound Bob stores must not belong to the
move he stores. (i dont know if or how it matters, but imo the move
and the value stored, should belong together.So,it might be viewed
as bug, or not?).

[Antonio Torrecillas]

Hello,
Just to add other ideas...

For the defer move generation trick I store in the transposition table for ALL nodes the move with the bigger sub-tree (node count).

The idea is to save work in the most expensive sub-tree.

Regards, Antonio.

[Chan Rasjid]

...
and there is another issue on Bobs implementation.
Normally the transValue and the transMove are corresponding.
I mean the upperBound Bob stores must not belong to the
move he stores. (i dont know if or how it matters, but imo the move
and the value stored, should belong together.So,it might be viewed
as bug, or not?).

When I was is new to chess programing, alpha-beta and its interaction with transposition tables was tricky and would often cause me confusion. Now, after many years, it is better.

The correspondence between a tt-move and tt-score is correct and we cannot break it - except for all-nodes! In an all-node, we could even set the highest upper bound just to alpha and correspond it to any of the moves and it still is valid as a score (upper bound) for that move. This is also precisely why selecting moves by comparing fail-low scores (upper bounds) is not helpful. In practice we always store as tt-score the minimum upper bound; but the tt-move need not be the one returning this score.

You probably forget that in a revisit and search of an all-node, the first move tried before move generation might fail high or the move might be the pv move - not necessary again an all-node. So the stored-move must be the highest ordered move as it would be the first move searched. Your scheme would work if ordering by fail-low scores works - but most others see otherwise (I took some time to convince myself of it in the past).

My program stores as tt-move for an all-node the move with the highest node count - the same as Antonio's; but the reason might not be about savings associated with the largest subtree - it could be a move that could only be refuted after many nodes searched is likely to be a good move.

Rasjid

[michiguel]

Hello,
Just to add other ideas...

For the defer move generation trick I store in the transposition table for ALL nodes the move with the bigger sub-tree (node count).

The idea is to save work in the most expensive sub-tree.

Regards, Antonio.

I tried exactly that long time ago but unfortunately it did not work at all in Gaviota.

Miguel

[Antonio Torrecillas]

From the beginning, I thought that fit with the idea of iterative Deepening.
(If I choose the sub-tree that has been explored more I'll get the most out of the TT.)
But as a move ordering trick, this may conflict with other move order related systems... I've never got IID ...for example.

[Desperado]

hello Rasjid,

thx for your reply.

First for me the move and a value keeps a pair, which is intended
normally when we store the pair into TTable.
Because we _normally_ dont have a bestMove at an allNode,but
we try to store the move with the highest probability to be a bestMove,
my personal taste is to be conform, and to store the move from which
we retrieved the highest upperBound.
(of course we _can_ break this correspondence, but thats only a hack from my point of view)

Everything else here are assumptions based on what ?!
My assumption is based on the fact, that _not_ trying the _firstMove_
(which a moveselector reports) again as first one (forced) , when we revisit the node is better than doing so!.
And if i want that to do conform + free of costs + not by random , then
it ends up like i have implemented it.
Further it has a positiv effect on my search, which is a fact not an assumption. (and you can be sure
that my engine is not doing sth ground breaking different than all the other engines out there).

Well, of course i can error, but i am not a newbie, even it might look
like this in that case. (but compared to Bob am definitely )

Finally if Bob or anyone else tells me his approach is superior because of _testing_ i will believe.
(and the only content here is having a move available in the TTable for allNodes, not a complete moveselection scheme for allnodes)

best regards, Michael

ps: - it is not that easy for me to express myself very well in english (nor
in my first language sometimes). So i sometimes feel
misunderstood, and may repeat my contents to often, sorry for that.

[michiguel]

...
If I fail low at any node, this is stored in the hash table as a "UPPER" position and there is obviously no best move to store. In Crafty, as a search is carried out, I save the first move searched (which may be the hash move, or the first capture tried, or the first killer (if there is no hash or safe capture move) or just the first move generated in the worst case. When I discover that this is a "UPPER" position with no best move, I store the first move searched as the best move. Why? The next time I hit this position, I will search that move without a move generation, and without a best move that is the move I would end up searching first anyway, so why not?
...
However, this now means that _every_ hash hit will have a best move (the EXACT/LOWER positions obviously would, and now UPPER also).
...

i agree that having a move available will improve the search,
and results in positive elo gain.

i dont agree that is has to be the first move given by the moveselector.
(as we all know,which tries: tMove,captures ...)

i am prettey sure, that using the move with the highest fail-lo score
is the better choice, at least it is more dynamic.Further i believe
that will result in smaller trees, and speed up the search more
than your approach.

Hello Michael,

Your scheme differs from that of Bob and it is not what he wants.

In an all-node, Bob's scheme either stores the original tt-move or the first move done,ie the move with the highest original ordering. In your scheme, the move stored might be way down in the original ordering. Such a move, if first searched in a hash hit in a subsequent search, will not be searching a move with the highest ordering and it would be a bad move to try.

Rasjid.

yes, i try a move a move which might be way down in _original_ move ordering. But there is no argument (for now),
that is telling us, it would be worse (both moves failed lo, the first
and move-n with the higher fail-lo score)

At the end, if we have a real allNode, which is now and for all revisits
an allNode, we might store a move by random.That would not hurt.
But my opinion is, if we dont do it by random then we need a _formular_
to pick a (best)move.

bobs formular: (1)
first move given by moveselection code

my formular: (2)
the value with the highest fail-lo score.(btw the most unimportant
thing is not to have _any_ extra code as advantage)

why should (1) be better than (2) ?

Michael

Because 1 will contain the last move that have been successful when this position has been visited before. I think this explanation has been missed in this thread. If a move was successful to cut off before, then it was not, there is chance that it will be again. You do not need any trick to guarantee this move will be there. Bob's approach is enough.

2 won't work with fail hard schemes. Even with fail soft, in certain situations of pruning (futility etc.) the bounds might be safer for certain moves than others (i.e. a node that was pruned). So, the bounds could mean very little. This of course depends very much on the engine.

Miguel

[Desperado]

Because 1 will contain the last move that have been successful when this position has been visited before. I think this explanation has been missed in this thread. If a move was successful to cut off before, then it was not, there is chance that it will be again. You do not need any trick to guarantee this move will be there. Bob's approach is enough.

2 won't work with fail hard schemes. Even with fail soft, in certain situations of pruning (futility etc.) the bounds might be safer for certain moves than others (i.e. a node that was pruned). So, the bounds could mean very little. This of course depends very much on the engine.

Miguel

That is a real good argument. But the rare case. Normally we wont have
have previous _real_ bestMove stored. Probably we have none, or the first one picked from msel, which failed lo.
In such a case it would be senseful to keep the _real_ bestMove instead of overwriting it.

Hm, ok arguing to decide for a move because of its better fail-lo score is not my intention anymore.
I just want the move that belongs to the value the search is working with.(that implicates to choose the move with the highest upperBound).
And for some reasons that works pretty well. And is definitely better than having an empty slot for the move in the TTable.

Michael