Author: Vincent Diepeveen
Date: 10:59:03 04/24/01
Go up one level in this thread
On April 24, 2001 at 13:37:02, Robert Hyatt wrote: >On April 24, 2001 at 11:25:29, Vincent Diepeveen wrote: > >>On April 24, 2001 at 09:57:39, Robert Hyatt wrote: >> >>>On April 24, 2001 at 08:20:57, Vincent Diepeveen wrote: >>> >>>>On April 24, 2001 at 03:47:15, Uri Blass wrote: >>>> >>>>>the best software that is not IBM. >>>>> >>>>>Suppose there is a match of 20 games at tournament time control >>>>> >>>>>I am interested to know how many people expect 20-0 for IBM >>>>>How many people expect 19.5-.5?.... >>>> >>>>>If IBM expect to do better result then the average result that the public expect >>>>>then they can earn something from playing a match of 20 games with Deep Blue. >>>>> >>>>>I believe that a part of the public who read the claim that kasparov played like >>>>>an IM are not going to expect good result for IBM.> >>>>>Uri >>>> >>>>First of all IBM would get out of book every game with -1.0 pawn >>>>disadvantage (which is about the average of what Kure and Noomen >>>>get in tournaments, sometimes they get out of book with mate in XXX even). >>> >>>That is pretty funny. I use a very simple to create book, and I don't get >>>out of book that badly in _every_ game. Not even every other game. >>> >>> >>> >>>> >>>>I would expect IBM to lose with 18-2. >>>> >>>>Let's be realistic >>> >>> >>>Yes, let's. :) 18-2 is pretty funny. >>> >>> >>> >>>> >>>> a) IBM searched 11-13 ply in 97, nowadays programs search deeper >>> >>> >>>Every time you make that statement I am going to correct it. From the log >>>files of the 1997 match we _know_ they searched 15-17 plies deep. Not 11-13. >> >>First of all the search depth *shows* 11 to 13 ply at most. > >No it doesn't. Here is yet another log excerpt from an early middlegame >position: > > 5(5)[axb5](60) 60 T=1 >pa4b5P Pa6b5p ra2a7 Ra8a7r bc5a7R > 6(5)[axb5](57) 57 T=1 >pa4b5P Pa6b5p ra2a7 Ra8a7r bc5a7R > 7(5) #[axb5](51)##################################### 51 T=2 >pa4b5P Pa6b5p ra2a6 Ra8a6r ra1a6R Nd6b7 bc5e3 Rc8a8 > 8(6) #[axb5](46)##################################### 46 T=7 >pa4b5P Pa6b5p ra2a6 Nd6b7 bc5e3 Nb7d6 ra6a7 Bf8e7 > 9(6) #[axb5](49)#################################### 49 T=55 >pa4b5P Pa6b5p ra2a6 Nd6b7 bc5b6 Ra8a6r ra1a6R Nb7d6 >10(6) #[axb5](49)##################################### 49 T=160 >pa4b5P Pa6b5p ra2a6 Nd6b7 bc5f8B Qe8f8b ng3f5 Ra8a6r ra1a6R Rc8b8 >11(6) #[axb5](49)#[Nf5](50) 50 T=308 >ng3f5 Nd6f5n pe4f5N Pb5a4p bc2a4P Bd7a4b ra2a4B Qe8d7 bc5f8B Rc8f8b pf5f6 Qd7d5p Very confusing is whether it's a 11 ply PV or 12 ply pv. the moves with n or N behind it means captures. DB extends in software nearly all captures. I see around 3 non capturing moves here. So 5 or 6 ply in software + capture extensions (either recapture extensions or SE) + 6 ply in hardware. Very logical. note it's a 12 ply PV you see here *not* a 11 ply pv. I get way longer lines at 12 ply with extensions turned on as this :) >qf2g3 Pg7g5 >--------------------------------------- >--> 33. Nf5 <-- 7/65:41 >--------------------------------------- This is caused by 30 diff processors with SE implemented. I have those huge lines too in DIEP when i turn on all extensions! No big deal. If 6(6) would mean 6 ply in software and 6 ply in hardware, then why do we see only 5 ply line? Even if you overwrite on an SP computer you still get 6 ply! Now the theoretic impossibility of searching 17 ply fullwidth *with* all those extensions the first 11 ply. Apart that each search line must be like 15 ply then or so, It's going to use up a lot of nodes. For deep blue it would cost around 5^6 more as the nodes they got in 1997! >Again I reiterate, the notation 11(6) means 11 plies in software search, >6 plies in the hardware, plus the quiescence in hardware. There is _no_ >argument with this. Simply ask any of the DB guys. 11(6) is a total of >17 plies of search. Noop it is not Bob. It is 11 or 12 plies of search from which 6 ply in hardware. Makes sense. Logical and clearly visible from the lines. The first few ply Note that if it would be 11 ply of search with pruning + 6 ply in hardware, then deep blue is the tactical worst program in history as it sees Bf5 in game 6 at 8(6) which would be 14 ply then, which doesn't make sense! Not even if you forward prune a lot! Shredder needs 8 ply for it too. It's a tactical queen win. Shredder is doing recapture extensions as far as i know. If i turn on extensions in diep i also need 8 plies. without recapture extensions i need 9 or 10 ply. Idem for other progs! Best regards, Vincent > >> >>Secondly it is theoretic impossible to search 19 ply fullwidth (13 ply >>software + 6 ply hardware) without hashtable last 6 plies. > > >no it isn't. And I will be glad to show you a 19 ply search by Crafty if >you want. Might take a while, but it is _not_ "theoretically impossible". >It is theoretically possible to solve the game, in fact... > > > > > >> >>This is simple math. >> >>how bigtime it suffered from not using hashtable can be easily >>seen in game 2 for example. > >You need to try the experiment first. I did so a few years back when having >a discussion with Hsu. It doesn't hurt nearly as much as you think. Even >Junior doesn't store the last ply or two before q-search. It hurts less in >the middlegame, more in the endgame, but not by a huge amount... the test is >easy to do (for me anyway). > > > > >> >>One of the moves Be4 which it made where Kasparov shortly was of >>the opinion that deep blue team 'cheated'. There there are many >>transpositions possible. Despite that deep blue doesn't search >>deeper as in openings positions where there are little >>transpositions possible. > > >Your math isn't working here. The effective branching factor at the Be4 >position is _still_ quite high. It is not a simple endgame yet. > >> >>I think Kasparov later corrected that, but i'm not sure of it. >> >>In diep the average number of moves is 40 in middlegame on average >>(endgame of course not counted). That is because it sees >>many stupid nonsense moves which humans do not consider soon. >> >>With hashtable you would reduce that bigtime (or as you indicate >>reduce actually seach depth needed, whatever you do, you will get >>a better b.f. as result). >> >>Last of all i DID do experiment with DIEP searching fullwidth and not >>using last 6 ply hashtable. >> >>Could you do this with crafty too? Of course after you also added SE >>to it for the first so many ply minus 6 and also turn on more recapture >>extensions and turn on checks in qsearch to some extend (for example >>only first ply). >> >>Now we can compare. Please posts nodes and search depth needed. >> >>The good b.f. which DB seemingly has first few seconds >>is a result of that initially it can't put 480 chessprocessors >>to work very efficiently within a few seconds. > >Sorry, but DB used 480 chess processors for _every_ search it did. That was >the way the algorithm was written. As a result, its search (and branching >factor) for early plies was worse than for deeper plies. This all explained >by Murray several times. > > > >> >>Nevertheless, please do the experiment and report back. For diep i need >>billions of nodes for 10 ply already! > >I'll try to find my old data on this. But if you need billions of nodes, >something is broken. I can turn hashing _off_ and not need billions of nodes >to search 10 plies... > > > > >> >>And i'm pretty sure i sort my moves better as Deep Blue ever did! >>Not to mention my evaluation is way better! > > >I love statements of pure subjective opinion when given as uncontestable >fact... Since you have never seen their evaluation in particular... > > > > >> >>All those factors are completely irrelevant of course. The proof for >>their search depth is so obvious! >> >>Apart from that studying logfiles you see that they get fail high to >>some tactical moves at very explainable search depths. >> >>Like the tactical move Bf5 in game 6 is 8 ply for them. With recaptures >>and SE i also need 8 ply for that. In fact most programs which by default >>do recaptures already need 8 ply! >> >>>15-17 in the middlegame, more in the endgame. I don't know where you get the >>>11-13 nor why you keep saying it when the log files clearly show that is wrong. >> >>6 ply in hardware + 13 ply in software = 19 ply fullwidth. >>Not 15-17. 11-13 ply is what they got. If you would add 6 ply in hardware >>to that that's 17-19 ply fullwidth! > > >That is _exactly_ what they got. 11(6) _does_ mean 17 plies + q-search. I >am not certain that the last 6 plies was 100% fullwidth... that I don't know >and I haven't taken the time to ask them for real details. They did mention >futility pruning in the hardware, so perhaps some of the last 6 plies were >subject to this. Or perhaps just the q-search was using futility. But there >are numbers in the log that match what they have said. I don't see any way to >dismiss (a) log files and (b) direct statements from the team members. > >> >>We only get that with nullmove AND hashtables! >> >>Please do the experiment Bob and as only programmer defending >>Deep Blue here it's very obvious that the facts are hard to ignore! > > >It seems to me that you are doing a pretty good job of "ignoring the >facts" here. Facts given directly in the log files for example concerning >their search depth. > >I often reach depths of 14-15 in middlegame positions using null-move. Turn >it off and that drops by 2-3. But then make me 200 times faster and I gain that >back and _then some_. > > > > >> >>> >>> >>>> b) their book is hell worse as nowadays books are >>>> c) positionally it never was good, it doesn't even >>>> know what a good bishop is nor when a doubled pawn is >>>> good (f2,g2,g3 pattern happened twice in games against kasparov) >>>> also it exchanges sometimes queens in a position where not exchanging >>>> wins for IBM >>> >>>Let me know when you or your program beats Kasparov in a standard game. Or >>>even when you _draw_ him. Then tell me how weak they played positionally. >>> >>> >>> >>>> d) hardly can use EGTBs >>> >>> >>>"Hardly"??? used them just like I do. They used them _before_ I did in >>>fact. They were using them in the late 1980's. Just like HiTech did. And >>>others. >>> >>> >>> >>> >>>> >>>>So in *all* respects it is getting outgunned. Not to mention EGTBs. >>>> >>>>No one talked about that subject yet, but last so many plies they can't >>>>use EGTBs. They only can use them the first 5 or 6 ply, that's it. >>> >>> >>>They use them in the first 11-13 plies. Which is _exactly_ how I use them. >>>I don't probe in the q-search. I don't probe beyond the basic nominal search >>>depth. It works fine for me. It works fine for them. They don't do it in >>>the hardware part of the search, which means the last 4-6 plies plus q-search. >>>That is _not_ a problem since it works well for me. >>> >>> >>> >>> >>> >>>> >>>>Though this is very good compared to not using them, this means simply >>>>that all exchanges towards a lost 5 men they will not detect. >>> >>>And if you probe in the q-search you will get killed tactically when there >>>are only 6-10 pieces on the board. You will lose _several_ plies. I know. >>>I have been there. >>> >>> >>> >>> >>>> >>>>They lose with induction to everything. The level of software has increased >>>>bigtime when compared to 1997. Of course the strategical problems are >>>>still there and some positional problems are still there, but in >>>>computer-computer games you hardly can take advantage of that. Only >>>>a human versus a computer can! >>>> >>>>Best regards, >>>>Vincent >>> >>> >>> >>>Your "induction" is broken. Make that "non-existent". HiTech or Cray Blitz >>>won't lose to "everything" today by any wild stretch. Much less Deep Blue. >>> >>>The jealousy directed at this program/project by chess programmers (some anyway) >>>is remarkable... the speculation about how it operates is even more remarkable. >>>And finally the amount of disinformation about it is unbelievable.
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.