Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: I do not understand why faster hardware is better

Author: Derek Paquette

Date: 06:29:07 11/16/03

Go up one level in this thread


On November 16, 2003 at 02:21:32, Uri Blass wrote:

>On November 16, 2003 at 01:29:52, Timothy J. Frohlick wrote:
>
>>To get to 14 ply with 11 to 12 good moves per ply would require a million
>>billion choices to be searched.
>
>11 to 12 good moves per ply is only your imagination.
>
>alphabeta means that the program usually searches only 1 option in the even or
>the odd plies.
>
>Even the branching factor of tscp is smaller than 11 and I think that it is 7
>and having better order of moves including using hash tables should help
>significantly.
>
>
> There are only 86,400 seconds in a day. Full
>>exhaustive searches to 14 ply could not be done on todays PCs.
>
>Wrong.
>I believe that branching factor of 5 is possible to achieve even without
>pruning(suppose even that only 6 is possible)
>6^14<10^11
>
>if you search 10^9 nodes per second you can get 14 plies brute force in 100
>seconds(not that I think that it is good strategy).
>
>
> Only 31 moves
>>could be made in one year if a machine were searching at billion positions/sec.
>
>I do not understand it.
>
>>
>>Selective search which involves massive pruning of the search tree chooses only
>>three to five best first moves and examines the best responses again
>>selectively. Much less computer power is needed.
>>
>>Most GMs select the one best move depending on their analysis of the board
>>position and their memory of similar/same positions. The one best move approach
>>also depends on the attacking plans of the GM.
>
>No
>
>GM's look at more than one move and at more than one line when they analyze.
>
>>
>>The program that the article dreams about is not similar to today's PC programs.
>>It does not filter most of the choices in the search tree.
>>
>>TJF
>
>I do not know about which article you are talking.
>The poster said that there is an article and did not give a link and I am too
>lazy to search for it.
>
>>
>>
>>On November 15, 2003 at 23:47:04, Derek Paquette wrote:
>>
>>>This is a very ignorant question coming from me,
>>>but I'd love to hear the answers, it is bugging me.
>>>
>>>Ok, hypothetical question, Deep Junior 8 is playing against kasparov...
>>>it is a difficult board position, around 7 ply the computer should be coming
>>>across the correct move, there is only 1 correct move to play without a lose
>>>along the road...
>>>now if DJ8 is filtering at 99.99999% of the moves,
>>>why would it matter if it had quad 2.8ghz chips, or even 8 chips...
>>>if its not seeing the move, why would it at 22ply suddenly see it?
>
>Why not?
>There are moves that you need many plies to see them.
>
>
>>>
>>>on the x3d site there is an excellent article, and it says, a definate way to
>>>beat a super grandmaster is to build a machine running at 1 billion positions a
>>>second, and have it search to only 14ply, making thoroughness over filtering and
>>>deep looking a priority...
>>>so can someone explain to me why faster hardware makes a difference, if even my
>>>home pc can look at ply 18 with deep junior...
>
>When Junior says depth 18 it does not mean 18 plies.
>
>9-36 plies dependent on the line is more accurate.
>
>Uri


If the machine is filtering so much,  what does extra hardware do for it neway
if its just not going to see the position?  Why after 5 minutes would it see the
right position that it should see after say 7 ply, when in 30 seconds it
couldn't...it already left that move possibility in the dust...
that is my question,
I see it all the time,  after 13 minutes a program finds such and such a
move...but the actual move was only 7ply deep..but it took 45 minutes to find
it.
etc.

I don't understand...does a computer keep looking back and going through
different moves from the start if it doesn't find anything positive??



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.