user17129: Can the solution to the famous Secretary Problem be applied to the search function of a chess engine? Rejecting the first 37% moves and choosing the best one after that,or maybe even just checking the first 63% of the moves and choosing the best one so far?

user825: No. What if recapturing your queen for an exchange is your first 
candidate move?

user12: The secretary problem is very different from chess move evaluation for several reasons.  First and foremost, the number of chess moves in a given position is finite and usually fairly small (~30 moves in a position).  The second reason is that the cost of choosing a sub-optimal employee is quantifiable and the second best secretary is okay.  In many chess positions there is only one move that is at all reasonable, every alternative will lose the game immediately.
In many chess engines, the most computationally expensive part of determining the best move is generating legal moves.  In the secretary problem, the number of applicants is known.  In chess, once we know the number of legal moves, we have already done some of the heaviest lifting.  
Finally, chess engines already prioritize candidate moves very quickly, the real strength of the engine is selecting the best move out of 2 or 3 moves that have risen to the top of the list.  Chess engines will continue to evaluate all of the legal moves in a position, but they might only go 2 or 3 ply deep for the moves that are less likely to be good moves while searching 40+ ply deep for the moves that are under active consideration.  This is called pruning and its development is one of the main improvements in newer chess engines over the earliest chess engines.  

17129: <p>Can the solution to the famous Secretary Problem be applied to the search function of a chess engine? Rejecting the first 37% moves and choosing the best one after that,or maybe even just checking the first 63% of the moves and choosing the best one so far?</p>
 825: <p>No. What if recapturing your queen for an exchange is your first 
candidate move?</p>
 12: <p>The secretary problem is very different from chess move evaluation for several reasons.  First and foremost, the number of chess moves in a given position is finite and usually fairly small (~30 moves in a position).  The second reason is that the cost of choosing a sub-optimal employee is quantifiable and the second best secretary is okay.  In many chess positions there is only one move that is at all reasonable, every alternative will lose the game immediately.</p>

<p>In many chess engines, the most computationally expensive part of determining the best move is generating legal moves.  In the secretary problem, the number of applicants is known.  In chess, once we know the number of legal moves, we have already done some of the heaviest lifting.  </p>

<p>Finally, chess engines already prioritize candidate moves very quickly, the real strength of the engine is selecting the best move out of 2 or 3 moves that have risen to the top of the list.  Chess engines will continue to evaluate all of the legal moves in a position, but they might only go 2 or 3 ply deep for the moves that are less likely to be good moves while searching 40+ ply deep for the moves that are under active consideration.  This is called pruning and its development is one of the main improvements in newer chess engines over the earliest chess engines.  </p>
