Author: Robert Hyatt
Date: 08:39:45 01/17/05
Go up one level in this thread
On January 17, 2005 at 07:33:59, chandler yergin wrote:
>On January 16, 2005 at 22:58:45, Robert Hyatt wrote:
>
>>On January 16, 2005 at 17:32:51, chandler yergin wrote:
>>
>>>On January 16, 2005 at 10:49:08, Robert Hyatt wrote:
>>>
>>>>On January 16, 2005 at 01:15:36, chandler yergin wrote:
>>>>
>>>>>On January 15, 2005 at 23:19:50, Robert Hyatt wrote:
>>>>>
>>>>>>On January 15, 2005 at 20:24:04, chandler yergin wrote:
>>>>>>
>>>>>>>On January 15, 2005 at 20:16:37, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>On January 15, 2005 at 12:29:40, chandler yergin wrote:
>>>>>>>>
>>>>>>>>>New game,
>>>>>>>>>{D]7k/8/8/8/8/8/N7/KB6 w - - 0 1
>>>>>>>>>
>>>>>>>>>Analysis by Shredder 8:
>>>>>>>>>
>>>>>>>>>1. +- (#29): 1.Kb2
>>>>>>>>>2. +- (#30): 1.Nc3
>>>>>>>>>3. +- (#30): 1.Nb4
>>>>>>>>>4. +- (#30): 1.Bc2
>>>>>>>>>5. +- (#30): 1.Bd3
>>>>>>>>>6. +- (#31): 1.Nc1
>>>>>>>>>7. +- (#31): 1.Be4
>>>>>>>>>8. +- (#32): 1.Bf5
>>>>>>>>>9. +- (#32): 1.Bg6
>>>>>>>>>10. = (0.00): 1.Bh7
>>>>>>>>>
>>>>>>>>>(, 15.01.2005)
>>>>>>>>>
>>>>>>>>>Instantaneous! I don't care how 'deep' in the search.. once into the EGTB,
>>>>>>>>>it's there!
>>>>>>>>
>>>>>>>>Completely irrelevant. You have to first _reach_ that position, and if you
>>>>>>>>reach it wrongly, you reach it in a drawn position.
>>>>>>>
>>>>>>>
>>>>>>>That's why the Analysis module seaches E-V-E-R-Y Move in a pV
>>>>>>
>>>>>>This would be much more interesting if you had any idea about what you are
>>>>>>talking about. A disk I/O takes about 5ms. 20 egtb probes in a search will
>>>>>>burn 1/10th of a second. 200 probes will burn a second. That is _not_
>>>>>>instantaneous. For a program searching 2M nodes per second, the speed can slow
>>>>>>down to 20,000 nodes per second easily given the right position.
>>>>>
>>>>>
>>>>>Zeno's Paradox...
>>>>>
>>>>>Let's say you are sitting next to your wife or girfriend...
>>>>>
>>>>>You slide halfway to her...
>>>>>
>>>>>
>>>>>Then you slide half way closer again...
>>>>>
>>>>>Then get halfway again...
>>>>>
>>>>>Theoretically, you will NEVER Reach her...
>>>>
>>>>This is _absolutely_ wrong. Any good integral calculus book will show you why.
>>>>
>>>>hint:
>>>>
>>>>The limit of X = 1/2 + 1/4 + ... + 1/2^n for N=infinity is exactly one. Theory
>>>>is quite clear there.
>>>>
>>>>Now if you mean "practically you will never get there" then you would be right.
>>>>But if you do the 1/2 step enough times, you will get there. It is just that
>>>>"enough" will take forever.
>>>>
>>>>>
>>>>>BUT; you will get close enough for Practical purposes.
>>>>>
>>>>>STOP YOUR CRAP!
>>>>
>>>>Learn some math...
>>>>
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>>If there are 50 "Possible" moves in a position.. it will search
>>>>>>>deeper and deeper... Subject to your Alpha Beta Algorithm of course...
>>>>>>>
>>>>>>>Which may or not be correct...
>>>>>>>
>>>>>>>
>>>>>>>Of course ya have to reach the position!
>>>>>>>Depending on the Static Positional Values Programmed in...
>>>>>>>in a Quiscent NON - Forcing position, and different engines may evaluate the
>>>>>>>position differntly.
>>>>>>>
>>>>>>>Right? You know I'm right!
>>>>>>
>>>>>>Hardly...
>>>
>>>Sorry, now you're speaking nonsense!
>>>This is part of the arrogant ignorant misinformation that you guys are
>>>spreading.
>>>That, is what I challenge!
>>
>>Then challenge something and give a citation in the literature to support your
>>challenge, if it exists... So far you have not provided _anything_ but lots of
>>ranting and rhetoric...
>>
>>>Fritz has a BUG in it... especially in positions where the King can run into
>>>the corner, and the opponent has a Bishop of the wrong color, plus a Rook Pawn
>>>advantage. Fritz sees the position as a win due to material advantage.
>>>It's a DRAW of course...
>>>You can let the Hard Disc spin til Hell freezes over, and it will NOT
>>>see the Draw!
>>
>>So what? Not all programs do that.
>
>Right! NONE of them should!
>
>> It is a decision made by the programmer and
>>it is a compromise.
>
>NO, it's a DEFECT; a Serious Defect! A Programmers defect!
>Bishops of Opposite Colors are NOT Rare Positions; and I won't allow you to call
>it a 'compromise' and get away with it!
It _is_ a rare position. Why don't you pick 500 random games, look at every
position, and see how often a BOC ending happens and is important to the game
outcome? Then you can talk using real data and real understanding, rather than
writing nonsense... Many programs played for _years_ with no BOC understanding
whatsoever. And they beat GMs regularly in spite of this...
>
>
>
>>There are reasons for and against recognizing certain rare
>>positions as draws or ignoring them in the search for more speed.
>
>Nonsense!
>Stick to my Point!
>Fritz has a BUG in it... especially in positions where the King can run into
>the corner, and the opponent has a Bishop of the wrong color, plus a Rook Pawn
>advantage. Fritz sees the position as a win due to material advantage.
>It's a DRAW of course...
>You can let the Hard Disc spin til Hell freezes over, and it will NOT
>see the Draw!
>
if it has endgame tables it might...
>
>
>>
>>>
>>>Other Programs had a Big Bug in them.. perhaps it's fixed now,
>>>but, a few years ago, it was obvious that to Beat the Top Programs,
>>>White gets a Stonewall Position, and demolishes Black on the Kingside!
>>
>>Feel free to log on to ICC and show me this.
>
>Try reading with comprehension!
>"Other Programs had a Big Bug in them.. perhaps it's fixed now,
>but, a few years ago, it was obvious that to Beat the Top Programs,
>White gets a Stonewall Position, and demolishes Black on the Kingside!"
>
Crafty has had BOC code for 10 years. That is a bit longer than "a few years
ago". I know other programs that also had this term...
>
>
>> I'll be willing to let Crafty play
>>you as many games (Crafty black) as you want, you always playing the Stonewall.
>
>Then I assume you fixed the Problem!
>
>
No, I never _had_ the problem...
>
>>>
>>>Put up any complicated Position, and let 5 Programs evaluate it!
>>>
>>>Tell me they ALL eval the pV the same?
>>>NONSENSE!
>>
>>So? Neither do humans. You seem to overlook that...
>
>
>I don't,
>>
>>
>
>"In a NON-Forcing Quiescent Position, the Static Positional Values come into
>play.Different analysis modules evaluate the position differently, based on how
>they were Programmed."
>
>Now, are you going to tell me and this Forum, I am NOT correct?
>
>Answer the Question!
>
What does that have to do with the discussion at hand? You can say 2+2 = 4 and
also be correct, but it has nothing to do with the stuff in this thread.
>
>>
>>I am going to tell you that in general, you don't know what the hell you are
>>talking about.
>
>You haven't refuted anything I've Posted!
>You have avoided the main points, and danced around..
You are the one dancing around, never addressing the same topic repeatedly.
>
>
>
>> The above had _nothing_ to do with the topic of this thread,
>>namely speed and endgame tables.
>
>It had to do with a Specific Topic I had in mind..
>You Nit-Picked it. Milliseconds are not Instantaneous...
>What a Pathetic response.!
But a _correct_ response. Showing that a program's search speed can drop from
1M nodes per second to 1K nodes per second _easily_...
>Using Multiple Lines are only showing what the Program has already seen.
>If it takes a few ms's SO What?
>
Nothing except it has nothing to do with the discussion at hand...
>
>
> Stick to the topic or go somewhere else...
>
>No one died and left you boss!
>This is a Forum, if you respond, & have something positive to contribute,
>that's fine. If you want to be sarcastic, and make an ass out of yourself,
>you WILL get a rude response.
About that canadian weather question???
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.