|
| From: | Robert-Jan Veldhuizen |
| Subject: | Re: [Bug-gnubg] unwanted extension of rollouts |
| Date: | Thu, 07 Aug 2003 00:43:14 +0200 |
At 10:42 8/5/2003 +0000, you wrote:
On Mon, Aug 04, 2003 at 11:13:35PM +0200, Robert-Jan Veldhuizen wrote > At 06:38 8/4/2003 +0000, you wrote: > >On Mon, Aug 04, 2003 at 12:21:24AM +0200, Robert-Jan Veldhuizen wrote > >> > >> Well it's not a big deal, but I think it would be nice if GNUBG itself > >> detects whether an old rollout should be resumed, or a new one should > >> start. > > > >As a user I hate these "magic" things where the program tries to guess > >what's best for me! I want to decide things myself! I'm aware that this > >is not the mickeysoft way to do things... > > Well I agree with that, but I don't think this is about guessing, just > about detecting whether settings have changed. > > > >A lot of other changes to the rollout settings may be compatible or > >almost-compatible for a resume. > > I strongly disagree. Changing settings and then merging results with an > older rollout seems completely useless to me. No, I don't agree. Here are some examples of settings that a compatible (or near-compatible): quasi random dice / no quasi random dice variance reduction / no variance reduction truncation at bearoff database / no truncation at bearoff database etc etc Also, it rarely matters whether you play cubefully or cubeless, so it don't think it will destroy a rollout if you change chequer play from cubeful to cubeless.
Why would anybody ever want to do a rollout with different settings like these for different trial numbers?
I really can't see any practical purpose for it, and I think it's a REALLY BAD idea if anyone tried this.
The idea of a rollout is that you get a reliable answer I'd think. If one doesn't want variance reduction f.i. he can do a rollout without it, otherwise he can do one with it. What's the point of mixing the two? It just makes the end result less reliable.
> With all the rollouts I've done with GNUBG, I have never wanted to mix > rollouts with different settings, as this is almost guaranteed to give > bogus results. Yes, but it is the "almost" I'm worried about. I would be p***** if gnubg erased my rollout if I just had forgot to activate truncation at bearoff.
GNUBG would only erase if you *changed* settings.
> > > Personally I strongly prefer the current > >implementation where your have to erase the rollout before starting a > >fresh one. > > I think it's not very consistent. If I press 3-ply I also get 3-ply right > away. Yes, that's because it's not possible to extend or resume a 3-ply evaluation.
I think you don't get the point here. When I set up rollout settings, one by one, I don't want GNUBG to overrule me and extend an old rollout.
When I press 3-ply, GNUBG erases any rollout that was there, without asking. So when I press rollout, why not do a rollout without asking or worse, start an old rollout with settings I haven't even made?
Why not a seperate "extend" button? I don't want a program to guess what's best for me. Worse, GNUBG now guesses it wrong 95% of the time and extends an old rollout while I want a new one.
Or, if it is really such a big deal that a user who changes settings might lose his old rollout (isn't that obvious to the user anyhow?), then add "are you sure?" buttons for erasing all results, including 0- to 4-ply which right now get discarded right away, just as one loses a rollout result when pressing the evaluation.
Anyway, I think resuming a rollout I quite obviously don't want is very weird logic (actually exactly the Mickeysoft thing you hate) and not consistent, and certainly not letting the user decide what to do.
It also seems that the way things work now is not transparent at all. You seem to be thinking the new settings will be used for extending a rollout, which is what I thought too, but from Jim I understand all settings changes the user made are pushed away, the old ones from a rollout restored, and then the actual settings popped back after the rollout. Note that the user has no obvious way of telling what's going on here really.
This is so confusing to any user that I think it showes the inconsistency of the whole approach IMO.
In fact one doesn't even know the settings of the current resumed rollout and has to do an export to tell what GNUBG is doing.
I really really hope this gets changed, as I feel pretty confident I'm not the only one who doesn't like this automagical resumes with OLD settings.
--Robert-Jan (Zorba on FIBS)
| [Prev in Thread] | Current Thread | [Next in Thread] |