Move on Hash Hit

[kingliveson]

Ivanhoe is very unstable. I run a chess engine on the ICC, and I used to use Ivanhoe, but I lost too many games to random crashes.

I have tried just about every version of ip* that is available in source form. In a single 30,000 test run on my cluster, where one opponent (say ip* would play 6,000 games) I get hundreds of core.nnn files from the thing crashing. It wins enough games to show it is very strong, but the crashes make it unusable for accurate measurements. And I am not talking about using any of the ip* clones that now have a parallel search. I'm talking about single-process/thread testing only.

That's one problem with derivatives. If the original has bugs and is unreliable, so will all the derivative programs.

Am not sure what the highlighted section means. Are you talking about the original Ippolit released source code or the later version renamed to IvanHoe which source has change significantly?

That's one problem with derivatives. If the original has bugs and is unreliable, so will all the derivative programs.

That is just an inaccurate statement to make.

I am talking about _any_ open-source derivative of ip*. What I tried to explain was that I am _not_ testing using parallel search, which most of these programs seem horribly ill-suited to deal with. I have tested them using a single-thread. So far, not one will play thru its allotted 6,000 games without crashing excessively. Meanwhile Crafty, stockfish, glaurung, fruit, toga, et al play hundreds of thousands of games without a single crash of any kind.

There was no confusion by the type of testing since your test usually does not include parallel search, unless it involves that aspect of the program. May be you are not aware; Ippolit < RobboLito < Igorrit < IvanHoe are development releases of the same program by the same authors.

What is that based on? Who _are_ the authors of IP* and Robo*?

Ippolit is an original chess engine. It stands on shoulders of previous engines; KAISSA, Crafty, Fruit/Toga/Rybka/Strelka. The authors use the following Pseudonyms: Yakov Petrovich Golyadkin, Igor Igorovich Igoronov, Roberto Pescatore, Ivan Skavinsky Skavar, Decembrists, etc. it’s a public domain/open source software, so there are many contributors.

Ippolit was the initial alpha release, and then came RobboLito which fixed many bugs and introduced support for endgame (RobboBases) tablebases. Igorrit was the first multi-core version of the Ippolit program. IvanHoe is the current version in development.

It is clear you have not tested the most recent sources/builds -- because if parallel search means multi-threading, 2, 4, 8 threads are handled well. Of course, it’s still a work in progress like every other beta software.

I have tried several. First ip*. First Robo* and the most recent (at the time) version as well. Each time I have tried one of them on our cluster, I get crashes. Crashes ruin the results and I therefore do not use them.

There is nothing abnormal about beta software being unstable in its early stages.

As far as inaccurate statements go, mine was anything but. If you copy 30,000 lines of code, and that code starts with many errors (which ip* certainly had) then those errors get inherited. Plain and simple...

Again, this statement is simply inaccurate. As already stated, these are not derivatives, at least not in such context, but rather incremental releases of the same program by the same authors. Not unless derivative means Linux Kernel 2.6.35.2 is a derivative of 2.6.34.4.

Your linux statement is _exactly_ correct, for the record. "Derivative" means "derived from" which is true of any two versions of Crafty as well, and it is why I can't enter two crafty versions in the WCCC events, for example.

You’re stretching semantics here a bit. Derivative work usually connotes an individual (not original author) taking and modifying existing works. We are talking about incremental builds of the same program by the same author.

You wouldn’t call Crafty 23.3 a derivative of 23.2. I recall a time management bug during beta testing of 23.3 (inherited or introduced at some point), which later was corrected. It surprises me that you stand by such statement. What then is the purpose of software development life cycle -- I mean you have applied a Kernel patch at one point or another right?!

I've probably applied more kernel patches than you have taken breaths of air. But again, just go to your friendly Webster's and look up "derivative" (and skip the calculus definition of course). "derived from" is the key. Each new crafty version is a derivative of the last one. Ditto for Linux or any other software. And this definitely implies that most (if not all) bugs from the previous version get inherited by the new version except for cases where the new version exists solely to repair one or more known bugs in the previous version.

This has to be a record for an individual -- applying more than 186192000 Kernel patches. I think most would agree derivative is not the proper term, but rather version.

You almost certainly don't play the quantity of games I see or you'd be seeing the crashes as a serious problem too...

I can’t play the same quantity because there is no 24/7 access to a cluster. The few thousands of games played however, have been flawless using most recent IvanHoe.

My objective in life is not to test programs by others, but to test/improve my own. I have not tried Ivanhoe since the previous instantiations had enough bugs to cause me to not want to waste further time. I may give it a whirl at some point in time. I'd be surprised if it can play a full 6,000 games without crashing, since none of the others could get past even 600...

I was quite sure you hadn't tried the most recent sources and figured your statements were directly related to initial testing of earlier less stable releases. When you do find time, you'll see that there’s been major improvement –- which naturally is the progressive course of software development.

No, I have not tested every version. I have tried quite a few that are recommended as functional. Whomever made that classification for the ip* family must work for Microsoft. My standards are quite a bit higher.

My suggestion is to try the latest source using the link posted above or visit Ippolit website.

[kingliveson]

Code: Select all

         /* "PREVIOUS_FAST" is inverse named plus don't too this with UCI_PONDER */
          if (EXACT_DEPTH >= PREVIOUS_DEPTH - 6 && EXACT_MOVE == HASH_MOVE
              && !UCI_PONDER && EXACT_MOVE && PREVIOUS_FAST && PREVIOUS_DEPTH >= 18
              && ALLOW_INSTANT_MOVE && MyOK (POSITION, EXACT_MOVE)
              && Value < 25000 && Value > -25000)
            {
              ROOT_SCORE = Value;
              ROOT_BEST_MOVE = EXACT_MOVE;
              ROOT_DEPTH = EXACT_DEPTH;
              PREVIOUS_FAST = FALSE;
              if (!IsCheck)
           v = MyExclude (POSITION, Value - 50, PREVIOUS_DEPTH - 6, EXACT_MOVE);
              else
           v = MyExcludeCheck (POSITION, Value - 50, PREVIOUS_DEPTH - 6, EXACT_MOVE);
              if (v < Value - 50)
           return;
            }

The question was whether the above code can cause the engine to play much worse, or even blunder with longer time control. I ran 2 50 40/40 repeating time control tournaments -- that's about 10 games per day. Not the fastest CPU; AMD Turion(tm) 64 Mobile Technology ML-37.


AllowInstantMoveFromHash false:

Code: Select all

Rybka vs IvanHoe, 40'/40+40'/40+40'  2010                      

1   Rybka 4 w32        +12/=29/-9 53.00%   26.5/50
2   IvanHoe 9.52b w32  +9/=29/-12 47.00%   23.5/50

AllowInstantMoveFromHash true:

Code: Select all

Rybka vs IvanHoe, 40'/40+40'/40+40'  2010                      

1   IvanHoe 9.52b w32  +13/=26/-11 52.00%   26.0/50
2   Rybka 4 w32        +11/=26/-13 48.00%   24.0/50

Game data available: http://chess.cygnitec.com/pgn/

[hyatt]

Code: Select all

         /* "PREVIOUS_FAST" is inverse named plus don't too this with UCI_PONDER */
          if (EXACT_DEPTH >= PREVIOUS_DEPTH - 6 && EXACT_MOVE == HASH_MOVE
              && !UCI_PONDER && EXACT_MOVE && PREVIOUS_FAST && PREVIOUS_DEPTH >= 18
              && ALLOW_INSTANT_MOVE && MyOK (POSITION, EXACT_MOVE)
              && Value < 25000 && Value > -25000)
            {
              ROOT_SCORE = Value;
              ROOT_BEST_MOVE = EXACT_MOVE;
              ROOT_DEPTH = EXACT_DEPTH;
              PREVIOUS_FAST = FALSE;
              if (!IsCheck)
           v = MyExclude (POSITION, Value - 50, PREVIOUS_DEPTH - 6, EXACT_MOVE);
              else
           v = MyExcludeCheck (POSITION, Value - 50, PREVIOUS_DEPTH - 6, EXACT_MOVE);
              if (v < Value - 50)
           return;
            }

The question was whether the above code can cause the engine to play much worse, or even blunder with longer time control. I ran 2 50 40/40 repeating time control tournaments -- that's about 10 games per day. Not the fastest CPU; AMD Turion(tm) 64 Mobile Technology ML-37.


AllowInstantMoveFromHash false:

Code: Select all

Rybka vs IvanHoe, 40'/40+40'/40+40'  2010                      

1   Rybka 4 w32        +12/=29/-9 53.00%   26.5/50
2   IvanHoe 9.52b w32  +9/=29/-12 47.00%   23.5/50

AllowInstantMoveFromHash true:

Code: Select all

Rybka vs IvanHoe, 40'/40+40'/40+40'  2010                      

1   IvanHoe 9.52b w32  +13/=26/-11 52.00%   26.0/50
2   Rybka 4 w32        +11/=26/-13 48.00%   24.0/50

Game data available: http://chess.cygnitec.com/pgn/

You have a _long_ way to go to answer your question. At least into the thousands of games if not more.

[ThinkingALot]

The question was whether the above code can cause the engine to play much worse, or even blunder with longer time control.

(exact_depth >= previous_depth - 3*Ply) - this condition ensures that there would be no blunder.

[hyatt]

The question was whether the above code can cause the engine to play much worse, or even blunder with longer time control.

(exact_depth >= previous_depth - 3*Ply) - this condition ensures that there would be no blunder.

How? Last move you played took depth=N plies. You quit early if current depth >= N-3??? When normally you would search to depth == N? That can certainly lead to a mistake.

[ThinkingALot]

How? Last move you played took depth=N plies. You quit early if current depth >= N-3??? When normally you would search to depth == N? That can certainly lead to a mistake.

But that's unlikely when exclusion fails low at beta = (value - 50).

[hyatt]

How? Last move you played took depth=N plies. You quit early if current depth >= N-3??? When normally you would search to depth == N? That can certainly lead to a mistake.

But that's unlikely when exclusion fails low at beta = (value - 50).

You are 3 plys short of a full search. Who says it will fail low until near the last iteration? This is a danger of moving quicker than usual. It's a serious danger. There are ways to be more selective in doing this, but it means you will take a normal search time limit more frequently. This is one of "those interesting problems..."

[Richard Allbert]

I have tried just about every version of ip* that is available in source form. In a single 30,000 test run on my cluster, where one opponent (say ip* would play 6,000 games) I get hundreds of core.nnn files from the thing crashing. It wins enough games to show it is very strong, but the crashes make it unusable for accurate measurements. And I am not talking about using any of the ip* clones that now have a parallel search. I'm talking about single-process/thread testing only.

It seams you have problem with Ippolit that causes your later conflicts with logic.
First, your terminology is just wrong. There is no clone or derivative. There is simply a logical development of one program, that has main and some side branches. Main branch is Ippolit->Robbolito->Igorrit->Ivanhoe. And Ippolit passed a really long way from its original (one file) version until the latest Ivahoe v52. On that way an immense number of bugs has been fixed, huge number of features has been added, its own tablebases implementation and support have been added, parallel search and multithreading have been implemented, and strength has been improved for at least 30 elo points. All this in the course of 1 year development. Something that took for example Crafty more than half a decade. And all this without expensive clusters...
Your problem is that a lot of your believes are based on first impressions/tests you make and you keep holding those believes even though the circumstances have totally changed in the meanwhile.

That's one problem with derivatives. If the original has bugs and is unreliable, so will all the derivative programs.

This is just a ridiculous claim. If it was true no bugs would be ever corrected in any program.

As much as I admire the strength of all top engines... this comparison is apples and pears. The features implemented in "one year" are all things known to exist, understood, and implemented in other engines.

Crafty has been at the forefront, developing the "unknown" for a long time.

[Sentinel]

As much as I admire the strength of all top engines... this comparison is apples and pears. The features implemented in "one year" are all things known to exist, understood, and implemented in other engines.

Crafty has been at the forefront, developing the "unknown" for a long time.

That's basically true, however, if you look in detail into the newest Ivanhoe code you will find only things that already exist, are understood and already implemented in other engines. You won't find anything revolutionary new or greatly innovative. Still, you have 3300 elo engine.

[kingliveson]

You have a _long_ way to go to answer your question. At least into the thousands of games if not more.

Examining the code, I came to conclusion that led to the feature's default true setting being set to false on my builds. Then I continued to look at the code and needed more input which prompted this thread. We'll only find out through testing. The small sample posted above did not support my hypothesis, and 40/40 time control is just not feasible since a thousand games will take over 3 months.