[rc5] v3

JP Rosevear webmaster at usjc.uwaterloo.ca
Mon Oct 27 13:21:07 EST 1997


>Sebastian Kuzminsky wrote:
>]    There is a tradeoff between having the clients go deep into their own
>] little branch of the search tree and having them go shallow.  If the
>] clients go deep and only return, say, the best 25 positions three ply
>] ahead, then the intermediate search (all the other 27000 positions
>] examined) are lost.  If there was a long-term payoff sacrifice in one of
>] the non-returned branches, we'll never find it.  On the other hand, we
>] cant return all 27000 positions, becuase the network would choke.  (Hm,
>] or we could all go buy fiber connections to the backbone.
>
>
>JP Rosevear wrote:
>] Your right, there is a serious IO problem.  I'm not sure this is the right
>] way to approach it though.  A computer like Deep Blue wouldn't lose those
>] branches, and hence we're at a disadvantage.
>
>
>   I cant think of any other way to do it.  Either the clients tell the
>server what they have found, or they dont.  The distributed.net computer
>doesnt have the internal bandwidth to support communication of the
>magnitude required for sending back all the branches.  There has to be
>imperfect, premature client-side pruning.  (I'm no computer chess
>expert, and i'd love to be proven wrong here.)

It would be an interesting experiment to see experimentally how many
different positions current chess engines have for consideration at the end
of x number of ply after alpha-beta pruning.  I admit I am no expert either
(just a strong interest), but this would give an idea of how serious the
I/O problem is.  In addition it make give us a target for ply before
returning.  ie If 10 ply returns 1000 positions and 12 ply 100 000 then we
stop a 10 ply say.

>   I dont know how serious this I/O disadvantage is.  The more i think
>about it the worse it seems...
Ditto.  However it is a worthwile topic of discussion since there are many
large processing problems that might have similar I/O problems, plus no
discussion and generation of ideas equals no solution... ever.
Just think you could be the man! (Could be a thesis in there! :-)


>JP Rosevear wrote:
>] Perhaps another project that could be considered would be the continuation
>] of the table base classes generated by Ken Thompson.  We could probably
>] knock out 6 and 7 man classes in very short order.
>
>
>   These projects are similar enough that if we do one, we get the other
>almost for free.
However the tablebase project would not have to operate in real time, and
hence requires the same amount of I/O but not the same rate.

Not too many new ideas this time - sorry (just a lot of nay saying).

-JP

==============================================================================
JP Rosevear
Webmaster & Systems Developer
University of St. Jerome's College
Waterloo, ON, N2L 3G3   	    	http://www.usjc.uwaterloo.ca
(519) 884 8111 x234			mailto:webmaster at usjc.uwaterloo.ca


----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list