Author: Jeremiah Penery
Date: 16:32:38 10/18/02
Go up one level in this thread
On October 18, 2002 at 14:40:37, Vincent Diepeveen wrote: >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. I saw the Seirawan analysis a long time ago, and I don't remember being too impressed. I will try looking at it again. Even so, I asked YOU for examples of bad moves. Can you answer some of the other questions I asked, also? >>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 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.