I understand. My point was that I think there are too many doubling decisions considered outside of that 0.160 range, and that skipping over them just because doubling would be a 0.160 blunder is a mistake. Maybe the player(s) will avoid this mistake most of the time, however I think the doubling was considered, and that a decision was made.
The only situation where I think one doesn't need to consider doubles outside of this range is in non-contact races where the chance of such an error is much lower. Just my 2 cents. Albert On 9/5/06, Robert-Jan Veldhuizen <[EMAIL PROTECTED]> wrote:
On 9/5/06, Albert Silver <[EMAIL PROTECTED]> wrote: > (...) The only point where I'd consider tightening up, or leaving it at 0.160 would be in non-contact races where the chance of such large cube mistakes is extremely low. However, for contact positions, I see (and make) so many blunders (WT, WP, MD, etc.) that to skip over them because they are larger than 0.160 is a genuine mistake IMHO. They are not skipped when it comes to adding up the total cube errors value. This discussion is just about counting the number of decisions. Note that GNUBG will always count any actual cube decisions, including wrong doubles that are not close and wrong passes/takes that are not close. So if you double and it's a no double by more than 0.16, the decision will still simply count for one (and any error added to the total because you made an actual decision. Your opponent's decision to take or pass will also count for one (and any error added total). The count is only relevant for the positions where you don't double; GNUBG tries to determine whether it was obvious that you didn't double then by using the 0.16 threshold. It is somewhat arbitrary, but 0.16 doesn't seem unreasonable. There's also many positions, especially in matchplay, where a No Double is a lot closer than 0.16 yet an obvious No Double, so that may compensate a bit for >0.16 No Doubles that may not be obvious. Like Massimiliano wrote, it's hard to come up with something better without introducing all sorts of other problems. -- Robert-Jan Veldhuizen
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
