Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: developing Junior (and other pro programs)

Author: Robert Hyatt

Date: 10:27:26 09/02/02

Go up one level in this thread


On September 01, 2002 at 10:20:08, Uri Blass wrote:

>On September 01, 2002 at 09:42:46, Vincent Diepeveen wrote:
>
>>On September 01, 2002 at 02:52:13, Uri Blass wrote:
>>
>>>On August 31, 2002 at 21:11:43, Vincent Diepeveen wrote:
>>>
>>>>On August 31, 2002 at 04:00:57, Uri Blass wrote:
>>>>
>>>>>On August 31, 2002 at 03:26:01, Dave Gomboc wrote:
>>>>>
>>>>>>>This is exactly the case for Junior and Fritz and they simply do not care about
>>>>>>>small improvement that they can get.
>>>>>>
>>>>>>That, I don't believe.
>>>>>>
>>>>>>>They know that there are positions when the program cannot see simple tactics
>>>>>>>but they do not care to fix it.
>>>>>>>
>>>>>>>There are positions when Junior cannot see simple tactics and Amir ban knows
>>>>>>>about it but he did not fix it at least not in Junior7(some years after he got
>>>>>>>the information).
>>>>>>
>>>>>>That's probably because it would hurt the program overall.  I'm sure he does
>>>>>>what he thinks is best for overall program strength.
>>>>>
>>>>>I believe that the reason for Junior is that it is not
>>>>>easy to fix it and be sure that you do not generate
>>>>>other bugs but I do not think that it is impossible
>>>>>to do it.
>>>>>
>>>>>I believe that in most cases
>>>>>professional do not work harder than the amaturs.
>>>>
>>>>they will be happy with such statements...
>>>>
>>>>Most obviously won't be able to answer that because they don't like
>>>>to work and prefer to stay on the beach instead :)
>>>>
>>>>>>
>>>>>>>There are positions when Fritz cannot see simple mate because of null move
>>>>>>>pruning.
>>>>>>
>>>>>>I'm sure Frans Morsch is well aware of that too.
>>>>>
>>>>>Yes but he does nothing to fix it and it does more mistakes than other programs
>>>>>because of null move pruning.
>>>>>I see no reason to use null move pruning after the first
>>>>>move of the pv but this is exactly what Fritz does.
>>>>>
>>>>>I already posted the analysis when Fritz finds the right move Nc6
>>>>>that is winning(white is in zunzwang) but the score
>>>>>drop every iteration because it does not want to analyze a move that threats
>>>>>nothing.
>>>>>
>>>>>Here is the relevant position again
>>>>>
>>>>>[D]1n6/1P6/8/2P5/p3kp1p/6p1/1P4K1/4N3 b - - 0 1
>>>>
>>>>>This position can happen in games
>>>>>
>>>>>Deep Fritz(black) played against Junior7(White).
>>>>>
>>>>>Junior7 already saw a score of 11.40 against itself when it played 54.c5 but
>>>>>Deep fritz blundered because of pruning the line that it wanted to play.
>>>>
>>>>any fritz7 comments instead of only the completely outdated deepfritz?
>>>>of course i tried fritz7 and it also fails miserably.
>>>>
>>>>Obviously you need to use nullmove first move after pv always
>>>>when you don't use alphabeta, but MTD instead.
>>>
>>>I believe that even with MTD the first ply of the pv is correct and in this
>>>example the zugzwang happens after the first ply of the pv(Nc6)
>>>
>>>Uri
>>
>>Please imagine what MTD is doing. Now suppose you want to quickly skip
>>to next ply (which in itself is great to solve testsets).
>>
>>So all you do is get a bound. Then you nullmove after the first move
>>*directly*.
>>
>>Do you understand why?
>>
>>Best Regards,
>>Vincent
>
>No
>I do not know much about MTD but I know that you cannot get a correct pv with
>MTD(constructing it from hash tables may give wrong results) so I do not like
>it.
>
>I have ideas to use the pv for better extensions rules(I do not do it today in
>movei) and if I do not know the right pv then I cannot do it.
>
>I know that the first move in the pv is always correct even with MTD.
>Not getting an exact score at least in the first iterations seems to me a wrong
>decision.
>
>I can understand not getting an exact score in the last iteration
>if you have a fail low and you are not interested in the exact score and you are
>afraid that you will not have enough time to get a better move if you try to get
>an exact score.
>
>Uri


There are tricks that work.  I "think" Brian Richardson came up with one that
will work.  Since you search the next to last time with the bound X and X+1,
and assuming you fail high, you search the last time with X+1 and X+2 as the
bounds and fail low, you can pick out the PV based on matching the previous
search's results.  IE the same PV that produced the next-to-last-search
fail high _must_ be the same PV that produces the last-search fail low...  And
you can grab that pretty easily...

But it doesn't matter.  There are _plenty_ of examples of mtd(f) working just
fine, regardless of what Vincent thinks.  Again, he spends too much time
dreaming up "why" something can't work, rather than trying to dream up solutions
so that it can work.  From experience, mtd(f) isn't a one-week thing to try and
discard when it doesn't work very well.  It is just like bitboards.  It takes
a lot of time to discover all the quirks and "get it right".  Those that jump
to quick conclusions aren't going to do very well.  It requires changes to the
hash table code and things such as lazy evaluation.



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.