Author: Michel Langeveld
Date: 22:56:33 09/15/00
Go up one level in this thread
On September 15, 2000 at 21:04:53, Dann Corbit wrote: >On September 15, 2000 at 17:57:47, Gian-Carlo Pascutto wrote: > >>On September 15, 2000 at 17:13:57, Dann Corbit wrote: >> >>>Sorry. Only 24 coming. This is only solved to 15 ply. Checkmate or not, you >>>must complete the ply to claim the "prize". >>>;-) >> >>Quote: >> >>Here are a set of tough positions to search deeply. Just finding a mate is not >>good enough, uless you can *prove* it is the shortest mate. >> >>>1.f6+ Kh8 2.Qh6 axb2+ 3.Kb1 Ne6 4.dxe6 Qxa2+ 5.Nxa2 Rg8 6.hxg6 >>> +- (#9) depth: 15/21 00:00:18 436kN >> >>If you want a _proof_ I guess CHEST is the only option. >> >>Now, before you start writing those poems realize that this >>analysis is done by a Solution-Tree-Cost search and *not* by >>an alpha-beta searcher. >> >>The ply depths listed are totally uncomparable to alpha-beta >>ply depths. >> >>If you think this is cheating, consider that that measuring >>ply depth, via any algorithm at all, is a bogus measure. > >So! I've been bamboozled. I think that pruning that leads to the same >solutions is valid. Every sort of pruning will throw away some correct >solutions. But NULL move is only very rarely going to lead to problems. As for >extensions like quiescense and things of that nature -- they lead to better >solutions but I don't think the added depth should be used to increase the ply >estimate. > >>The only thing that might qualify is a fixed-depth, not pruned >>except by alpha-beta, search. Those won't reach 16 ply within >>the next few years I guess ;) > >Which was exactly my point. However, for NULL-move pruned searches, it appears >that two of the difficult problems I posed were solved. A third would have been >solved, but Dieter felt mercy. I think the nature of my request was fairly >obvious. The notion that "ply depth means nothing" is bogus because everyone >obviously knows exactly what I mean. But let me temper it. > >If a pruning extension that leads to an examination of fewer leaves proves to be >superior in providing correct answers after a thorough statistical test for the >same estimated depth in plies, that extension would be accepted. > >>Every more or less standard chessprogram uses some kind of >>extensions or pruning, which make the ply depth figure _meaningless_. >>As meaningless as NPS is as an indicator of program strength. > >I disagree. Let's call ply the number of half-moves that a program is examining >on a minimum (ignoring NULL-move pruning). That is a completely unambiguous >term that anyone can understand. Now, if a program uses extensions to see >farther along certain special tracks, that is not a ply depth but a speculation >to improve the guess at the current ply. On the next iteration, we will have >moved to the next ply. > >>Even worse, there exist very good algorithms that don't have >>any notion of ply depth at all. > >What algorithms are those that do not consider half moves from the origin? > >>Besides, the basic task you gave us was very badly worded too: >>SOLVE these positions. > >Solve in the following manner: >A program which has exhaustively searched 16 plies will have a material and >positional value computation. The value of that computation is calculated in >centipawns according to the PGN standard. You will find that after reaching a >certain depth, good programs generally agree on the evaluation (certainly within >a pawn or so). > >>A real solution would only consist of one thing: 1, 0, or -1. >>Now, ironically, the one solution you didn't accept was the only >>one I was able to solve... (to a 1) > >That's an interesting real solution, but it isn't the one that I asked for. > >>Instead you ask for a value (centipawn evaluation) that is >>also meaningless. Centipawn = 1/100 of a pawn ? But the >>value of a pawn is NO constant! > >I made no such claim. However, centipawns is a measure approved of in the PGN >standard. An unblocked pawn on the 7th rank is worth far more than 100 >centipawns, obviously. > >>The only thing that matters >>is whether the position is WON or LOST (or drawn). > >Is that what your evaluation function returns? I doubt it. > >>I hope you now realize that this challenge was flawed, and >>that there is no use to holding ply-depth DSW's. > >I disagree. You can refuse to perform the request (which I think was fairly >obvious) but others might find it interesting. Claiming that there is no such >thing as a ply depth is even more silly than claiming that all programs have the >same meaning for depth in plies. The problem is one of definition. If you >cannot use an ephemeral definition, just use the exhaustive one. It's a bit >more doubtful you'll come up with useful data, but I think everyone really knows >what I mean. > >I realize that programs do prune differently. However, at whatever the author >really believes are the strongest play settings they do have some idea of what >half move they are processing, I am sure, for any algorithm. If not, where is >the algorithm so that I can read about it? > >>PS. >>My own program Sjeng reached over 12 ply in 30mins on 5 of >>those positions on my Cyrix120, so it's likely that a fast PentiumII >>can solve them. Also, the matefinder was on to something in at >>least one other position (not the mate above though!). I will >>try to get a full 16 ply search tomorrow. But again I ask you >>to realize that '16 ply' is meaningless. The only reason why Sjeng >>is able to get to those depths faster than e.g. Crafty (on the positions >>I tested this was the case) is that Sjeng is very light on extensions, >>but heavy on pruning. A 16 ply Crafty search is totally uncomparable >>to a 16 ply Sjeng search. You can replace Crafty and Sjeng by any >>random chessprogram in that last sentence. > >When Christophe Theron said that we were close to being able to search 16 plies >in a game, what do you think he meant? Were his words meaningless? I don't >think so. Each ply (in my definition) is a half-move carefully examined by the >program [in such a way that the optimal chances of winning from performing the >analysis in that manner are performed]. > >We could search forward and narrow our search to a single move at each ply >forward. But that does not fit my definition, since anyone can see that such a >method leads to disaster rather than the optimal chance of winning (unless >you're the GM who said, "I only consider one move -- the best one." when asked >how many moves they think of). r4r2/q1pb1pkp/1p1p2p1/2nPpP1P/2P1P3/p1N2P2/PP1Q4/2KR1BR1 w - - acn 31230467; acs 1052; bm f6+; ce 32750; dm 9; pv f6+ Kh8 Qh6 axb2+ Kb1 Qxa2+ Nxa2 Ne6 dxe6 Rg8 hxg6 Rxg6 Rxg6 Rg8 Rxg8+ Kxg8 Qg7#;
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.