Reply
 
LinkBack Thread Tools Display Modes
  #1   Report Post  
Old April 14th 04, 10:35 PM
Filipe Maia
 
Posts: n/a
Default Hashing fail lows

Do people usually add the fail low positions to the transposition table?
I'm only adding the fail highs and the ones between alpha and beta. I also
don't add nothing from quiescent search and null move.

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
  #2   Report Post  
Old April 15th 04, 02:46 AM
Robert Hyatt
 
Posts: n/a
Default Hashing fail lows

Filipe Maia wrote:
Do people usually add the fail low positions to the transposition table?
I'm only adding the fail highs and the ones between alpha and beta. I also
don't add nothing from quiescent search and null move.


You should add _everything_. A fail low hit saves just as much work as
a fail high position...



--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
  #3   Report Post  
Old April 15th 04, 09:13 AM
Mikko Nummelin
 
Posts: n/a
Default Hashing fail lows

On Wed, 14 Apr 2004, Filipe Maia wrote:

Do people usually add the fail low positions to the transposition
table? I'm only adding the fail highs and the ones between alpha and
beta. I also don't add nothing from quiescent search and null move.


It is advisable to hash also fail lows as it indicates that value in that
position is at most alpha. This allows fixing the upper bound or making a
cut-off when coming again to that position with certain alpha-beta range.

It should, however, be noted that in case of fail low there is no
'recommendable' move to add into that hash table entry.


Mikko Nummelin
  #4   Report Post  
Old April 15th 04, 09:15 AM
Mikko Nummelin
 
Posts: n/a
Default Hashing fail lows

On Thu, 15 Apr 2004, Robert Hyatt wrote:

Filipe Maia wrote:


Do people usually add the fail low positions to the transposition
table? I'm only adding the fail highs and the ones between alpha and
beta. I also don't add nothing from quiescent search and null move.


You should add _everything_. A fail low hit saves just as much work as
a fail high position...


But adding results based solely on quiescence search may lead to errors if
those values are added to same hash table as 'full-width'-values.


Mikko Nummelin
  #5   Report Post  
Old April 15th 04, 10:50 AM
Tord Kallqvist Romstad
 
Posts: n/a
Default Hashing fail lows

Mikko Nummelin writes:

On Thu, 15 Apr 2004, Robert Hyatt wrote:

Filipe Maia wrote:


Do people usually add the fail low positions to the transposition
table? I'm only adding the fail highs and the ones between alpha and
beta. I also don't add nothing from quiescent search and null move.


You should add _everything_. A fail low hit saves just as much work as
a fail high position...


But adding results based solely on quiescence search may lead to errors if
those values are added to same hash table as 'full-width'-values.


Why? I have always used the same hash table for the main search and
the quiescence search, and I have never seen any problems at all.

--
Tord Romstad


  #6   Report Post  
Old April 15th 04, 01:39 PM
Mikko Nummelin
 
Posts: n/a
Default Hashing fail lows

On Thu, 15 Apr 2004, Tord Kallqvist Romstad wrote:

Why? I have always used the same hash table for the main search and
the quiescence search, and I have never seen any problems at all.


Well, of course this depends on the reliability consideration. If in the
hashtable there is for example:

position N
Best move: Ba1
2.4 pawns lower bound based on 2 plies

and you arrive into position N again but have still 3 plies to search full
width, you don't make cutoffs based on this node, but instead:

- Try anyway Ba1 first.

- Update the node after the 3 plies search of this position is complete.

This means that quiescence search nodes may be considered as 0 ply nodes
so that they are not used for cutting off, but just to hint a
probable best move (of course to be updated if more reliable results are
found for that position).


Mikko Nummelin
  #7   Report Post  
Old April 15th 04, 01:55 PM
Robert Hyatt
 
Posts: n/a
Default Hashing fail lows

Mikko Nummelin wrote:
On Thu, 15 Apr 2004, Robert Hyatt wrote:


Filipe Maia wrote:


Do people usually add the fail low positions to the transposition
table? I'm only adding the fail highs and the ones between alpha and
beta. I also don't add nothing from quiescent search and null move.


You should add _everything_. A fail low hit saves just as much work as
a fail high position...


But adding results based solely on quiescence search may lead to errors if
those values are added to same hash table as 'full-width'-values.



Mikko Nummelin


that is why you store a "draft" with a position. Then that can not
possibly happen.


--
Robert M. Hyatt, Ph.D. Computer and Information Sciences
University of Alabama at Birmingham
(205) 934-2213 136A Campbell Hall
(205) 934-5473 FAX Birmingham, AL 35294-1170
  #8   Report Post  
Old April 15th 04, 02:28 PM
Tord Kallqvist Romstad
 
Posts: n/a
Default Hashing fail lows

Mikko Nummelin writes:

On Thu, 15 Apr 2004, Tord Kallqvist Romstad wrote:

Why? I have always used the same hash table for the main search and
the quiescence search, and I have never seen any problems at all.


Well, of course this depends on the reliability consideration. If in the
hashtable there is for example:

position N
Best move: Ba1
2.4 pawns lower bound based on 2 plies

and you arrive into position N again but have still 3 plies to search full
width, you don't make cutoffs based on this node, but instead:

- Try anyway Ba1 first.

- Update the node after the 3 plies search of this position is
complete.


This is all true, but I don't see how the qsearch is different from
the main search in this respect. You never allow hash table cutoffs
when the remaining depth is bigger than the depth stored in the hash
entry, neither in the main search nor in the qsearch. The logic is
exactly the same in both functions.

This means that quiescence search nodes may be considered as 0 ply nodes
so that they are not used for cutting off, but just to hint a
probable best move (of course to be updated if more reliable results are
found for that position).


No, this information can also be used for cutoffs. As always, a
necessary condition is that the remaining depth is less than or equal
to the depth in the hash entry. Unless you have a very exotic
qsearch, there is no reason why you would need to do hash table
cutoffs differently in the qsearch compared to the main search. I use
exactly the same code and the same hash table both places.

--
Tord Romstad
Reply
Thread Tools
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fail Soft Alpha Beta & Transpositions Orhan Öztürk rec.games.chess.computer (Computer Chess) 4 September 10th 03 04:58 PM
(Fail soft) alpha beta Delphi rec.games.chess.computer (Computer Chess) 7 September 7th 03 03:00 PM


All times are GMT +1. The time now is 01:29 AM.

Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright ©2004-2019 ChessBanter.
The comments are property of their posters.
 

About Us

"It's about Chess"

 

Copyright © 2017