At 06:59 AM 9/3/2009, Michael Depreli wrote:
Example:
2-ply World Class 8/0.16 704kb
4-ply 8/0.06 @ 2-ply (skip 3-ply) 1222kb
An increase but it hasn't ballooned to some colossal amount?
Michael
Did you manually construct the 1222 kb file, retaining all 0-ply and 2-ply
evaluations (plus the 4-ply evaluations that gnubg performed)? Unless I'm
missing something, it seems like it would take more than just a few minutes
to manually create this file. Or is this an estimate of how large the file
would be if gnubg were modified to retain all lower-ply evaluations (I
assume that you're using "typical" filters, i.e. your 2-ply filter skips
1-ply pruning and your 4-ply filter skips 1-ply and 3-ply pruning).
My opinion on file sizes is probably different than most people's
opinions. E.g. I had a neutral opinion about eliminating "set analysis
limit" last month, whereas others who posted were strongly in favor of
removing it. Disk usage is cheap these days, but if users want to e-mail
multiple match files to each other, it's not practical for many users to
deal with files larger than a few megabytes (for a long
match). (Compression is always possible, but many people don't know how or
don't think to compress large files before e-mailing.)
Btw, I don't know if this is a bug or a feature but I discovered a way for
you to achieve what you want to do if you normally analyze with pruning off:
1. Start by analyzing with pruning off
2. Turn pruning on, re-analyze (the analysis should be instant because it's
not re-evaluating anything)
3. Turn pruning back off, change the move filter (either more or less
rigorous), and re-analyze; the new analysis seems to be based on the new
move filter.
I haven't tried to figure out what gnubg is doing, so I don't know if this
is a bug or a feature.
Chris
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
