bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Bug-gnubg] Wrong cube errors categories in analysis statisticspanel


From: Albert Silver
Subject: RE: [Bug-gnubg] Wrong cube errors categories in analysis statisticspanel
Date: Thu, 2 Oct 2003 10:06:29 -0300

I presume there is something wrong with the mail server since I'm
receiving multiple copies of the messages from the mailing list. The one
below for example came exactly 12 times(!!) to my Inbox. I counted them.

                                                Albert

> -----Original Message-----
> From: address@hidden [mailto:bug-gnubg-
> address@hidden On Behalf Of olivier croisille
> Sent: Wednesday, October 01, 2003 9:08 AM
> To: address@hidden; address@hidden
> Cc: address@hidden
> Subject: Re: [Bug-gnubg] Wrong cube errors categories in analysis
> statisticspanel
> 
> I'm computer-litterate but hopelessly useless when it comes down to
> programming/coding, so I'll leave the 'technical' part of the
discussion
> for
> you to discuss with Jorn et al.
> 
> So, back to practical things as far as I'm concerned. I think our
> discussion
> illustrates the proverb "le mieux est l'ennemi du bien" as they say in
> French, no idea of the exact translation, if any, means something like
> "wanting to do something even better might just end up doing harm to
what
> was already quite good".
> 
> Obviously no offence intended, I have too much respect for gnubg
> developpers, but IMHO we should just set back to former analysis
doubling
> categories, that were perfectly satisfactory for all *practical*
purposes
> and were not buggy (doubling error wrongly classified, see first post
of
> the
> thread and  its attachment)
> 
> Granted, in theory, it lacked analyzing players' doubling strategy
around
> CP. But, again, in practical terms, the CP information is of very
limited
> value-added, and just adds confusion :
> 
> - first, as Holger correctly stated, there is no such thing as a a
'Wrong
> double around cash point', so this stats line should disappear.
> 
> - now, what about 'Missed double around cash point"? Again, from a
> practical
> point of view : why would a player carry on playing around his CP?
Surely
> he
> knows he has a double - otherwise, I should urge him to read
Robertie's
> 501
> three times in a row :-)) - because around CP his position must make
him a
> large favorite in the game. So, if he plays the position instead of
> cashing
> it, in his mind it HAS to be a 'too good' problematic and reasoning.
OK, I
> realize my explanation is a tad tedious, but I hope you'll get the
> picture.
> My point is 'Missed double around cash point", even if this is
> theoretically
> incorrect, should be merged with 'Missed double around TG', as was the
> case
> before, because in essence they refer to exactly the same nature of
> decision
> by players. Actually, since it was the cashing decision that was
correct
> and
> missed, it even should be the other way round : it is 'Missed double
> around
> TG" that should be merged into 'Missed double around CP'
> 
> So I suggest getting back to former categories...
> 
>                                       GNU                  FRENCHKISS
> Missed doubles around DP              0                    0
> Missed doubles around TG              0                    0
> Wrong doubles around DP               0                    0
> Wrong doubles around TG               0                    0
> 
> - and, yes, I chose on purpose a game where I made no mistake, wasn't
that
> easy to find :-) -
> 
> ... but renaming 'Missed doubles around TG' in 'Missed doubles around
CP',
> because again this illustrates better the nature of the decision that
had
> to
> be made. But for the same reason I would leave 'Wrong doubles around
TG'
> untouched, because here the position was indeed too good.
> 
> Olivier
> French Kiss on GG
> 
> 
> >From: Jim Segrave <address@hidden>
> >Reply-To: address@hidden
> >To: Holger <address@hidden>
> >CC: olivier croisille <address@hidden>,
address@hidden
> >Subject: Re: [Bug-gnubg] Wrong cube errors categories in analysis
> >statistics panel
> >Date: Wed, 1 Oct 2003 02:09:16 +0200
> >
> >
> >Warning - from someone whose theory is less than awe-inspiring"
> >
> >
> >Imagine MSC as a line, increasing in value left to right:
> >
> >
> >You lose------------------------------------------------You win
gammon
> >                 DP               CP        TG
> >          1      |   2        3   |   4    5 | 6
> >
> >The numbers represent regions of MWC.
> >
> >So for each region, the limits and associated errors:
> >
> >1 = MWC < DP, error:
> >     double:    wrong double around DP
> >         no double: no error
> >         take:      no error
> >         drop:      wrong drop round DP
> >
> >2 = DP < MWC < .5 * ( DP + CP)
> >     double:    no error
> >         no double: missed double around DP
> >         take:      no error
> >         drop:      wrong drop round DP
> >
> >3 = .5 * ( DP + CP) < MWC < CP
> >     double:    no error
> >         no double: missed double around CP
> >         take:      no error
> >         drop:      wrong drop round CP
> >
> >4 = CP < MWC < .5 * (CP + TG)
> >     double:    no error
> >         no double: missed double around CP
> >         take:      wrong take around CP
> >         drop:      no error
> >
> >5 = .5 * (CP + TG) < MWC < TG
> >     double:    no error
> >         no double: missed double around TG
> >         take:      wrong take around TG
> >         drop:      no error
> >
> >6 = TG < MWC
> >     double:    wrong double around TG
> >         no double: no error
> >         take:      wrong take around TG
> >         drop:      no error
> >
> >Re the other questions
> >
> > > Does someone know why getMatchPoints() does this and whether this
is
> > > intended?
> >
> >I can't reproduce this.
> >
> >From today's CVS, gdb output reformatted for ease of readability:
> >
> >Breakpoint 2, TheoryUpdated (pw=0x899c740, ptw=0x899b900) at
> >gtktheory.c:331
> >1: aaarPointsMatch = {{{0.42115128, 0.328579843},
> >                       {0.589850724, 0.589850724},
> >                   {0.759432137, 0.767605424},
> >                       {0.947443664, 0.767605424}},
> >
> >                      {{0.240567863, 0.232394576},
> >                       {0.410149246, 0.410149246},
> >                       {0.57884872,  0.671420157},
> >                       {0.808395922, 0.671420157}}}
> >(gdb)
> >
> >And for player 0 in the Market Window, I see the values exactly as
> >reported above, converted to percentages. There's no swapping
visible.
> >
> >For those who want to test this, this is from:
> >
> >     GNU Backgammon  Position ID: sLnJAEzYvg0ICA
> >                     Match ID   : cInxAAAACAAA
> >
> >
> > > To categorize cubes gnubg compares the arithmetic means of DP and
> > > CP, and CP and TG with the winning probabilities.  Could someone
> > > please explain me why (and confirm that) this is correct?
> >
> >See above, I think it is correct.
> >
> > > I'm wondering about the following: The winning probability
> > > (aarOutput[ 0 ][ OUTPUT_WIN ]) doesn't include any added value for
> > > gammon or bg chances (aarOutput[ 0 ][ OUTPUT_WINGAMMON ] and
> > > aarOutput[ 0 ][ OUTPUT_WINBACKGAMMON ]). Those match points (DP,
CP,
> > > TG) have an entity of cubeful equity, don't they? And I think
> > > equities are calculated as the sum of winning chances, gammon
> > > chances and bg chances, thus include gammon and bg value. If all
> > > this was correct so far, then I suppose these 2 values can't be
> > > compared.
> >
> >This seems a good point - I think picking the point needs to be done
> >in terms of MWC, it's not enough to do equity, since in some match
> >points, gammons are irre;evant.
> >
> >--
> >Jim Segrave           address@hidden
> >
> 
> _________________________________________________________________
> MSN Search, le moteur de recherche qui pense comme vous !
> http://search.msn.fr
> 
> 
> 
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnubg







reply via email to

[Prev in Thread] Current Thread [Next in Thread]