Author: Ricardo Gibert
Date: 16:11:28 01/30/02
Go up one level in this thread
On January 30, 2002 at 18:29:45, Dann Corbit wrote: >On January 30, 2002 at 18:21:07, Ricardo Gibert wrote: >>Too keep things simple, let's assume it takes them 200 bits to store 1 >>particular position. What they are saying is, "Oh look! That's really 4 >>positions when we include reflections and rotations! It takes 200 bits for the >>first position and we get the next 3 for free - 0 bits! That's an average of >>(200 + 0 + 0 + 0)/4 = 50 bits per position!" >> >>True. Unfortunately, it is still 200 bits per unique position. They're counting >>things up in a non-standard way. They can justify this, since their "new" idea >>is to expand the equivalence class that includes reflections and rotations to >>include more positions by trading optimal play for suffiently strong play. In >>this case, counting in this way is not unreasonable for comparison purposes. >> >>Their ideas can be made to "work" for EGTBs, but I don't think it will reduce >>EGTBs when they are in uncompressed format. It can be used to enhance the >>compressability of them, however. Another problem is it will be computationally >>prohibitive to generate such EGTBs and thus limit their utility for such EGTBs. > >If an EGTB were compressed with (for instance) strong arithmetic compression, >then most of the order will be squished out. In theory, all tablebase files >will compress into this single "pill size" object -- whatever it is. However, >in practice, you will see better compression when the starting object is smaller >if it contains the same information. Consider (for instance) a long binary >string of 1's and 0's verses the same character string. > >>Unlike in endings where we can content ourselves with an upper bound on the >>number of moves to win, in middle games and openings we are generally only >>interested in best known play. The trade for optimality for sufficiency is not a >>doable trade there. > >These tablebase files can be generated from an existing table base file. > >Or (tangentially) alpha-beta files can be created from analyzed chess positions. > So that you would know "this position is not worse than..." by doing a lookup. >This idea sounds pretty silly (the alpha-beta files) but it might be worth a >look in the opening phase or the mid-endgame. Some of your commentary looks like it was inserted into the wrong post by mistake to me. I can't tell if you are agreeing or disagreeing with much of what I wrote. In any case, I would just like to add that the idea of maintaining a database of middlegame positions is not reasonable, since the astronomically low hit rate does not justify the even tiny amount of time expended trying to look them up. Too many possible chess positions and too little memory relatively speaking. Not even having 1 position represent an equivalence class of a hundred or so positions changes this.
This page took 0.01 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.