[Top][All Lists]

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

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

From: Holger
Subject: Re: Re: [Bug-gnubg] Wrong cube errors categories in analysis statistics panel
Date: Thu, 02 Oct 2003 21:06:38 +0200

At 16:19 02.10.2003, Jim Segrave wrote:
On Thu 02 Oct 2003 (14:17 +0200), address@hidden wrote:
>        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)

Do you want to split "Missed double (around CP)" into two categories (making it 4) or combine the 3 missed doubles to 2?

> 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)

A test for TG < DP is necessary so it doesn't fall into the normal case.

> 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.

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

          \       /       |
  ND       \ DT  /   DP   | TG
            \   /         |

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

That's a good idea. But I neither know what could be done with GTK+. Alternatively, one would have to draw a graphics, maybe with LibArt.



reply via email to

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