Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: no more comments???

Author: Uri Blass

Date: 19:34:46 07/25/02

Go up one level in this thread


On July 25, 2002 at 18:01:49, Robert Hyatt wrote:

>On July 25, 2002 at 13:59:31, Uri Blass wrote:
>
>>On July 25, 2002 at 13:09:31, Robert Hyatt wrote:
>>
>>>On July 25, 2002 at 12:10:35, Uri Blass wrote:
>>>
>>>>On July 25, 2002 at 11:29:37, Robert Hyatt wrote:
>>>>
>>>>>On July 25, 2002 at 01:32:52, Uri Blass wrote:
>>>>>
>>>>>>On July 24, 2002 at 21:54:12, Robert Hyatt wrote:
>>>>>>
>>>>>>>On July 24, 2002 at 13:13:11, Gian-Carlo Pascutto wrote:
>>>>>>>
>>>>>>>>On July 23, 2002 at 12:08:43, Uri Blass wrote:
>>>>>>>>
>>>>>>>>>I still do not use hash tables to save generating moves and it is another gain
>>>>>>>>>that I can get from hash tables.
>>>>>>>>
>>>>>>>>That gain is very small - I still don't do it either.
>>>>>>>>
>>>>>>>>--
>>>>>>>>GCP
>>>>>>>
>>>>>>>
>>>>>>>I think for me it was about 10%.  Not huge.  Not ignorable either.  if you
>>>>>>>count the number of times the hash move causes a fail high, that is the number
>>>>>>>of move generations you will totally avoid...  It may or may not be a lot
>>>>>>>depending on other factors...
>>>>>>
>>>>>>No
>>>>>>
>>>>>>It is not the number of move generations to avoid for me.
>>>>>>You should multiply it by the number of legal moves because
>>>>>>I generate them before looking at the hash tables.
>>>>>
>>>>>
>>>>>
>>>>>I think you misunderstand.
>>>>>
>>>>>At a ply in the tree, at the top of search, you should be doing this:
>>>>>
>>>>>1.  hash probe.
>>>>>2.  generate captures.
>>>>>3.  try them one at a time.
>>>>>4.  generate non-captures
>>>>>5.  try them one at a time.
>>>>
>>>>I think that it should be:
>>>>
>>>>1.hash proble
>>>>2.generate killers.
>>>
>>>I don't see why you need to "generate" these.  You already have the
>>>moves in the  killer list, you simply have to validate the move to be
>>>sure it is legal in the current position...
>>
>>I need to generate a new function to validate if
>>a move is legal(I have a function to check
>>if the opponent move is legal but the way that I do it
>>is by generating all the list of the legal moves and
>>checking if the move is in the list).
>>
>>I called it generating the move but you are right that
>>I do not need to put it in the move stack
>>so practically after finding that it is legal.
>>>
>>>
>>>>3.try them one at a time.
>>>>4.gnerate captures(only good captures or promotions).
>>>>5.try them one at a time.
>>>>6.generate non-captures
>>>>7.try them one at a time.
>>>>
>>>>
>>>>For step 1 I need to change the data that is in the hash tables and add the
>>>>number of legal moves because this number is
>>>>used in part of the cases to decde about extensions.
>>>>
>>>>I understand that at least for step 2,4,6
>>>>I need to write some new functions.
>>>>
>>>>Function 1:check if the killer is legal,generate it
>>>>and count the number of legal moves
>>>>(unless the number is in the hash tables or
>>>>the killer is illegal).
>>>
>>>Where are you doing the "legal move count"?  I assumed it was in your
>>>move generator, which would be called at the _next_ ply after making a
>>>killer at this ply...
>>
>>It is today in my move generator
>>but I use it to decide if to extend or not to extend
>>
>>I have some rule that tells me to extend if the number
>>of legal moves is small and some other conditions
>>happen so
>>I need to know the number of legal moves before
>>making another move.
>>
>>Uri
>
>So you are "out of sync" here?  IE you make a move, and update the legal
>move count for your opponent immediately so that you know whether to extend
>here or not?

Yes

Today I do not use it for partial extensions in most of the cases
and I use it for a decision about partial extensions only when
I have more reasons to extend or there is a single reply
but it may be changed in the future.

I believe that the simplest way to do the same thing faster is
only to count the number of moves without generating them because
counting the number of moves should be clearly faster than generating
and remembering them.

A more simple change before having a function to count them is simply to
remember the number of moves in the hash tables.

>
>That is a bit like my old incremental move generation.  I would make a move
>and update everything so that generating moves was always trivial.  The problem
>is that you make a move, update the stuff, then get a hash hit and don't
>use the updated info at all.  I gave up on that and decided to just update
>exactly when it is needed...

Yes I update a lot of information in my makemove function but inspite of it
Movei use more time for generating moves and not for making moves
and in the last time that I checked it used most of it's time to generate moves.

Part of the reason is that my qsearch has no generate capture functions.
Movei generates all the legal moves in the qsearch and pick
the important moves that includes checks in the first plies
of the qsearch and only captures later but I do not think that
it is the only problem because movei did not use a lot of time
in the qsearch before adding checks to the qsearch(only about 20%)
and adding checks to the qsearch made it slightly better
in test suites and probably also better in games.

Again I can avoid generating all the moves in the qsearch
but I cannot avoid counting them if I want to have the same program because
I use the number of the legal moves for the evaluation.

Uri



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.