Usually one stores the search-depth in de TT-depth field.
I was curious if an alternative would work.
Did not want to change the structure too much.
So I tried storing the number of nodes searched in a subtree; the log2() of it that is.
The result is -117 elo.
Maybe this inspires someone.
TT: depth field
Moderator: Ras
-
- Posts: 558
- Joined: Tue Jul 03, 2018 10:19 am
- Full name: Folkert van Heusden
-
- Posts: 1955
- Joined: Tue Apr 19, 2016 6:08 am
- Location: U.S.A
- Full name: Andrew Grant
Re: TT: depth field
Probably can't work, because node count may be more of a marker of how wide, or how wrong the [alpha, beta] window was, than the actual depth of the search. Interesting nonetheless.
-
- Posts: 558
- Joined: Tue Jul 03, 2018 10:19 am
- Full name: Folkert van Heusden
Re: TT: depth field
That was exactly my goal: as an indication of how "thorough the search of that subtree" was.AndrewGrant wrote: ↑Thu Mar 30, 2023 10:57 am Probably can't work, because node count may be more of a marker of how wide, or how wrong the [alpha, beta] window was, than the actual depth of the search. Interesting nonetheless.
-
- Posts: 465
- Joined: Fri Dec 16, 2016 11:04 am
- Location: France
- Full name: Richard Delorme
Re: TT: depth field
I did that in my Othello program Edax. It helped to reduce the size of the searched tree. I built a draft from the age of the search, its cost (log2(node count)), the selectivity level and the depth, to choose which entry to replace.
Richard Delorme
-
- Posts: 1273
- Joined: Wed Mar 08, 2006 8:28 pm
- Location: Florida, USA
Re: TT: depth field
I've thought about adding this type of approach. However, in a Lazy SMP environment there could be a quick cutoff due to another thread, which invalidates the whole approach.
— Steve
— Steve
http://www.chessprogramming.net - Juggernaut & Maverick Chess Engine