Author: Dann Corbit
Date: 18:29:04 01/30/02
Go up one level in this thread
On January 30, 2002 at 21:11:25, Angrim wrote: [snip] >Hmm, this made me stop and think a bit. If you could actually skip >over the positions that are covered by your rule, while still using >the current index based methods, the resulting savings would indeed be >nice. However, I do not see any way to do this. To calculate a >positions index, you need to know how many positions that would >otherwise have been in this file would have been before it in the >file. For the "kings not touching" rule, this can be calculated >directly based on the positions of the two kings. If there is a >way to calculate this for the sliding piece rule, I have overlooked >it. >If you do come up with a practical way to do this, it could make >this whole thread worthwhile :) The permutations are a simple algorithm. I suspect that a bit of math may make such a calculation possible. It is possible that the idea will fizzle. But I would like smart people (like yourself) to give it a bit of thought and perhaps something useful will fall out of it. Forget about the encoding scheme of exactly how a position is stored. It was just Les' way of demonstrating his basic idea. The keen idea is the reduction that comes from looking for a solution and recognition that many different roads all lead to Rome. As a sidelight -- the postions I posted earlier for KQKnn turn out to be uniquely correct (all the generated mates are optimal : none of the Nalimov lookups for the generated mates are shorter than the extrapolated ones by the simple algorithm). It is conceivable that some tablebase files might be optimal or nearly so.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.