Jos? Carlos:
>Yes, distance to conversion sounds like a good idea.
>But I think it also has flaws: after the conversion, the position might be
>a mate in 51, so it should be considered draw, also before the
>conversion.
Correct. Uri said how to do it.
>Maybe all of this is solvable or very rare to be important...
I think it is solvable, and even not that hard.
When you and Uri used "conversion", it has to include pawn moves, too. Sometimes, this is called DTZ - distance to zeroing move, because conversion and pawn moves zero the 50 moves counter. As a byproduct, this yielded in an idea, that even saves lots of recources compared to the Nalimov generator, that was available some time ago at Hyatt's site. You can consider all pawn positions as different TBs. Instead of KPK you start with KP(h7)K, and work backwards until KP(a2)K and consider it as 48 different TBs. (In reality, one might only have 24 different ones here, and it is also a bit tricky to code, because of all the symmetry, that is used). Instead of needing the whole TB in RAM somehow for efficient generation, one "pawn slice" will be enough now. Of course it won't matter for KPK, but for the larger ones.
Cheers,
Dieter