Nortitle wrote:No. If I'm using it only for move ordering, I'm calling the move generator anyway, so storing the index is sufficient. Similarly if I were storing evals and using the stored eval for improved alpha/beta bounds, I'd be calling the move generator anyway. The only case where you can *save* a call to the move generator by storing the full move is when you can actually re-use the previously computed eval and *not* do the search (i.e. the previous eval was from a search to the appropriate depth and its fail-high/fail-low flags don't prevent you from re-using it). I don't think this is as common a scenario as you guys think.
I actually used to do it the more common way, then I switched to my "minimal TT entry" approach as an experiment. Experimentation revealed it is beneficial in some situations and detrimental in others. It's not as clear-cut as you are claiming. It depends on the position. In an endgame where there are a lot of transpositions, a TT that stores rich information is beneficial. In a complex middlegame position, it doesn't pay off that much, i.e. you don't have as many true transpositions. Also it depends how deep you're searching. In fast time controls, you probably won't fill up a billion-entry TT table anyway, so a smaller-number-of-entries/richer-entries approach is better. But for deep analysis you do want to keep billions of entries and my "minimal TT entry" approach starts to pay off.
Rich
If you store the best move in the TT you can save the move generator call, you only need to validate that the TT move is actually (pseudo-)legal in the current position to avoid a crash. Then you simply search the TT move without ever calling the move generator, and only if the TT move does not cause a cutoff you continue with normal search by calling the move generator, not forgetting to remove the TT move from the move list to avoid searching it twice.
That's what almost everyone does at least.
And I do not believe that always calling the move generator is really faster than doing what I wrote above but with a slightly larger TT entry size (9 instead of your 8 bytes) and therefore a slightly smaller number of TT entries (90% compared to your case).
Sven