I use 19ply.

But it's not only about move choice, it's also about differing in evaluation. Say, Engine 1 suggests move A with a score of 0.12, and Naum says the score is 0.50. It turns out the variations are very dangerous for Black, and indeed, 0.12 is a too shy score. From the root it doesn't make a difference (move A will be played), but from the distance, it may be critical that you see this variation and aim for it, instead of going for one where Engine 1 suggests an early deviation with 0.24 (twice) the score, which is actually worse.

There's also a factor I'd call "move preferences", that depends on what kind of positions the engine wants to reach. Here's a common scenario of critical positions (keeping in mind critical positions are rare and usually are avoided so they don't appear in the actual game):

All engines, when asked for a move, pick Move A. After interactive examination, Move A is refuted. So, the engines are asked to exclude move A, and give their second preference.
Half the engines suggest move B.
The other half suggest move C.
Naum suggests move D.

Here, Naum's score is very different from the other engines, which forces me to try to refute Naum's idea, and what ends happening is that these engines agree that D is better than C or B. I've found the best move.

People may look at the position and think "all engines pick the same move, nothing to see here", but engine's redundancy requires profundity, and the best engine for the job is only apparent when you ask them for moves when you exclude their initial suggestions (say, most engines have the best move in 5th position, but one has it in 3rd position, this engine has a better understanding of it, even if it's not its first move choice).

Here are two games in where I would have had a drawn result instead of won games if I didn't use Naum, as it was leading the games to victory (at some point, when my advantage was big enough, I had to switch off Naum and put in there a better engine to win the games, but what matters is getting there in the first place).

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=12861
(Core winning idea by Naum)

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=22914
(Here, Naum was showing the right 0.00 in positions where other engines thought white had an edge, then Naum was showing black with slight advantage while other engines thought there was equality, so it was like having analysis from the future)

That said:

- When I tried this with Rybka 2.3.2a back when Rybka 3 was released (and so, 232a had an easier time), 232a failed miserably, either it suggested moves I already had covered, or it suggested "original ideas" that never worked (mainly, passive moves other engines weren't considering, but for good reason.)

- I've never used Strelka.

>Some techniques first published with Ippolit sources became "mainstream" since then. By now most programmers treat them just like killer heuristics, null-move etc.

Can you give some examples?

I would have to say (not intending this as a criticism) that the similarity between Critter and the Ippos is more than just what I call "ideas". When you take formulas with no change (other than rescaling to 256 instead of 100 per pawn) or copy PST or other eval numbers it makes the program a derivative (in some sense anyway) of the other one, and would make Critter ineligible to play in ICGA events, for example. I know you don't intend to do so anyway, and since the program(s) in question are open-source you have done nothing wrong; but it's fair to say that Critter and the Ippos are at least cousins, whereas Houdini and Ivanhoe are more like brothers.
     Critter as well as all of the Ippos share certain traits that are not found in Stockfish or Komodo (or any other programs not suspected of being Ippo-derived). They are relatively much stronger at bullet or hyperbullet chess than at slower play, they tend to stick with the same move from iteration to iteration more than do all other programs, the evals don't swing nearly as much from iteration to iteration in general, etc. I would be most interested in your opinion as to which idea or ideas in Critter and Ippo are primarily responsible for this behavior.
     I think that what has happened with Komodo is that although we could not make Ippo ideas work for us, we found our own ways to accomplish much of what the Ippo ideas do. So in that sense perhaps I should say that Komodo is intermediate between the Stockfish family and the Ippo family.

Komodo and SF have hardly any similarity in evaluation; it is the search that is somewhat similar. I mean we use the same basic techniques for pruning that SF does, and not usually those that Ippo does (when they differ), as well as our own. But the eval determines the move choice in the majority of cases.

We ended up spending too much time on Komodo 4 and not enough on the MP, but now Don will focus on getting it finished. It's partly my fault, because I don't have much to do with the MP version until it's ready for testing, so I tend to get Don sidetracked on ideas to improve the basic program. Yes, my health is fine, the trouble in Netherlands last year was a one-time, non-recurring one. My new opening book is being printed right now and should be in shops in Europe imminently.

> But there might be the line: Fruit-Rybka-Ippolit-Houdini.

Fruit and Ippolit are open source engines, it should be very easy to demonstrate by direct comparison that Ippolit is related to Fruit.
Please do so.

And maybe we should add iris and voiceprint scanners to the Aquarium startup sequence.

You guys are funny. Last I checked, chess was just a board game.

jb

There are so many options, if the goal is simply to protect Vas' IP. Here's just one.

Point of information: According to Richard Vida (Critter) Houdini was quickly RE'd because it's so closely based on Robbolito that there was a simple open-source roadmap for REers to follow.

I think the most useful way to look at this whole question is to start with perfection as a benchmark and then work your way to the state of the art today.  Imagine two engines playing each other.  Player A is using 32-man EGTB and never makes a suboptimal move.  Player B is the Rybka Cluster or whatever other engine/hardware setup you think is currently the world's best. 

Now, over the course of games between these two entities, we know A will never make a move that surrenders a half-point.  (An engine that did play less than perfectly in order to get an opponent into positions he would definitely make a fatal move would be even stronger yet, but let's set that aside for this discussion.) 

Assuming the game of chess is drawn, how many moves would Player B get into the game without giving up a half-point, i.e. going from a drawn position to a losing position?

Let's say it can make 12 moves before it makes a move that loses.  The challenge for the programmer is finding a move that holds the draw.  Until it can do that the ELO difference between A and B is only limited by the ELO formula.  In practicality, the ELO difference is infinite.  If Player B always loses, every single time, then there can be no comparison.

Let's suppose Player B does find a drawing move on move 13.  OK then, how many more moves can it go before it makes another losing move?  And now I repeat what I just said above.

The point is that today's Player B (the strongest chess entity in the world) may make any number of objectively losing moves over the course of a full game.  In order for ELO to be equal with Player A, every single one of those losing moves has to be replaced with a drawing move, otherwise the ELO difference is infinite.  It isn't a question of relative ELO; at the true extremes it is a question of draw or lose.  It is pass-fail.  ELO doesn't enter into it.

Now, needless to say, if there even existed a Player A then Player B, C, D...Z would all rapidly improve.  Because Player A would reveal, though its moves, the correct path in every position.  That information would be invaluable to the competition, and in due course there would be many engines who, through trial-and-error, could find ways to draw Player A.  At that point the ELO measurement would become relevant again.