Author: Robert Hyatt
Date: 19:31:24 05/11/98
Go up one level in this thread
On May 11, 1998 at 14:59:15, Vincent Diepeveen wrote: > >I construct the PV from hashtable too. And with probe > 4 it hardly >gets overwritten, unless you have some bugs in your hashtable. hardly != *never*. And when you go as fast as I go on a Cray, even with huge hash tables there are overwrites... If you don't believe this, go try fine #70 with lots of different sizes of hash. If you *always* solve it at the same depth, no matter what the hash, I'll believe you. If you change based on the size of hash, you just proved it to yourself that important stuff gets overwritten... > >>So at the very best, you can see their PV less the last 4 non-captures >>+ captures, and if the hardware is following checks or whatever, that >>"hidden" part of the PV can be quite deep. The SP2 is only doing about >>7-8 plies of search before handing off these "near-leaf" positions to >>the hardware. So at *best* you can see about 2/3 of the PV, At worst, >>a small part... > >This is not true. I'm using probe=8, you are already for a long time >telling the whole world how easy it is at these mainframes and >supercomputers >to use a huge probe. please stay with me one more time: we are *not* talking about a super- computer when we talk about the individual chess processors on DB. we are talking about 500 different processors, and they all do *not* share a huge transposition table among all the processors, they have enough separate tables to make this a *huge* problem... > >With a huge probe it never gets overwritten. The memory is huge at >a mainframe compared to the number of tuples they need to store, so >they chance they overwrite PV is near to zero. totally wrong, Vincent. They don't have a large shared hash table. They have one for the SP search itself, and the chess-specific chips have a hash table on the boards... but it is *not* addressable from the SP, nor from *other* chess processors (not shared)... Please don't make blanket statements when you don't know what they have done... it only confuses things worse.. > >>>This is exactly what i experienced myself: if you search 11 ply then >>>positionally >>>you simply see not much deeper. Definitely not 30 ply. > >>Then you simply haven't done it right... Because selective extensions >>do work. They work better and better as you have more hardware and can > >If they do work then why is DB the only program in the world where it >works? er, maybe because it is the only program that can afford to spend that kind of nodes in extensions? although genius uses singular extensions, and Dave Kittinger was at last check... as did HiTech and Cray Blitz. But it takes horsepower, and it has a cost. They get to ignore the cost because they go so fast the "cost" can be ignored... > >I remember that hundreds of people have tried it, and no one got it to >work, >and suddenly DB got it to work? Where have you *been*? DB *invented* singular extensions... > >You told us about a year ago that DB team would publish some astonishing >stuff. Still waiting for that publication. > >>afford non-important extensions, since it is difficult to tell the >>difference >>between those that are useful and those that are not, in a given >>position. >>They can search zillions of futile ones, to pick up that one very >>important >>one, and they *still* out-search us... > >zillions is not near the truth. they search around 36B nodes from which >at least >18B gets wasted, > >then the processor is so fast that they cannot store this in shared >memory, >so we get few billions finally which they search. > >So if i allow my program to search a billion nodes with nullmove in a >position >where nullmove can be used (and that are all positions played that >match), >then my program sees way more than they did. Keep believing that. While we are on the subject, I have this bridge in New York that I've been trying to get rid of. It is a good investment and I'll let you have it *cheap*... > >That's very logical. > >>>Of course, mate in 15 ain't no problem, but let's discriminate between >>>TACTICS, and positional depth. > >>singular extensions is not only about tactics. It can be about >>positional >>extensions just as easily. It depends on the singular margin you think >>you >>can live with. Most use big numbers to keep cost down. They are not >>so constrained... > >This algorithm already goes wrong when a move is not singular. >Singular moves are good to see some deep threats like mate. singular extensions can also find positionally singular moves if you tune it right... depends on how much you are willing to "invest". They have plenty to spend... > >In opening for example after 1.d4,d5 2.e4?,dxe4 3.Nf3 >this means that they cannot use this algorithm because you can cover >e4 in more than 1 different way. so what? that's not a singular move... > >So singularism is not the way to solve chess. Especially singularism is >a tactical extension, just like chess. It is not positional. It has to >do with >threats where you only have 1 move to prevent that thread. > >If i threaten you, and you can only undo my threat in 1 way, then >no matter the value i need to have only 1 way to undo that threat. > >Singular extensions is converting alphabeta back to minimax. not by a long stretch... but you need to read Hsu's paper, and implement them before throwing stones... It works... > >A big problem of singular extensions is detecting them. >To detect them i need to search all siblings which in fact i don't want >to search because i want to give a cutoff here. searching it with a >reduced >depth is like a minimax algorithm where you search the biggest part of >the tree with a reduction factor, but only a small reduction compared to >the depth of the tree. > try the math... it is not a "small reduction" It is an *exponential* reduction. Their paper mathematically shows *exactly* what it costs, and the cost is not overwhelming.. > > >>> >>>Now don't make me laugh by saying that they use smart extensions: >>>If you KNOW what to extend, then why extending, you can play the best >>>move at once without searching. >> >> >>You miss the whole point. They can *afford* "dumb" extensions. so that >>if only one of every 100,000 extensions they try produces something >>useful, >>they can afford that. *we* can't... we'd be doing 4-5 ply searches. > >Yes they can afford to search minimax, but they won't search deeper than >11 ply then as it appears. maybe you'll get to play them one day... you'll then change your tune. As did most of us after getting steamrolled. Remember that DiepX doesn't beat Crafty enough yet to claim any superiority... And I *know* how Crafty would do against DB... I *know*... > >>>>I disagree with the "clearly lacking knowledge".. It drew an ending I'd >>>>bet every program around would lose. And it found ways to keep things >>>>interesting... round 1 was a lucky win by Kasparov... one or two tempi >>>>and things turn totally around... >>> >>>Can you base this on evidence, like what moves are so hard to find for >>>our pc programs at analysis level (to compensate a little >>>for their fast hardware and get more than 11 ply)? >>> >>>Fact is that DB did a bunch of bad moves, which for the major part are >>>not done by commercial programs. > >>yes... it also did a bunch of *good* moves, most of which are *not* done >>by commercial programs... > >Let me repeat the question to you WHAT moves are so well >from DB? > >All ! moves (a4!,Bf5!) of DB in the 6th game for example >are done very quickly by almost all PC programs. > >So any pc program would have won this game quickly. horsehockey. This game was played out against several commercial PC's giving them white and none won against a good IM. This was published in r.g.c.c within a month or so of the match... Remember black was a piece up. The micros all managed to lose at 40/2 time controls... I don't remember who posted this however.. but it should be in Deja..
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.