Re: Re: [Bug-gnubg] Wrong cube errors categories in analysis statistics panel

[Jim Segrave]

On Thu 02 Oct 2003 (14:17 +0200), address@hidden wrote:
> 
> Just to clarify (I'm putting Jim's explanation in a more readable format,
> provided you have a wide enough screen), this is what (I think) it is
> done now :

Yep - that's a much nicer picture than mine

> 
>        GWC |         DP        S1         CP        S2        TG        |
> ACTION     |         |         |          |         |         |         |
> -----------|---------|---------|----------|---------|---------|---------|
>            |         |         |          |         |         |         |
> DOUBLE     |   WADP  |    //   |    //    |    //   |    //   |   WATG  |
>            |         |         |          |         |         |         |
> NO DOUBLE  |    //   |   MADP  |   MACP   |   MACP  |   MATG  |    //   |
>            |         |         |          |         |         |         |
> -----------|---------|---------|----------|---------|---------|---------|
> 
> WA -> Wrong Aound, MA -> Missed Around
> 
> Now what you're saying is that a MACP is either a MADP or a MATG (taking
> the arithmetic mean of DP and TG as separation point, old logic).
> Personally I don't see anything wrong with the current classification, it
> simply gives a bit more of information that the one you propose (i.e. the
> old one).
> If you carry on playing knowing you are between CP and TG, you are wrong
> and the fact you think you are above TG is not a good reason to classify
> the missed double as "around TG".

I agree, I think being told that you should have doubled near the DP,
CP or TG is additional useful information - it gives you feedback on
whether you completely mis-read the situation (thinking you were under
the cash point when you had almost crossed the TG point for example)

> Following your reasoning, a player that doesn't double when he's slightly
> above DP and largerly below TG should have his mistake classified as "missed
> around TG" simply because he thought he was above TG.
> 
> As a totally minor detail, I would change the displayed text to something
> like :
> 
>      Wrong double  (below DP)
>      Wrong double  (above TG)
>      Missed double (above DP)
>      Missed double (around CP)
>      Missed double (below TG)

And I agree that's clearer as well. You could even go further to say 
Missed double (below CP) and
Missed double (above CP)
 
> One thing I can't figure out is what happens when TG is below DP.
> This may happen in match play, playing for an undoubled gammon (e.g.
> at -2,-4 with significative gammon chances, as Joern pointed out in
> a previous thread on the subject).

Let's see what orderings are possible:

DP  <= CP  <= TG - normal, as above
DP  <= TG  <  CP - can't happen, by definition of TG
CP  <  DP  <= TG - can't happen CP must be >= DP 
CP  <  TG  <= DP - can't happen, as above
TG  <= CP  <  DP - can't happen, as above
TG  <  DP  <= CP - all doubles are wrong, all no-doubles are right

So the only extra requirement is that the first test is that if a
double is offered, you are below the TG point, if not it's a 

 Wrong double  (above TG)

> Assuming the CP will still be above the DP, the CP/TG separator (S2)
> will no longer have sense and you will need a new separator between TG
> and DP (the order being now TG -- DP -- CP). I don't know if the
> currently implemented logic does this or not.

With the above test, this is no longer relevant.
 
> A small (big) request related to the subject : the Market Window
> panel allows to modify the current position's gammon/backgammon
> rates (GR1, BR1, GR2, BR2), but not the winning chances (W1% only,
> since W2% = 1-W1%).

It would be better to allow editing either with the effect of moving
one up moves the other down.

> 
> P.S.
> Another minor detail : manually entering gammon/backgammon rates,
> rates above 100% (or below 0%) are fixed to 100% (0%), but there's
> no check on the fact that GR+BR<=100% : you can get funny DP at
> -150% or at +230%, way too wild :)))

It's possible to fix this (it's just like the code I put in yesterday
to address the match length/scores limitations). Basically, everytime
you change one of GR or BR, you change the range limits on both GR and
BR to restrict them so that BR < GR and (BR + GR) <= 100%


What I'd love to see added is a change to the graphs so that rather
than being bar graphs, the areas became trapezoids with the top of the
graph being the fully live cube values and the bottom being the dead
cube values

      live
________________________________
          \       /       |
  ND       \ DT  /   DP   | TG
            \   /         | 
--------------------------------
      dead

I don't know if this is possible with GTK, but I think it very nice.

-- 
Jim Segrave           address@hidden