My "official" request to top engine programmers

[Ferdy]

Maybe I'm a bit old-fashioned, but... what's the taste of IDeA doing all the work? There's a lot of fun when one makes own analyses, even with engines help.

When you use idea to do the work by itself, you will taste later its analysis.

Example you setup e4 Nf6, then let idea do the work by itself. Later you will just browse the tree produced from idea. It will show you the best possible moves from a given position, it would also show you the 2nd best moves and others. Browsing the trees is also fun. But then again if you don't like it, just disable the automatic engine expansion.

It seems like you are a fun of infinite analysis, you can also send those positions from infinite analysis automatically to idea, so your infinite analysis sessions will not be lost, it is kept there in idea tree. You don't have to repeat your analysis again and again, you can simply load a particular idea session that you have done in the past, it can be alekhine idea or sicilian idea or nimzo-indian idea. Then start from there if you continue to work on it.

[Rodolfo Leoni]

It seems like you are a fun of infinite analysis, you can also send those positions from infinite analysis automatically to idea, so your infinite analysis sessions will not be lost, it is kept there in idea tree. You don't have to repeat your analysis again and again, you can simply load a particular idea session that you have done in the past, it can be alekhine idea or sicilian idea or nimzo-indian idea. Then start from there if you continue to work on it.

I just think infinite analysis is a better tool, but an engine with PHs should be necessary to keep track ov variation scores.

I see IDeA evolved a lot in these years. With a PH engine and multipv mode it could be useful. Does it show engine PV(s) output while on analysis, or just its tree?

[Dann Corbit]

There was a project some time ago that did something like this.
The pv nodes were stored in a database as it played.
These pv nodes were reloaded into hash when the engine was started for the next game.

It was also possible to preload the hash with a huge database of EPD records, if you so desired.

It was called Stockfish PA GTB.

It was too much effort for the author to maintain.

The same thing happens to many other such projects (CFish is a good example).

[Rodolfo Leoni]

There was a project some time ago that did something like this.
The pv nodes were stored in a database as it played.
These pv nodes were reloaded into hash when the engine was started for the next game.

It was also possible to preload the hash with a huge database of EPD records, if you so desired.

It was called Stockfish PA GTB.

It was too much effort for the author to maintain.

The same thing happens to many other such projects (CFish is a good example).

Hi Dann,

that sounds great. A pity author closed the project, but I assume the effort was to mantain the database, rather than updating the engine.

Have you a download link for Stockfish PA GTB and CFish?

Many thanks in advance.

[Dann Corbit]

There was a project some time ago that did something like this.
The pv nodes were stored in a database as it played.
These pv nodes were reloaded into hash when the engine was started for the next game.

It was also possible to preload the hash with a huge database of EPD records, if you so desired.

It was called Stockfish PA GTB.

It was too much effort for the author to maintain.

The same thing happens to many other such projects (CFish is a good example).

Hi Dann,

that sounds great. A pity author closed the project, but I assume the effort was to mantain the database, rather than updating the engine.

Have you a download link for Stockfish PA GTB and CFish?

Many thanks in advance.

The Stockfish PA GTB project is ancient in computer chess terms (6 years since the last update):
https://github.com/jeremybernstein/Stockfish_PA_GTB
I loaded a few million positions into the EPD database. I have a billion positions now, but it already took a long time to load. I think the database should be changed to a memory mapped DB like MonetDB.
FastDB might also work, but the lack of a true unique index gives me pause for FastDB.

[Dann Corbit]

CFish project:
https://github.com/syzygy1/Cfish

[Rodolfo Leoni]

Many thanks Dann, I'll try to compile them. The Stockfish PA GTB is a bit old, anyway. At those times, Critter was possibly a bit stronger. I'm very curious about Cfish.

[Dann Corbit]

Many thanks Dann, I'll try to compile them. The Stockfish PA GTB is a bit old, anyway. At those times, Critter was possibly a bit stronger. I'm very curious about Cfish.

CFish is a lot faster on my machine than Stockfish. Unfortunately, it is also starting to age, so any advantage on speed will be lost to the missing features of the base version of Stockfish.

Just to be clear, CFish is simply a C port of the Stockfish engine. Ronald got tired of patching it every few days.
He also got close to zero testing effort on it.

It is a little bit slower than ASMFish, which is probably why people did not have a driving interest. On the other hand, for platforms that do not have x86 instruction sets, CFish works and ASMFish does not work.

So, for instance, CFish is the blazing fast answer for Android.

[carldaman]

The problem that scores of a variation get lost when you go deeper in a variation, and then return to (before) a previously analyzed one, is not related to persistent hash. The latter only makes it possible to transfer analysis between different sessions with the engine.

What you complain about (and also bugged me, when I started to do thorough analysis) is caused by a bad replacement strategy for hash entries. Most engines number the searches they do, and remember in the hash table which search was responsible for creating a stored entry, or remember what was the last search that actually used the stored information. If they then stumble on entries that are not used in any recent search (sometimes even just the current search), they assume the positions they refer to no longer are reachable from the current root position, and thus useless. They are treated as empty, and immediately overwritten.

This works very well in games, where no take-backs are done. Such as in the games used to determine the rating of the engine. For interactive analysis this is fatal, however: as soon as you go into an alterative variation, and play an irreversible move, all your previous analysis will be purged from the hash table, as the positions are no longer reachable. But of course they remain reachable, through the take-back you will sooner or later do to back-poropagate the score of the newly analyzed variation.

The solution is quite simple: engines should realize that an interactive analysis session is in fact a single search, where the low plies are governed by the user, and the root positions of the various analysis searches are not root positions at all, but just internal nodes of the tree the user is constructing. As such, they should not increment the search number during analysis. They are just not different searches, but part of the larger one.

In my engines incrementing the search number only before searches intended to play in a game ('thinking'), and leaving it as it was in an analysis search, did solve the problem.

Well, you say what I said before, you just say it better.

BTW, are you still developing Joker? I've been away these last years and I need some updates about what works are still in progress.

About technical solution, I have no other reference than Critter example. Richard Vida built Critter session file as a separate, sizeable hash. With this solution he avoided complicated hash handlings and, most of all, file is updated every time a move is made on the board. That means one can resume an analysis when he wants, as all of his wokr was saved. It uses both forward and backward (2 plies) propagation when a score drop is detected. Not a perfect system, but the best I've ever seen.

The problem is, Critter could be 200 ELOs weaker than Komodo and fishes... That's why I'm asking if some top engine programmer is interested in developing this feature.

You'd think this [correct score propagation in the hash] was a top priority for commercial engine developers. I mean, so many people buy an engine for analysis purposes, so why wouldn't they provide an analysis-friendly engine? It makes no sense, other than to surmise that game-playing Elo is mostly everything to them. No wonder we're still in dark ages when it comes to good analysis features. [I do like IDEA, but it's a resource intensive hog of a program, and I prefer to interact with the analysis as much as possible]

As seen above, HGM is aware of the problem, and he even proposed an elegant solution; Richard Vida offered a good solution with his *free* (but now old) engine. If freeware programmers can offer improved analysis 'tools', why won't the top engine developers do the same or better, especially when they charge for their engines and they should 'owe' it to their customers?
Just wondering 'out loud'...

Regards,
CL

Hi Carl,

I agree 100% with your clear and direct opinion. The choice is between self-oriented engines and user-oriented ones. It seems the direction everybody took is the fight for gaining few ELOs per year, and that's absolutely self-oriented. But if we thing an human being will use the engine, we should consider what's most important for him.

To become user-oriented could be next step of engines evolution...

Hi Rodolfo,
you've nailed the nail on its head with your last reply, so to speak.

I have already mentioned the idea of a learning capability for Komodo, over the last couple of years, in this forum, and the authors said they'd consider it. I even brought up the Critter and Stockfish implementations as examples. No sign of such a useful feature, yet, unfortunately.

Now, I get it that adding any new feature would take resources away from improving the engine's base strength, but such new features could be bundled into a 'Pro' version of Komodo, perhaps more tweakable, that could be sold at a premium. Then the extra effort would pay off and many customers would be very satisfied.

Houdini, another commercial program, used to have a 'Learning' feature, but in Houdini 5 it was taken OUT (!) How do you figure that? This is the face of 'progress' in computer chess nowadays: expect very little else other than strict Elo gains - Elo is everything!

CL

[Ferdy]

It seems like you are a fun of infinite analysis, you can also send those positions from infinite analysis automatically to idea, so your infinite analysis sessions will not be lost, it is kept there in idea tree. You don't have to repeat your analysis again and again, you can simply load a particular idea session that you have done in the past, it can be alekhine idea or sicilian idea or nimzo-indian idea. Then start from there if you continue to work on it.

I just think infinite analysis is a better tool, but an engine with PHs should be necessary to keep track ov variation scores.

idea can save variation score if you want to.

I see IDeA evolved a lot in these years. With a PH engine and multipv mode it could be useful. Does it show engine PV(s) output while on analysis, or just its tree?

You can see the ia analysis output, and it will save automatically the position and score of the variation into the idea tree. After mini-maxing the tree, you will have a good idea of what lines may lead to a good score, bad score, equal score and interesting score. You can walk into the leaf from the position you are evaluating and may extend it further if you feel there are still interesting lines to pursue. Your analysis effort is not wasted because they are saved in the tree.