Author: Robert Hyatt
Date: 14:59:32 09/17/04
Go up one level in this thread
On September 17, 2004 at 14:21:16, Dann Corbit wrote: >On September 17, 2004 at 11:42:38, Robert Hyatt wrote: > >>On September 16, 2004 at 19:48:59, Dann Corbit wrote: >> >>>On September 16, 2004 at 18:18:13, Robert Hyatt wrote: >>> >>>>On September 16, 2004 at 12:52:43, Dann Corbit wrote: >>>> >>>>>On September 16, 2004 at 07:37:01, Ricardo Gibert wrote: >>>>> >>>>>>Your post is a good example of what happens when one jumps to a conclusion >>>>>>without taking the minimum amount of effort needed to understand what is really >>>>>>going on. >>>>> >>>>>I disagree completely, also with everyone else. >>>> >>>>Taking a _longer_ path to win is counter to a tactical test idea. Clearly the >>>>move given is bad, because it just extends the game and reaches the same >>>>position a second time where the _real_ solution has to be played. That is >>>>pointless... >>>> >>>>Otherwise a mate in 3 might turn into a mate in 40 if one side takes every >>>>opportunity to first repeat a second time before making progress... >>> >>>The pv shown by Arasan leads to a win. >>>If it lead to a draw or some other problem I would agree. >> >>You ask a student to add 2 + 2. >> >>He turns in the following: >> >> >>sqrt(100) / sqrt(25) + log10(100) and solves that and turns it in with his >>scratch paper. Do you give him credit? I do not. There are a zillion longer >>ways to do something, such as a tree search in chess. Tactical solutions are >>about the shortest way to win. IE if there is a mate in 8 and a mate in 10, the >>correct answer is the mate in 8. > >There are often strange solutions to test problems (e.g. tossing a queen due to >tablebase simplification). If a chosen move wins 100% of the time, and the >program sees a clear solution, it is a winning move. A winning move cannot be >said to be incorrect. It has exactly the same value as a winning move to a >shorter solution. Maybe or maybe not. In this case, it clearly shows that the program is going to fail to find certain repetitions that will convert wins into draws. As a programmer, I would fix it. But, when there is a winning move, and you find a longer solution that comes back to a position where the winning move can be played, that solution is bad. IE using that approach a simple mate in 3 could turn into a mate in 3000 or more, which makes no reasonable sense to allow... > >>If there are two equal ways to win, then yes, >>either is correct. But to intentionally repeat a position makes no sense and I >>give it a "zero" as it is pointless... >> >>If you want to count it right, that's ok, but I disagree and I won't. Otherwise >>each WAC position probably has _multiple_ correct solutions... > >If a problem is not proven all the way to win/loss/draw then it is really open. >If there are 10 moves that lead to a definite win, then all ten moves are >solution moves. Including crazy moves like tossing a queen for a tablebase >simplification. The key move is proven to be a win. The program output you produced showed that in fact. But the program simply stuck extra, unnecessary moves on the front of the winning path, which can't be the right way to win this... Winning a tactical position is about finding the winning move, or if there are several, you generally want to find the shortest path to a win. But you certainly don't want to introduce extra moves that have no bearing on the position at all...
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.