OpenChess

Is move on hash hit (or move on ponder hit) a good idea? Seems it might be beneficial for fast games, but could be disadvantageous with longer games. IvanHoe uses the following condition:

Here is my thought. That code is about the biggest pile of sh** I have seen. Too many special cases that might not fit very fast games, or very slow games, or very fast hardware, or very slow hardware. Simply looks ridiculous... For example, what is magic about the "magic number of 18" for the depth test???

hyatt wrote:Here is my thought. That code is about the biggest pile of sh** I have seen. Too many special cases that might not fit very fast games, or very slow games, or very fast hardware, or very slow hardware. Simply looks ridiculous... For example, what is magic about the "magic number of 18" for the depth test???

Actually, the code might not look pretty, but is quite effective, and I wouldn't call it sh** just because I don't understand it.
18 is not a magic number at all. Since it is in 2ply, the is effective depth 9 which is reached in practically any kind of TC. So the condition is not there only to prevent hash hits at extremely low depth (which it also does), but to prevent (limit the number of) multiple hash hits in a row.

Sentinel wrote:

hyatt wrote:Here is my thought. That code is about the biggest pile of sh** I have seen. Too many special cases that might not fit very fast games, or very slow games, or very fast hardware, or very slow hardware. Simply looks ridiculous... For example, what is magic about the "magic number of 18" for the depth test???

Actually, the code might not look pretty, but is quite effective, and I wouldn't call it sh** just because I don't understand it.
18 is not a magic number at all. Since it is in 2ply, the is effective depth 9 which is reached in practically any kind of TC. So the condition is not there only to prevent hash hits at extremely low depth (which it also does), but to prevent (limit the number of) multiple hash hits in a row.

For the record, I didn't call it sh** because I _didn't_ understand it. I called it sh** because I _did_ understand it. As I clearly said, "magic numbers" are generally bad. Particularly if they apply to depth. Testing "prev_depth" does not look reasonable when trying to decide what to do now. There might be effective ways to choose to "move now" but that does _not_ appear to be one of them. This is a _very_ dangerous idea, in general, because it opens a door to overlook something you'd not overlook with a normal search. If any of this "family" of programs was reliable, I'd be happy to test and and most likely be able to say what this costs in dropping Elo. But the entire family is too unreliable and crashes too often to make accurate Elo measurements possible on my cluster. If you like the idea, fine. But that doesn't mean it works until it has been thoroughly tested. With these programs I don't see how that is possible.

hyatt wrote:

Sentinel wrote:

hyatt wrote:Here is my thought. That code is about the biggest pile of sh** I have seen. Too many special cases that might not fit very fast games, or very slow games, or very fast hardware, or very slow hardware. Simply looks ridiculous... For example, what is magic about the "magic number of 18" for the depth test???

Actually, the code might not look pretty, but is quite effective, and I wouldn't call it sh** just because I don't understand it.
18 is not a magic number at all. Since it is in 2ply, the is effective depth 9 which is reached in practically any kind of TC. So the condition is not there only to prevent hash hits at extremely low depth (which it also does), but to prevent (limit the number of) multiple hash hits in a row.

For the record, I didn't call it sh** because I _didn't_ understand it. I called it sh** because I _did_ understand it. As I clearly said, "magic numbers" are generally bad. Particularly if they apply to depth. Testing "prev_depth" does not look reasonable when trying to decide what to do now. There might be effective ways to choose to "move now" but that does _not_ appear to be one of them. This is a _very_ dangerous idea, in general, because it opens a door to overlook something you'd not overlook with a normal search. If any of this "family" of programs was reliable, I'd be happy to test and and most likely be able to say what this costs in dropping Elo. But the entire family is too unreliable and crashes too often to make accurate Elo measurements possible on my cluster. If you like the idea, fine. But that doesn't mean it works until it has been thoroughly tested. With these programs I don't see how that is possible.

There shouldn't be any issue testing latest version of IvanHoe. I have ran thousands of games without problem. As for the condition above to determine move now in order to gain time advantage, it looks as if there might be benefit for short blitz games. But longer time control, it looks to be a recipe for blunder.

On-the-other-hand, because the condition prevents consecutive "move now/fast move," one could argue that with long time control games, and the behavior not being sequential, the engine would have searched tree deep, storing enough info to prevent blunders...Just something to ponder for now as there are no pro/con data.

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.

terrigood wrote: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.

hyatt wrote:

terrigood wrote: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.

hyatt wrote: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.

kingliveson wrote:

hyatt wrote:

terrigood wrote: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.

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

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

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.