Author: A. Steen
Date: 22:26:29 11/20/05
Go up one level in this thread
On November 21, 2005 at 00:57:13, enrico carrisco wrote:
>On November 21, 2005 at 00:07:38, A. Steen wrote:
>
>>On November 20, 2005 at 23:23:14, enrico carrisco wrote:
>>
>>>On November 20, 2005 at 23:03:44, A. Steen wrote:
>>>
>>>>On November 20, 2005 at 22:42:02, enrico carrisco wrote:
>>
>>
>> ::: snipped ten examples of engines analysing a KRK position; all found the
>>best move (Ke3) immediately in a tiny fraction of a second and gave it a high
>>evaluation :::
>>
>>
>>>>>Please -- will the die-hard "EGTB files are a waste" believers please stand-up.
>>>>>
>>>>>Regards,
>>>>>
>>>>>Enrico.
>>>>
>>>>
>>>>I think EGTBs are useful, but I think your examples illustrate the opposite of
>>>>what you are trying to prove. :)
>>>>
>>>
>>>Or perhaps you miss my point and need a clearer path of explanation.
>>
>>We'll see what I missed. :)
>
>Or what I missed... And why it is clear to me that I should have put forth a
>more solid (and clear) foundation to begin with. Then, the obvious point that
>the position is "won" would not arise.
>
>http://www.talkchess.com/forums/1/message.html?463265
>
>>
>>>>Good chess engines are not optimised mate-finders, but optimised win-finders,
>>>>and there is a big difference!
>>>
>>>So, after viewing the example below, your definition of win-finder would be
>>>taking the scenic route? Your statement is nonsense as finding mate is >winning.
>>
>>My statement is not "nonsense". :)
>>
>>You are confusing at least four potentially distinct things:
>>*a) winning by the fastest method available, and knowing it is fastest and a
>>100% sure win (i.e. a seen mate)
>>*b) winning by the fastest method available but not knowing it is fastest or a
>>100% sure win
>>*c) winning by a more "scenic route" and knowing it is a 100% sure win (a seen
>>mate)
>>*d) winning by a more "scenic route" and not knowing it is a 100% sure win.
>>
>>A tablebase result would be of type (a).
>>
>>All your chosen engine analysis examples were of type (b), with the move found
>>(and potentially made, if the TC was demanding enough) as fast as a tablebase
>>lookup would be. Whether directly (root position) or while carrying out an
>>evaluation/search.
>>
>>So in the single position example given by you, the EGTBs have no advantage.
>>
>>Had you chosen examples of types (c) or (d), you may likely have had a point.
>>
>>But you did not.
>>
>>Whether the program knows or not it is a fastest win is usually irrelevant as
>>long as it makes the perfect move fast enough. As Rhett Butler put it: "Frankly
>>my dear, I don't give a damn." In a manner of speaking.
>
>So, in your words, it is unimportant if 21 extra moves are made as long as they
>are made "fast enough."
"NONSENSE." I never said that at all. I said the opposite. This is
argumentatum ad strawmandum, or something like that.
Again, you apparently fail to understand. Did you even read my post fully?
Here is your test position, given by you in the first post in the thread:
[D]8/2k5/8/3R4/8/8/5K2/8 w - - 0 1
All your examples of engine analysis were of Type (b), i.e., the programs all
found the OPTIMAL = PERFECT = FASTEST move (and found it fast too, using the
/2.5 approximation up the plies probably in 1/100 second or a little more,
comparable to HDD seek times for a EGTB seek).
What more can you conceivably ask for, please?
Whether the programs **knew** (with the certainty of a tablebase lookup or
searchwise-proven fastest mate) it was OPTIMAL = PERFECT = FASTEST is therefore
not relevant at all. It is totally irrelevant for any purpose to do with winning
the game of chess being played. Scholarly research wasn't being discussed, else
there was no point to your post. For such research, almost always out of reach
of forward-searchers, that we need EGTB infallibility is a given. Quote the
recent 266 move long 7 piece horror win!
You were discussing real play. Winning OTB. You discussed time controls. They
don't apply to scholarly research.
The engines you selected all found Ke3, and found it "instantly", and Ke3 is the
best move (uncooked too).
So what more do you want?
Had any of the engines chosen another move (also winning, but slower - i.e. Type
(c) or (d), then you would have a point, and I would not have posted to correct
you).
Please, if you can't grasp this much, our conversation is truly pointless. You
obviously see higher truths than I can see or choose to see. :)
> Unfortunately, I think many would "give a damn",
Why?
All the programs choose the optimal move (Ke3) "instantly" (far faster than an
EGDB lookup), and stick to it faithfully with a high score (DJ9 apparently
wavers for a fraction of a second but then reverts).
>especially if trying to analyze a position for greater insight.
Hahaha!
Now, you change the goalpost, and pretend you are talking about research
analysis, which is not what the discussion was about at all (else it would not
be a discussion).
You are a riot! :)
I hope you are joking. Else I would advise you to make your profile private, in
case these justifications by you are used to poke fun at you by others in the
future.
>(Especially a
>self-proclaimed "almost patzer.") Or is it genius? (See:
>http://www.talkchess.com/forums/1/message.html?463281)
>Here's another example -- perhaps you will find it a worthy one:
Thanks, I gave you a perfect example already, with:
[D]2r5/8/5K2/3k4/8/8/8/8 b - - 0 93
which illustrated your point for Fruit.
::: snipped :::
Isn't the real underlying question - will Hiarcs X be able to stand up to Fruit
2.2.x or will it be ruthlessly crushed like Hiarcs 9 and earlier? I think even
an 8-man tablebase would not help H9, it doesn't get close enough vs Fruity to
use that in search very often. :)
Now, I must go and learn again (Dot)-(Dot)-(Dot), and I leave you to grasping
the difference between
EGDB = Type (a)
"Accidental EGDB" = Type (b)
Scenic routes = Types (c), (d)
Best,
A.S. (patzer, as proven by CCC "GM"s in-
http://www.talkchess.com/forums/1/message.html?463110 )
>>> By the way -- your profile is missing.
>>
>>Excellent, and most highly relevant to the discussion.
>>
>>>>So whether the programs found mate instantly, let alone the quickest mate, or
>>>>not is irrelevant.
>>>>
>>>>In all your examples, the programs found the fastest winning move (Ke3 - and I
>>>>don't need to check that, do I - surely everything else must be at least 1 move
>>>>slower?) in much less than one second. Probably in just a few thousandths of a
>>>>second. And all gave it a high evaluation. Only one (J9) ever wavered from
>>>>that choice Ke3.
>>>>
>>>>So, even if EGTBs were being used in the search itself, the presence of EGTBs
>>>>would not have helped at all in this example. Chess Challenger 7 could not
>>>>handle KRK, but we have moved on since then.
>>>>
>>>>Simply put, you need a more complex example. :)
>>>
>>>I wasn't trying to hang Fruit with my example, so I didn't hammer my point clear
>>>enough, perhaps. Yes it found the next suceeding move but not knowing a clear
>>>path to mate in very simplistic ending can end with a lot of wasted time -- even a flag.
>>
>>Some endings - many endings - only look simplistic.
>>
>>>Look at moves 86. on in the following exmaple. Fruit 2.2.1 was black.
>>
>>OK. But a bit earlier, at 58., there is what I think may be a blunder by white.
>>
>>
>>>
>>>1. Nf3 {0:05:03} Nf6 {0:05:03} 2. c4 {0:05:06} c5 {0:05:06} 3. g3 {0:05:08}
>>>d5 {0:05:09} 4. cxd5 {0:05:11} Nxd5 {0:05:11} 5. Bg2 {0:05:14} Nc6 {0:05:14}
>>>6. Nc3 {0:05:17} Nc7 {0:05:17} 7. Qa4 {0:05:20} Bd7 {0:05:20} 8. Qe4
>>>{0:05:23} g6 {0:05:23} 9. Ne5 {0:05:26} Bg7 {0:05:26} 10. Nxd7 {0:05:29}
>>>Qxd7 {0:05:29} 11. O-O {0:05:32} O-O {0:05:32} 12. a3 {0:05:35} Rac8
>>>{0:05:34} 13. b4 {0:05:37} cxb4 {0:05:23} 14. axb4 {0:05:25} Nb5 {0:05:25}
>>>15. Bb2 {0:05:07} a6 {0:05:28} 16. Rfd1 {0:04:41} Nd6 {0:05:31} 17. Qd5
>>>{0:04:25} Rfd8 {0:05:34} 18. Qa2 {0:04:14} e6 {0:05:28} 19. Rdc1 {0:04:16}
>>>Nf5 {0:05:19} 20. Bxc6 {0:04:16} Rxc6 {0:05:00} 21. d3 {0:04:00} Nd4
>>>{0:04:34} 22. Kg2 {0:03:54} e5 {0:04:19} 23. Rab1 {0:03:30} h5 {0:04:22} 24.
>>>Ne4 {0:03:25} Nxe2 {0:04:21} 25. Rxc6 {0:03:18} Qxc6 {0:04:17} 26. Qc4
>>>{0:03:14} Qd5 {0:04:16} 27. Qxd5 {0:03:08} Rxd5 {0:04:19} 28. Kf3 {0:03:04}
>>>Nd4+ {0:04:12} 29. Bxd4 {0:03:06} Rxd4 {0:04:01} 30. Ke3 {0:03:09} b6
>>>{0:03:46} 31. Nd2 {0:03:01} Bh6+ {0:03:45} 32. Ke2 {0:03:00} Bxd2 {0:03:43}
>>>33. Kxd2 {0:02:55} Kg7 {0:03:43} 34. Kc3 {0:02:46} Rd6 {0:03:42} 35. Re1
>>>{0:02:42} Kf6 {0:03:30} 36. Re4 {0:02:45} Kf5 {0:03:22} 37. f4 {0:02:39}
>>>Rc6+ {0:03:23} 38. Kd2 {0:02:30} exf4 {0:03:18} 39. Rxf4+ {0:02:32} Ke6
>>>{0:03:14} 40. Re4+ {0:02:32} Kd7 {0:03:07} 41. Re1 {0:02:28} a5 {0:02:59}
>>>42. Ra1 {0:02:28} axb4 {0:02:52} 43. Rb1 {0:02:31} Rf6 {0:02:46} 44. Ke3
>>>{0:02:30} Re6+ {0:02:39} 45. Kf4 {0:02:33} Re2 {0:02:32} 46. Rxb4 {0:02:28}
>>>Rf2+ {0:02:26} 47. Ke4 {0:02:19} Rxh2 {0:02:29} 48. Rxb6 {0:02:13} Rh3
>>>{0:02:32} 49. Kf4 {0:02:07} h4 {0:02:31} 50. gxh4 {0:02:05} Rxd3 {0:02:26}
>>>51. Kg5 {0:02:06} Rf3 {0:02:14} 52. Rb7+ {0:02:02} Ke6 {0:02:17} 53. Rb6+
>>>{0:01:54} Ke7 {0:02:19} 54. Rb7+ {0:01:51} Kf8 {0:02:10} 55. Rb5 {0:01:54}
>>>Rh3 {0:02:05} 56. Kf6 {0:01:56} Kg8 {0:02:03} 57. Rb8+ {0:01:57} Kh7
>>>{0:02:05} 58. Kxf7 {0:01:54} Rxh4 {0:02:03} 59. Kf6 {0:01:57} Rh5 {0:02:05}
>>>60. Rb1 {0:01:52} Rf5+ {0:02:08} 61. Ke6 {0:01:47} Kh6 {0:02:10} 62. Rb2
>>>{0:01:42} Rf4 {0:02:13} 63. Rh2+ {0:01:38} Kg5 {0:02:15} 64. Ke5 {0:01:28}
>>>Rh4 {0:02:18} 65. Rf2 {0:01:23} Kh5 {0:02:21} 66. Rf8 {0:01:22} g5 {0:02:23}
>>>67. Rh8+ {0:01:17} Kg4 {0:02:26} 68. Rb8 {0:01:15} Rh1 {0:02:29} 69. Kf6
>>>{0:01:13} Rh6+ {0:02:31} 70. Ke5 {0:01:11} Rc6 {0:02:34} 71. Ke4 {0:01:04}
>>>Re6+ {0:02:36} 72. Kd4 {0:01:03} Re1 {0:02:39} 73. Rh8 {0:00:58} Kg3
>>>{0:02:41} 74. Kd3 {0:00:55} g4 {0:02:44} 75. Rh6 {0:00:50} Kg2 {0:02:46} 76.
>>>Rf6 {0:00:44} g3 {0:02:48} 77. Rf7 {0:00:41} Re5 {0:02:51} 78. Rh7 {0:00:41}
>>>Kf3 {0:02:54} 79. Rf7+ {0:00:41} Kg4 {0:02:56} 80. Rf1 {0:00:42} g2
>>>{0:02:58} 81. Rb1 {0:00:19} Kf3 {0:03:01} 82. Kd4 {0:00:17} Rg5 {0:03:03}
>>>83. Rg1 {0:00:04} Kf2 {0:03:06} 84. Rd1 {0:00:05} g1=Q {0:03:08} 85. Rxg1
>>>{0:00:08} Rxg1 {0:03:02} 86. Kd5 {0:00:07} Re1 {0:02:48} 87. Kd4 {0:00:05}
>>>Rd1+ {0:02:26} 88. Ke4 {0:00:04} Rd8 {0:02:19} 89. Ke5 {0:00:06} Kf3
>>>{0:02:00} 90. Ke6 {0:00:09} Ke4 {0:01:44} 91. Kf6 {0:00:07} Kd5 {0:01:22}
>>>92. Ke7 {0:00:05} Rc8 {0:01:11} 93. Kf6 {0:00:07} Rc3 {0:01:03} 94. Kf5
>>>{0:00:07} Rh3 {0:00:57} 95. Kf4 {0:00:07} Rh4+ {0:00:56} 96. Kf5 {0:00:09}
>>>Rh5+ {0:00:52} 97. Kf4 {0:00:07} Re5 {0:00:41} 98. Kf3 {0:00:05} Rf5+
>>>{0:00:36} 99. Ke3 {0:00:04} Rf7 {0:00:32} 100. Kd2 {0:00:04} Kc5 {0:00:24}
>>>101. Ke3 {0:00:05} Rf1 {0:00:19} 102. Ke4 {0:00:04} Kd6 {0:00:11} 103. Kd3
>>>{0:00:04} Rf3+ {0:00:05} 104. Ke4 {0:00:04} Rf8 {0:00:04} 105. Kd4 {0:00:04}
>>>Rf4+ {0:00:07} 106. Kd3 {0:00:05} Kc5 {0:00:04} 107. Ke3 {0:00:06} Ra4
>>>{0:00:04} 108. Kd3 {0:00:06} Rd4+ {0:00:07} 109. Ke3 {0:00:06} Rb4 {0:00:04}
>>>110. Kd3 {0:00:06} Rh4 {0:00:04} 111. Ke3 {0:00:06} Kc4 {0:00:05} 112. Kf3
>>>{0:00:08} Kd3 {0:00:04} 113. Kg3 {0:00:06} Rb4 {0:00:07} 114. Kf3 {0:00:05}
>>>Kd2 {0:00:10} 115. Kf2 {0:00:05} Rb3 {0:00:12} 116. Kf1 {0:00:07} Ke3
>>>{0:00:12} 117. Kg2 {0:00:10} Ke2 {0:00:13} 118. Kg1 {0:00:13} Kf3 {0:00:14}
>>>119. Kh2 {0:00:15} Rb1 {0:00:14} 120. Kh3 {0:00:18} Rh1# {0:00:16}
>>>{White checkmated}
>>>0-1
>>
>>Well, EGTBs hook on to the win once white allows the pawn exchange at 58.,
>>giving m/44. So at 86, with optimal play for both, we should be at about m/16.
>>In fact we are at m/13 as white has played worse. 86 + 13 = 99. So there was
>>an extension by 120-99 = 21 moves, caused by stupid play by black starting with
>>92 and then getting worse.
>>
>>Yes, this is a better example from you. :)
>>
>>It illustrates that repeated "scenic routes" can literally result in running
>>around in pointless rectangles (like the BR does).
>>
>>Your single position example did not.
>>
>>Aside: EG play by both Fruity and Fritzy9 is sometimes suspect. It comes with
>>the territory of making the progs smarter, maybe.
>>
>>I am on the side of EGTBs.
>>
>>Best,
>>
>>A.S.
This page took 0.01 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.