Author: enrico carrisco
Date: 23:06:28 11/20/05
Go up one level in this thread
On November 21, 2005 at 01:26:29, A. Steen wrote:
>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?
I did read your post fully but fail to see your argument beyond the fact that my
first example didn't include the aimless moves of my latter examples. The
subject of the post was "EGTB benefits." In the SAME position with EGTBs, Fruit
did not shuffle pieces and did always find the correct move, as expected, and
did so instantly.
Benefit or no benefit?
>
>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).
Nonsense again. If using EGTBs, the move would have been instant -- but this is
another agurment entirely.
>
>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.
I'm sorry you assumed that my discussion was narrowed in such a way. I did
discuss the possibility of being flagged which relates to "real play" but I
mentioned "clear path to mate" which is not isolated to either and applies to
both.
>
>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?
See "aimless moves" or "peice shuffling" above.
>
>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. :)
I believe it was pointless from the beginning since you claimed to be an EGTB
supporter but replied to a post that (while not initially clearly and
completely) set out to show EGTB benefit. Besides beating the dead horse of me
not including an initial example of the "aimless moves" in my first KRK example
-- what point have you made?
>
>> 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).
Already answered above.
>
>You are a riot! :)
I'm glad you're enjoying yourself.
>
>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 you prove my earlier assumption that you are a 'troll.'
I'm sorry you feel your only remaining course of action is to attack HIARCS 10.
It, however, does not surprise me.
-elc.
>
>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 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.