Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Movei - Genius 2 : 1-6 with 1 draw

Author: Christophe Theron

Date: 06:37:53 10/29/03

Go up one level in this thread


On October 29, 2003 at 04:29:38, José Carlos wrote:

>On October 27, 2003 at 23:16:51, Christophe Theron wrote:
>
>>On October 26, 2003 at 13:28:02, Uri Blass wrote:
>>
>>>On October 26, 2003 at 13:11:26, Christophe Theron wrote:
>>>
>>>>On October 26, 2003 at 12:12:33, Uri Blass wrote:
>>>>
>>>>>On October 26, 2003 at 11:10:14, Peter Berger wrote:
>>>>>
>>>>>>Maybe I should have posted this in WinBoard forum, but the diagram feature is so
>>>>>>much nicer here :)
>>>>>>
>>>>>>This is the first match in (planned at least ;) ) a little series between modern
>>>>>>middle-class amateur engines and old professionals.
>>>>>>
>>>>>>Genius 2 played on a PIV2.2GHz, 32MB Hash, tournament.bok used.
>>>>>>Movei (17.10.03) played on a PIV1.8GHz, 16MB Hash. It used the book of the
>>>>>>public version and the s parameter.
>>>>>
>>>>>How much hardware advantage does it give for Genius?
>>>>>
>>>>>can you compare nodes per seconds for Genius and movei?
>>>>>
>>>>>>
>>>>>>Time control was game in half an hour.
>>>>>>
>>>>>>It was a surprisingly one-sided match where Movei was without any real chances.
>>>>>
>>>>>From looking at few game it seems that movei had chances but blundered.
>>>>>
>>>>>In game 1 movei could draw by tablebases
>>>>>but blundered with 42...Kf6(it did not know that KQ vs KP is a draw when the
>>>>>pawn is in the 7th and when it played 42...Kf6 it could not search deep enough
>>>>>to see the promotion of white).
>>>>>
>>>>>In game 2 movei also blundered in an endgame that is not clear(Fritz8 says that
>>>>>white is better before 39.Ne5 but movei needs too much time to avoid that move).
>>>>>
>>>>>Movei could play 39.Re7 h3 40.Re2 Rg2 41.Re1 f6 42.gxf6 gxf6 43.Rh1 h2 44.Nd4
>>>>>
>>>>>and yace could learn from that line almost a draw score for white.
>>>>>
>>>>>I still did not look at the rest of the games but from the positions that you
>>>>>posted in game 7 and 8 it is clear that movei also had chances in these games
>>>>>and maybe time control of x minutes/y moves could be better for it but I need to
>>>>>check if it can avoid the mistakes in case of searching one ply deeper.
>>>>>
>>>>>>
>>>>>>A few comments:
>>>>>>
>>>>>>Genius 2 was the first chessprogram I bought. At this time I had a mighty
>>>>>>386SX20, and its play impressed me much, kind of a first love.
>>>>>>I just loved its passive and accurate play, and the endgame looked very strong
>>>>>>to me.
>>>>>>
>>>>>>a.) While later Genius version were stronger in the past I am not sure if this
>>>>>>will also turn out to be the truth on current hardware.
>>>>>>The branching factor of Genius 2 looks much better than what I am used to with
>>>>>>later versions (untested impression). It was only mildly outsearched by
>>>>>>movei (1-2 ply), in the endgame it actually searched deeper than its opponent
>>>>>>most of the time.
>>>>>>
>>>>>>b.) Movei suffered some in the opening. The opening book used  for it wasn't too
>>>>>>impressive. Still its one victory was clearly a book win in fact :), when Genius
>>>>>>couldn't find the right moves in time to justify the good opening line it had
>>>>>>chosen ( Round 6).
>>>>>>
>>>>>>c.) Movei's time management is unconventional. While it plays a little too fast
>>>>>>in general, it doesn't seem to have an upper limit (or it is very high) for the
>>>>>>time to finish a ply.
>>>>>
>>>>>The upper limit is half of the time that it has in the clock to finish the game
>>>>>or the time control.
>>>>>
>>>>>>This made it think on 14. O-O in game 6 for _several_ minutes for example,
>>>>>>because it was so eager to finish ply 12. Maybe this could be improved.
>>>>>
>>>>>I learned this from Amir Ban who said that it is a bad idea to finish search in
>>>>>the middle of the iteration.
>>>>>
>>>>>Uri
>>>>
>>>>
>>>>
>>>>I don't agree with Amir here.
>>>>
>>>>I think it is important to finish the first move of the iteration you have
>>>>started, so at least you know if there is something wrong about this move.
>>>>
>>>>If it is the case (the score drops significantly from the previous iteration),
>>>>extend the time. Let it search very long if needed, so it either finds a better
>>>>move or finishes the iteration.
>>>>
>>>>If the score of the first move is better or does not drop much (from the
>>>>previous iteration) and you have exceeded your target time, stop the search and
>>>>play that move.
>>>>
>>>>
>>>>
>>>>    Christophe
>>>
>>>You may be right but I am not sure about it.
>>>
>>>I agree that it is more important to finish the iteration when the score drops
>>>(after fail low) relative to the case when the score does not drop much
>>>but  I still believe that there is an advantage in finishing at the end of the
>>>iteration.
>>>
>>>The point is that I am not sure if it is a good idea to waste time to search the
>>>first move when in most cases the score does not drop significantly only to find
>>>a case when the scores drops significantly.
>>>
>>>
>>>Maybe I should have a combination of both methods.
>>>The idea is that I may decide to stop to search if I finish the iteration in
>>>more than 20 seconds and also stop to search in case that the score did not drop
>>>and I already used more than 50 seconds.
>>>
>>>Uri
>>
>>
>>
>>Yes I also do something like that. I have a "target time", and I compare the
>>time used so far and the target time to decide.
>>
>>Anyway, don't expect much elo gain from time management improvement.
>[...]
>>So they will give it a big importance, but in reality the elo gain to expect is
>>miserable.
>
>  You've been repeating over and over here that Tiger results with increment
>time controls are not valid because Tiger's time manegement was wrong.
>  After all, it seems they weren't valid, by a miserable margin.
>
>  José C.



What I mean is that as long as your time management allows your program to use
most of the time that has been allocated to it, you won't find any dramatic
improvement over the simple method of allocating for each move the total time
left divided by the number of moves left to the next time control (or a rough
estimate of the number of moves left to the end of the game if you are in a
sudden death time control).

A nice improvement over the simple method is to let the program use an extended
amount of time in case of a fail-low (panic time).

In the case of Fisher time controls in Tiger, the problem is different. Tiger,
when using Fisher time controls, will use only a fraction of the total time
allocated to it. It gets worse as the increment time goes up.



    Christophe



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.