Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Using just Upperbounds and Lowerbounds

Author: Tony Werten

Date: 17:43:13 02/03/01

Go up one level in this thread


On February 03, 2001 at 18:33:28, Robert Hyatt wrote:

>On February 03, 2001 at 05:53:20, Tony Werten wrote:
>
>>On February 02, 2001 at 21:33:10, Robert Hyatt wrote:
>>
>>>On February 02, 2001 at 14:42:23, Alvaro Jose Povoa Cardoso wrote:
>>>
>>>>On February 01, 2001 at 18:37:48, Robert Hyatt wrote:
>>>>
>>>>>On February 01, 2001 at 16:27:29, Tony Werten wrote:
>>>>>
>>>>>>On February 01, 2001 at 14:19:25, Alvaro Jose Povoa Cardoso wrote:
>>>>>>
>>>>>>>Does any one tried to use just Upperbounds and Lowerbounds in hashing, ignoring
>>>>>>>ExactScore entries?
>>>>>>>My question has to do with the fact that if we use ExactScores we don´t get long
>>>>>>>PVs to feed in the next iteration, even if we extend PVs from hash.
>>>>>>>My testing shows that if we do not use ExactScore entries in the hash table, we
>>>>>>>end up with very long PVs that can be fed into the next iteration in order to
>>>>>>>aproximate the minimal tree. After all, ExactScores are rare compared to
>>>>>>>Upperbounds and Lowerbounds.
>>>>>>>
>>>>>>>Can someone comment on this?
>>>>>>
>>>>>>One of us is missing something. The PV is always exact. If you don't store
>>>>>>exact, you don't have a pv. I don't know what you get from the hashtable, but it
>>>>>>isn't a PV.
>>>>>>
>>>>>>I take my PV from hashtable and I (almost) always get a long pv, at least as
>>>>>>long as the search depth.
>>>>>>
>>>>>>Tony
>>>>>>
>>>>>>>
>>>>>>>Thank you
>>>>>>>Alvaro Cardoso
>>>>>
>>>>>
>>>>>He is talking (I think) about a PV that is cut short when you get an EXACT
>>>>>hash hit.  IE in crafty, where a PV ends with <HT> which sometimes happens
>>>>>at ply=2/3/4 and results in a very short PV.  I use internal iterative deepening
>>>>>to help search around this the next iteration, however..
>>>>
>>>>
>>>>That is exactly what I was talking about. When I get an EXACT hash hit the PV is
>>>>cut short, and extending it from the hash table doesn't help much, I just get
>>>>1-3 moves from the hash, perhaps there is something wrong with my program.
>>>>Also, and in response to Dr. Robert Hyatt, I can´t execute the assignment
>>>>because my program is the portuguese version of checkers. I hope you don't mind
>>>>if I ask questions not related to the game of chess.
>>>>
>>>>Thank you
>>>>Alvaro Cardoso
>>>
>>>That is a perfectly normal problem.  My PV is often shorter than it should
>>>be due to an EXACT hash hit.  Nothing you can do about it, not that there
>>>is anything wrong with it.
>>
>>I still don't get how you can have a short pv if you have a exact hashhit.
>>
>>Maybe run a test where you add in your pv, the bounds it got. My guess is you're
>>last move is a BELOW_ALFA hit. ( That was a problem I had before )
>>It was caused because I raised alfa after nullmove, sometimes making it the best
>>score and having a bogus best_move which couldn't be found in hashtable.
>>
>>cheers,
>>
>>Tony
>
>It happens all the time.  You get an EXACT hash hit while searching the PV,
>so you stop and use that score instantly.  How can you fill in the _rest_ of
>the PV moves since you didn't search any deeper.  I see this so often that I
>eventually added the <HT> indicator to the PV to let everyone know it really
>should be longer but was cut short by an EXACT hash hit.
>
>If you never get a short PV, you have something broken somewhere..

But if you get a <HT> you must have searched it the previous ply, so it's still
in your tables ? Or  you've searched it this ply and you should not have
overwritten it. ( or you have something broken somewhere .. )

Tony

PS very strange strange that if you don't get an error you must have something
broken.

>
>
>
>>
>>>
>>>And you can _still_ turn in your assignment on time.  Checkers is perfectly fine
>>>to test your hypothesis. :)



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.