Author: Vincent Diepeveen
Date: 11:40:37 10/18/02
Go up one level in this thread
On October 17, 2002 at 22:14:19, Jeremiah Penery wrote: ICCA journal june 1997 has analysis from Yasser Seirawan. Not exactly a weak player. Of course he was paid by IBM to sound positive, but his analysis reveal major comments on deep blue. All moves he gives a ? or a ?! or ?? you should avoid. Of course ?? are direct losing material. both kasparov as well as deep blue hardly played them. they too strong to do just that. Only kramnik did a few ?? moves this match :) We can of course point down some moves too where kasparov missed clear wins. Seirawan is explaining kasparov in the article as if kasparov is a small child who acts like one too :) Kasparov will be furious if he ever sees the comments given by Seirawan. However on average like 4 to 5 bad moves a game is really *horrible*. World top GMs usually make 1 or 2 such moves a game. If they do 2 they are already not world top 50 in advance. >On October 17, 2002 at 13:26:54, Vincent Diepeveen wrote: > >>On October 17, 2002 at 11:34:35, Uri Blass wrote: >> >>>On October 17, 2002 at 10:41:20, Robert Hyatt wrote: >>> >>>>On October 17, 2002 at 06:13:26, Johan Melin wrote: >>>> >>>>>On October 16, 2002 at 23:35:10, Robert Hyatt wrote: >>>>> >>>>>>On October 15, 2002 at 14:01:35, Johan Melin wrote: >>>>>> >>>>>>>On October 14, 2002 at 07:34:16, Bas Hamstra wrote: >>>>>>> >>>>>>>>Bob, did you read the Hsu transcript posted here? It is pretty clear to me that >>>>>>>>Hsu himself says 12 ply fullwidth *total*. Case closed. Please read the complete >>>>>>>>transcript. >>>>>>>> >>>>>>>>Best regards, >>>>>>>>Bas. >>>>>>> >>>>>>>I agree. The transcript with Hsu is clear. But it would be out of character for >>>>>>>CCC if everybody just agreed with each other, there still has to be a fight ... >>>>>>>;) >>>>>>> >>>>>>>/Johan Melin >>>>>> >>>>>> >>>>>>Here is the relevant part of the transcript: >>>>>> >>>>> >>>>>There are other relevant parts? How about: >>>>> >>>>>---------------------------------- >>>>>EeEk(* DM) kibitzes: kib question from ardee: Does "12(6)" mean 12 >>>>>total ply or 12+6=18 total ply? This has the been source of huge >>>>>arguments for years! >>>>>CrazyBird(DM) kibitzes: 12 total in terms of brute force. 6 is just >>>>>the max partition in hardware. >>>>>---------------------------------- >>>>> >>>>>He sais 12 _total_. He also refers to 6 as "just", implying that it is less >>>>>important than the 12. >>>> >>>> >>>>No he clearly did _not_ say "12 total". He said "12 plies of brute force". He >>>>also >>>>said elsewhere that the _hardware_ does forward pruning. So "12 plies of brute >>>>force" >>>>implies that is non-hardware... >>> >>>It is not clear from it. >>> >>>suppose the hardware never pruned in the first 3 plies in the hardware when the >>>hardware get depth 6. >>>Suppose also that the software sent the hardware only lines of at least 9 moves. >>>You can have 12 plies of brute force when 6 is the maximal depth in the >>>hardware. >> >>going into details how the software and hardware divided itself is >>not very interesting, because it was so very inefficient. > >It's also very important to this discussion. > >>Also the moves it played were horrible. > >Give me some examples of horrible moves that it played. > >>It never doubts also, which > >What do you consider 'never' doubting? > >Maybe this search: > > 3(4) 14 T=1 >Pe6e5 nf3h4 Bd6b4 > 4(5) 21 T=1 >Pe6e5 nf3h4 Bd6b4 > 5(5)[e5](21) 21 T=1 >Pe6e5 nf3h4 Qd8a5 > 6(5)[e5](23) 23 T=2 >Pe6e5 nf3h4 Qd8a5 > 7(5) >#[e5](-3)###############################[Qa5](1)##[Qb8](13)##[Qe7](19)####[Qb6](20)#[Re8](23) >23 T=9 >Rf8e8 pc2c4 Pe6e5 qe1b1 > 8(6) #[Re8](-1)#[Qb8](4)#################################[Qc7](6) 6 T=30 >Qd8c7 pe3e4 Pe6e5 pg3g4 Bh5g6 nf3h4 Bg6h7 > 9(6) #[Qc7](-1)#[Qb8](1)####################################### 1 T=59 >Qd8b8 nf3h4 Pg7g5 nh4f3 Pe6e5 pe3e4 Rf8e8 >10(6) #[Qb8](-17)#[Qc7](-7)#[Re8](-6)###[Qa5](-3) -3 T=176 >Qd8a5 pa2a3 Rf8e8 nf3h4 Pg7g5 bb2f6N Nd7f6b nd2e4 Qa5d8 ne4d6B Qd8d6n nh4f3 > >In 7 iterations it only changed its mind 11 times...yes, of course that's 'never >doubting'. I can give plenty more examples. I can also give examples of every >other program NOT changing its mind during the entire search. It doesn't mean >much. > >But you do know that the better your evaluation, the less you should change your >mind, right? > >>amazes me. You concluded it is a preprocessor. If it is, then >>it is searching dubiously because i conclude clearly that it >>is not cleaning its hashtables, where i cannot disagree with your >>preprocessor conclusion. > >What? > >>the forward pruning in hardware was of course dubiously done. > >You don't even know what they did, how could you know it's dubious? > >>It is in hardware too difficult to take previous SOFTWARE mainlines >>into account. Doing the 2 times repetition in hardware is already >>hard enough. In IEEE99 Hsu describes how many gates some for us >>trivial things need. For software trivial things, they are very >>difficult in hardware. > >In the same paper from which you get the number 12.2, they explain how they >detect repetition. They don't use mainlines. They keep a count of displaced >pieces for the last 32-ply leading up to the current board position being >searched. The hardware can recognize a move that leads to a repetition (i.e., a >move where there are zero displaced pieces). Of course they have a move stack, >but the repetition detector doesn't explicitly need the moves. > >>Anything done in software is independant from the hardware obviously >>with exception of the 2 times repetition and the board position you >>have now and the single bound it has now. >> >>Note that a single bound creates a big problem to detect singular >>extensions in the mainline. > >They only used a single bound in the hardware, not in the software. And they >didn't do singular extensions in the hardware anyway, except at the first ply. > >>It DID do 1 singular extension the first ply in hardware. See the >>artificial intelligence article (deepblue.pdf). > >The software has much more interaction with the first hardware ply than the rest >of them, so it's a lot easier to do SE at that ply. > >>I already concluded years ago that the IBM team had a wrong implementation >>of singular extensions. Missing loads of singular moves. > >Please give examples. > >>They had to limit it bigtime, because otherwise you never get to 12.2 ply >>on average fullwidth. > >Of course they limit it, but that doesn't mean they 'miss' singular moves. > >>the big bugs in extensions in the hardware and the combination of forward >>pruning there which didn't take into account anything in software, >>means in short that it is pretty clever in software when a search of >>say 5 ply takes too long, to make 1 more move in software and divide >>all those moves over the different processors. >> >>It is not hard for me to realize that when you get 480 processors just >>2 weeks before the match starts, that it is impossible to get them >>efficient parallel to work. >> >>It is very happy to see for us that the deep blue machine only searched >>in reality on average around 250k nodes a second at each hardware cpu. >> >>If i give to you a 500 processor machine with 1Ghz McKinleys and such >>a simplistic program like deep blue (like 40 patterns in eval and >>very simplistic 'gnuchess' mobility, and not even knowing about doubled >>pawns like at g2,g3 or g7,g6). > >You obviously don't understand their paper if this is what you think. > >>Then i am sure you will get more than 126MLN nodes a second easily :) > >What kind of speedup does Zugzwang get using 500+ processors? > >>Even in terms of absolute speed, the machine isn't unreachable to todays >>standards. > >Nobody's saying it's not. But nobody else has done it either. > >>Of course i don't ask you to search very efficient at those 500 cpu's then, >>just 12 ply is enough to get similar deep :) >> >>Of course you can get more nodes a second easily by removing nullmove >>and you can forward prune a bit last few plies to not suffer too much >>from extensions. > >Removing nullmove does not give more nodes/sec. > >>And you can even try more conditions there than you can do in hardware. >> >>Your proposals to at least search 12 ply is interesting, but of course >>not practical to put in hardware, because the decision takes 1 extra >>cpu clock then. >> >>What i am lately wondering about is that when the machine searched >>300-400MLN nodes a second in far endgame, how little nodes a second >>must it have searched in openings phase to get to 126MLN a second? > >The maximum sustained speed for one search was 330M, IIRC. If you really want >to know the answer, you can do some math and find out how many times they >reached a 'far endgame', and estimate the percentage of searches in that phase. >Then some simple multiplication can give you a very low estimate for the average >speed of the rest of the searches.
This page took 0.01 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.