Evaluate this position.

Readers should run their engines for the following position and give an evaluation:

Thanks for the answer. Let me explain a few things:

1. This position is taken from a current (friendly) engine match of mine.

2. My i7-970 rig (6 @ 4.375 GHz), running Houdini 2.0 Pro thinks that White is about 1.80 better off @ depth 30.

3. My opponent's i7-980x rig (6 @ 3.33 GHz) also running Houdini 2.0 Pro thinks that the position is level @ depth 30

I've removed the FEN, it was for the wrong position.

I don't want any help with strategy etc. just a simple engine generated numerical evaluation.

One of us has a screwed engine, just wondering which one.

I'm not looking to solve the position. My query simply asks for a numerical evaluation, so that I may determine if my engine is screwed. I have lots of engine games ongoing and publish a lot of analysis in our vote chess games here.

If it's my engine that's screwed then I need to know, quick-sharp

However, I'm a suitably accomplished enough player, to know (just by looking at the board) that White is ahead. 

Just a "confidence check".

p.s. What hardware/software combo are you running?

Thanks for the input rooperi.

I've downloaded what I hope to be the latest version of Stockfish and run the position by it:

I'm surprised by a few things:

1. How quickly Stockfish gets to high depth.

2. How different my evaluation is from yours, given same depth and similar software.

p.s. I'm looking at this position now:

Nah, that's not what's happening. Read the analysis posted. 

Yes, I'm quite sure.  Look at my "p.s.".... the position has changed. In the second position it is obviously White to move (or he loses his Queen).

Thanks for the evaluation.

The difference might be caused by the different transposition tables. Also it's possible that during the game your (or the opponents) engine generated the same zobrist key for two different positions and reused the score for the wrong position. These all are "by design".

cokes,

I don't store any positions. For each analysis, I start the interface afresh, enter a FEN string and calculate from there. At the end of the analysis, I shut the whole thing down, even if I wish to continue with another position or indeed, the same position, same engine but different settings (e.g. I play with the contempt).

I'm aware of the sort of errors that can occur (as you've pointed out) with a "warm start". I found out through experience (crazy evaluations etc.) and have never heard of "zorbist key". Care to explain that one?

I see. If you start fresh after each move then it's less likely to get very different results, but, I think, it's still possible. I don't know much about how Houdini works internally, but I'd imagine that all the threads share the same transposition table, so the content of the transposition table depends on how the threads are scheduled to run at the OS level. Also sometimes engines add small random values to the evaluated scores to make games less boring :) and they sometimes randomize move orders a bit to increase the chance of testing moves that would otherwise get cut by one of the pruning techniques. These could all affect the score you get.

Zobrist keys are (usually) 64bit integers generated from chess positions. Every possible board position has an associated zobrist key that the engine can use as a key to look values up in the various hash tables (transposition table, evaluation hash table, pawn hash, ...). Unfortunately, there are way more possible chess positions than 64bit integers, so it's inevitable that different positions get the same zobrist key. If P1 and P2 different positions get the same zobrist key then when the engine stores a value for P1 in a hash table and later tries to look the value up for P2 it'll read the value stored for P1 without realising it. This is very unlikely event, but evaluating enough positions it'll happen eventually (and your supercomputer can evaluate a lot of positions per sec :)). It's a calculated risk. The other option is to generate longer keys, but then engines would be able to store only fewer key-value pairs in the hash tables. Some engines (not sure if Houdini falls into this category) go even further and to save a few more bits per entry (key-value pair) they accept the greater chance of collisions and store only a fraction of the zobrist key in the map leading to more entries, but greater chance of collisions as well.

Not sure if this makes any sense or if it was clear at all, let me know I should go into more detail.

Btw, I think you would be better off if instead of FENs you used PGNs. FENs are used to describe the state of the board, but not how you got there while PGNs have the move sequence. The difference can be significant if you get close to a threefold repetition. Starting from a FEN your engine won't know how many times the positions occurred on the board before and can easily walk into a threefold repetition. Not too likely, but possible.

Also, you can get a nice boost if you can afford not to clear the transposition tables between moves. Might be a bit problematic if there are many days between the moves as your OS will likely to page the transposition table out, but it's still possible that reading a few pages back from disc is faster than reproducing the values that can be reused (some of the transposition table entries computed from the previous moves are useless depending on what the new moves are - for example the score for a knight move cannot be reused after a pawn move as pawn moves are irreversible, so you'll never get back to the same position you had before the knight move, i.e. you'll never need to know again what the score of the knight move is).