Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: To NON-believers in EGTB benefits... (some engines benefit greatly..

Author: A. Steen

Date: 23:51:03 11/20/05

Go up one level in this thread


On November 21, 2005 at 02:06:28, enrico carrisco wrote:


:: snip only to improve readability and highlight new oddities/POI ::


>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


By "SAME position" one must assume you mean "Not the SAME position", as in the
original position supplied by you, Fruit didn't shuffle anything and found Ke3
instantly w/o EGTBs. :)

And since avoiding aimless moves is one of the main points.... :)


>with EGTBs, Fruit did not shuffle pieces and did always find the correct move, as expected, and did so instantly.


"Instantly" is interesting.

S(KRK, Nalimov EMD) =! 7Kb, which resides in RAM cache easily.  But we are
talking about the general question of EGTB use, where tablebase sizes make RAM
cache-residence a dream many years from reality (and even then, pre-load time
will be an issue).  So for real life use, HDD latency and seek times are an
issue, and periods of even 10ms have to be considered.

For a 4GHz CPU, even 5ms = 20,000,000 CPU cycles.  With hyperthreading and
family, that is an awful lot of processing time for one tablebase lookup.

So, "instantly" is usually wrong.


>Benefit or no benefit?


See above.


>>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.


Yes, another argument, and not one which really supports you in the general
case. As shown above. In all but the tiniest EGTBs, HDD latency is an issue, and
often delayed look-up will fundamentally disrupt alpha-beta etc.

Thanks for the further undeserved "Nonsense" insult. :)

My experience tells me, the more abusive one's not unintelligent adversary
becomes, it is because the more aware he or she is of the virtual bullet holes
in his or her feet. :)

Saying "Sorry, I was wrong, we all make mistakes." is so much simpler!


>>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.


Being constructive, interesting is to see how long it takes (for moves 92. and
some successors in your example) on a modern PC for Fruit / F9 etc. playing
without EGDBs to find a constructive plan and stick to it.

Have you looked?


>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.


As Ke3 is neither, and is optimal, irrelevant.


>>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.'


Yet a further, probably undeserved, obvious insult.  This just isn't your day,
sir. :)

I take it telling your correspondent (s)he is a troll after you have been
brought into logical line is something you have done before.

I do not fish, and therefore do not troll.


>I'm sorry you feel your only remaining course of action is to attack HIARCS 10.
>It, however, does not surprise me.


You initially inferred a motive for my interjection was seeing Fruit singled out
for your fire.  I have no allegiance to Fruit, and elsewhere I compliment F9 and
S9 for having positive OTB scores vs myself, while Fruit I find (relatively)
easy to defeat.  All games slow, of course.

I simply responded in precise reflection, by bringing Hiarcs into it (had you
not directed me so discreetly to your profile, I would not have known).

You did not like it. But I did not like it done to me, and you started it.  So
to cry foul now makes it worse still.

Hopefully, you learned something positive. Or, are you a "troll"? (see above).

>-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 )



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.