buggnubg - Bugs: bug #4408, A few suggestions for...

 
 

bug #4408: A few suggestions for rollouts/small bugs

Submitted by:  None
Submitted on:  Tue 22 Jul 2003 07:35:25 AM UTC  
 
Originator Name: Ian DunstanOriginator Email: -unavailable-
Item Group: Feature RequestCategory: Rollouts
Release: 0.14-develPrivacy: Public
Operating System: Windows XPOS Type: None
Processor Type: NoneSeverity: 3 - Normal
Open/Closed: ClosedAssigned to: Jim Segrave <jsegrave>
Priority: 5 - NormalStatus: Fixed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 12 Oct 2003 06:31:40 PM UTC, comment #11:

Item (2) is on Jim's todo list -- I've created a new bug entry for it.

Ian, next time: please make a new bug submission for each bug/feature request.

Joern Thyssen <thyssen>
Project Administrator
Sun 12 Oct 2003 09:53:19 AM UTC, comment #10:

Is this bug report still open?

I've just fixed item (3), and (1) and (4) should be "fixed". But what about item (2) above?

Joern Thyssen <thyssen>
Project Administrator
Thu 24 Jul 2003 01:22:36 PM UTC, comment #9:

Yes, this looks great.

Presumeably, the 'n/a' tag would be free to change between ND, DT or DP as the rollout progressed (just as 1r and 2r do). In the first few trials it could conceivably swap around quite a few times, simply following the dictates of variations in equity.

Anonymous
Thu 24 Jul 2003 12:17:45 PM UTC, comment #8:

(I hope the columns come out correctly - I hate web forms for text entry, particularly ones that reformat text)

The 'r' and 's' after the ranking indicate if the move/decision is
still being rolled out ('r') or has been stopped 's'.

I am thinking of always showing three lines:

ND - label 'Centered 1 cube' or 'Player xxx owns 2 cube'
DT - label 'Player yyy owns 2 cube' or 'Player yyy owns 4 cube'
DP - label 'Player yyy drops'

The status flag of DP, when it displays) will always come out as 's'.

The change between rolling out a double vs. rolling out a take would
be:

1) the progress window would show the taker's equity/mwc, rather than the
doubler's equity. I find it odd that a take decision displays
positive equities in the rollout progress window which become
negative when the rollout ends and it's moved to the annotation
window.

2) If you're rolling out a take decision, the ND line will be
displayed, but will have the ranking set to 'n/a', since you'd need
a time machine and some threats to turn a double back into a
no-double.

3) The ranking of choices for a double decision is between ND and the
least favourable of DT and DP. The jsd of the ranking will reflect
the jsd between ND and the least favourable choice. The most
favourable (and hence the choice the opponent should avoid) will
get a ranking of 'n/a'). Examples:

I. Doubling too early:

centered 1 cube .... +0.52 1 r

player opp owns 2 cube .... +0.35 2 r
j.s.d. <= vs. no double

player opp drops ... +1.00 n/a s
j.s.d <= vs. no double

II. A correct D/T:

centered 1 cube .... +0.87 2 r
j.s.d. <= vs double/take

player opp owns 2 cube .... +0.93 1 r

player opp drops .... +1.00 n/a

III. A correct D/P:

centered 1 cube .... +0.85 2 r
j.s.d. <= vs double/pass

player opp owns 2 cube .... +1.67 n/a
j.s.d. <= vs. double/pass

player opp drops .... +1.00 1

IV. Too Good to Double:

centered 1 cube .... +1.93 1 r

player opp owns 2 cube .... +3.43 n/a
j.s.d. <= vs. no double

player opp drops .... +1.00 2 s
j.s.d. <= vs. no double

Whereas if you're rolling out a take, you get the same 3 lines, but
the no-double first line is always 'n/a' and the ranking can only pick
the take and drop decisions. The j.s.d. will always be the same as the
s.d. of the take decision. We'll rollout the no-double as long as we
are still rolling out the take (so that the data will be available for
the examining the double decision). And, as mentioned before, equities
and results will be presented in terms of the taker, not the doubler.

Jim Segrave <jsegrave>
Project AdministratorIn charge of this item.
Thu 24 Jul 2003 11:38:49 AM UTC, comment #7:

Re: first:

gnubg doesn't analyse beavers... But your "sharing" of the result may be the first step towards support.

0..N N+1 N+2 N+3 N+4
prev ==> double ==> beaver ==> take/drop ==>roll
moves play1 (double) play1 play1
play0

N+1 and N+2 can be shared, but N+3 can only be shared for money play. Fortunately there are no beavers in match play!

For N+1 we need both the ND and DT numbers. FOr the N+2 we only need the DT numbers, and for N+3 we also only need the DT numbers.

For the racoon decision (N+3) we actually need both "drop", "take", and "raccoon", but "drop" is trivial and "raccon" is equal to 2 * "take" since the only difference between "racoon" and "take" is the value of the cube -- the cube ownership is unchanged.

Joern Thyssen <thyssen>
Project Administrator
Thu 24 Jul 2003 11:11:29 AM UTC, comment #6:

A few more thoughts on this matter for your consideration:

Re: Second

I think the rollout progress window needs to be completely uniform. It is somewhat perilous to manually "invoke" the rollout for ND vs DT, or DT vs DP or, etc. The reason I suggest this is that it's very difficult to guage some positions. Eg., you might start a rollout with the impression that it's a close Take/Pass decision and find out it really wasn't even a Double. Leaving it up to Gnubg's evaluation of the position and defaulting to certain display windows, isn't a good idea either, IMO.

I've changed my mind about the static display idea for DP and think it's worth seeing in every Cube decision rollout. It now becomes interesting whether it gets a 1R, 2R, or 3R ranking (does the "R" stand for "rollout in progress" or "ranking"?). Ie., if the rollout equities indicate a close Take situation, it might be appropriate to have the static display, DP, with a 2R ranking. 1R would go to DT, even though it had a lower equity. With the current build logic, DP would seemingly come out on top as the "best" decision.

Re: Third

As of the latest build, extending rollouts for Cube decisions seems to be working fine (first impressions). Great work as usual.

Re: Fourth

The logic that you have come up with looks ok to me (as does Mr Thyssen's).

Anonymous
Wed 23 Jul 2003 12:00:55 PM UTC, comment #5:

I'm looking at doing a few things:

First:
Combining the analysis of a double/redouble with that of the subsequent take/pass play. There's no reason to do two analyses of what is essentially a single position.

Can anyone tell me how gnubg currently handles beavers etc.? I assume that the game record becomes

0..N N+1 N+2 N+3 N+4
prev ==> double ==> beaver ==> take/drop ==>roll
moves play1 (double) play1 play1
play0

Under my proposals N + 1, N + 2 would each have cube
decision evaluations stored. N + 3 would simply point back
at the cube decision evaluation for N + 2

Second:

Change the rollout progress window to reflect whether it's
been invoked for the double or the take decision. If it's
for a double, there should be three lines displayed:

ND/DT/DP.

DP is a static display with w/wg/wbg/lg/lgb 1.0 0 0 0 0 0. Standard deviations are 0.0 The status will always show it
as being stopped.

If the rollout is invoked for a take/drop, the window will
show the same 3 lines, the ranking for ND will be "n/a".

Third:

Fix things so that evaluations of cube decisions are passed
the previous values (at the moment, you can't extend a cube
decision rollout).

Fourth:

I can change the logic in the rollout code to handle cube
decisions in a different manner to chequer play decisions.
The logic should be (I think):

Stop the ND rollout when both of the following are met
(equities here are done from the doubler's point of view):

1) jsd(Eq(ND) - Eq(DT)) < abs(Eq(ND) - Eq(DT))/jsd limit

and

2) std(Eq(ND)) < abs(Eq(ND) - Eq(DP)) / jsd limit
This works because jsd(Eq(ND) - Eq(DP)) = jsd(Eq(ND)) =
std (Eq(ND))

Stop the DT rollout when the following are met, (again
using the equities from the doubler's poitn of view):

1) jsd(Eq(ND) - Eq(DT)) < abs(Eq(ND) - Eq(DT)) / jsd limit

and

2) std (Eq(DT)) < abs(Eq(DT) - Eq(DP)) / jsd limit
The same argument allows us to use the std of DT.

And point 4 of previous comment, forcing cubeful evaluations for cube rollouts was committed Tue Jul 22 14:29:09 GMT

Jim Segrave <jsegrave>
Project AdministratorIn charge of this item.
Wed 23 Jul 2003 08:45:09 AM UTC, comment #4:

Re 2) The rollout routine is so general that it even doesn't know that it's doing a cube decision rollout. It will break the generality if we introduce a flag or anything to indicate that this is a cube decision rollout. In fact, you can even use the routine to roll out a cube decision simultaneous with chequer play decisions, or roll out two different positions simultaneously.

By introducing a pseudo-rollout for DP then we could apply the same logic as for chequerplay decisions, thus keeping the generality of the rollout routine. That is, you formula becomes:

REPEAT rollout_trials UNTIL magnitude[DP - ND] > 1.96*jsd(DP,ND)

The sd for DP is trivially 0 leading to jsd(DP,ND)=SD(ND), essentially producing the same formula as yours, but keeping the general framework.

Joern Thyssen <thyssen>
Project Administrator
Wed 23 Jul 2003 08:01:28 AM UTC, comment #3:

1) Sorry guys, I thought I knew most of Gnubg's options (but then again, it changes nearly every day, so keeping up isn't easy :), but being able to set the number of dp in the output slipped right passed me. Having stated that, I've now looked at the option and I can't change the setting away from 3dp. It let's you enter another number, but it won't actually implement the change.

2) A few thoughts... along with checking that the jsd between ND and DT, also check the following:

REPEAT rollout_trials UNTIL magnitude[1 - ND] > 1.96*StDevND

and also

REPEAT rollout_trials UNTIL magnitude[1 - DT] > 1.96*StDevDT

(2 wines later, I think the above logic works :)

I don't know the architecture of your softawre, but it occurs to me that the value 1.000 doesn't have to be a dummy rollout (just a stored value somewhere) and since the StDev's are calculated after each trial it might not be too hard to do a running comparison, keeping the rollout going, until all three conditions are satisfied (ie. ND vs DT, DT vs 1.000, ND vs 1.000). The value 1.96, used above, could be altered depending on what the setting for "Number of jsd's from best move " is set at.

3) No worry really. I suspect it will be one of those problems that disappears, almost of it's own volition, when something gets changed. I was mainly just wanting to support Ian Shaw's observations.

Thanks,

Ian.

Anonymous
Tue 22 Jul 2003 01:58:58 PM UTC, comment #2:

Re 2): I don't know how well this fits into the new framework, but you should really be interested in 2 or 3 jsd's: (a) between ND and DT, (b) between DT and DP, and (c) between ND and DP.

You can stop the ND rollout if (a) and (c) are small enough and the DT rollout when (b) and (c) are small enough. This should work all cube decisions, but I don't know how well it fit's into the current framework. A possible (ugly) hack is to introduce a dummy DP rollout that just returns the equity +1...

Joern Thyssen <thyssen>
Project Administrator
Tue 22 Jul 2003 01:47:00 PM UTC, comment #1:

1) no. of decimal positions:
123456789012345678901234567890123456789012345678901234567890
This should use the settings from the 'set output digits
nn' command (or Settings->Options->Display->Number of
Digits in Output). It uses the same output routines as the
export and annotation windows.

2) Needs some thought.

3) Rollout settings being repeatedly reported:

I can't reproduce this with a build from 21 July. I did fix
a typo and the display so that it will report the j.s.d.
choice with 3 decimal places.

4) Good point.

Since rollouts always work with a copy of the rollout
window, it's easy to force everything to cubeful in the
copy when it's a cube decision rollout without affecting
the general window (so the next rollout will still be cubeless).

1, 3, 4 are either non-issues or will be fixed by a commit
sometime today

Jim Segrave <jsegrave>
Project AdministratorIn charge of this item.
Tue 22 Jul 2003 07:35:25 AM UTC, original submission:

1) Not a big deal, but I liked (maybe I just got used to)seeing 4 dp in the rollout w/g/bg fractions and equities, perhaps because I tend to look at 0.5182 and prefer to think in terms of it being 51.82%.

2) More importantly, the jsd option works well for a Double/No Double decision, but doesn't help us decide about a Take, or, "Too Good to Double" decision. To do this we need to be able to compare the cubeful 1-cube and 2-cube equities to 1.0000 and keep the rollout going until the issue is clear.

3) The GNU backgammon messages to do with jsd options that keep coming up, whether you've actually changed anything or not, are a bit annoying. Ian Shaw mentioned one in an earlier post, but this has recently been joined by another one starting with: "Rollouts (or rollouts of moves) more than 2 .... ". They won't go away.

4) If you use the "Rollout" tab in the Hint window and you have a cube decison position, the rollout done may now get done cubeless (ie. if the general window rollout setting is set at cubeless), ultimately causing the output to be rubbish. In the past, the rollout would automatically become cubeful, regardless of how other settings were configured. Reinstating this idea would be good I think, making sure that the general and early/late, trucation point window settings all changed to cubful automatically.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 3 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 12 Oct 2003 06:31:40 PM UTCthyssenOpen/ClosedOpen=>(Error - Not Found)
  Assigned toNone=>NA
  StatusNone=>(Error - Not Found)

Back to the top


Powered by Savane 3.1-cleanup1