1. Forum
  2. Usenet
  3. REC.GAMES.BACKGAMMON

  • Axel is correct but only comes third

    From [email protected]@21:1/5 to All on Thu Aug 18 14:18:06 2022
    I found this Axelisation interesting.
    As I see it, the number of crossovers is equal.
    XG gets penalised for a gap on 4.
    So we get an adjusted count of 96 to 107.
    Add 1/6 of 96 to 96 and subtract 107 to get a score of 112 - 107 = 5.
    XG should double (as it did).
    And I could take at 2 away so 5 away is assessed as a very easy take.
    But assuming (I think safely) that XG's analysis assesses these things correctly, the equity is actually 0.985.
    It's a correctly Axelised take (so I took) but Isight wrongly finds an
    easy take.
    The other methods that I happen to know (8, 9, 12) and 10% + 2 actually
    lead to an incorrect pass. But they seem to understand the position
    much better. 8,9, 12 leads to 106.4 < 107 and finds an ultra-marginal
    pass instead of an ultra-marginal take.
    10% + 2 leads to 106.5 < 107 -- again an ultra-marginal pass.

    The difference between an ultra-marginal pass and an ultra-marginal
    take is less than the difference between an ultra-marginal take and
    an easy take. So I don't like pure Axelisation here, despite the
    answer being correct from a binary standpoint.
    The solution? With so much play left in the position, there is no
    need to penalise for crossovers and gaps here. We should not adjust
    and should just use the raw counts of 95 (not 96) to 107. Then the method works better. Alternatively, perhaps use one of the above two methods for
    this type of long-distance race (sorry, Axel)?

    Paul

    XGID=----ACF-B-A--B-c-bbda-aaa-:0:0:-1:00:6:2:3:0:10
    X:eXtremeGammon O:Daniel

    Score is X:2 O:6. Unlimited Game, Jacoby Beaver
    +13-14-15-16-17-18------19-20-21-22-23-24-+
    | O O | | O O O |
    | O | | O O |
    | | | O O |
    | | | O |
    | | | 6 |
    | |BAR| |
    | | | |
    | | | X |
    | X | | X |
    | O X X X | | X |
    | O X X X | | X X X X X |
    +12-11-10--9--8--7-------6--5--4--3--2--1-+
    Pip count X: 95 O: 107 X-O: 2-6
    Cube: 1
    X on roll, cube action

    Analyzed in 4-ply
    Player Winning Chances: 78.25% (G:0.00% B:0.00%)
    Opponent Winning Chances: 21.75% (G:0.00% B:0.00%)

    Cubeless Equities: No Double=+0.565, Double=+1.130

    Cubeful Equities:
    No double: +0.865 (-0.120)
    Double/Take: +0.985
    Double/Pass: +1.000 (+0.015)

    Best Cube action: Double / Take

    eXtreme Gammon Version: 2.10

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Reichert@21:1/5 to [email protected] on Fri Aug 19 09:11:08 2022
    "[email protected]" <[email protected]> writes:

    It's a correctly Axelised take (so I took) but Isight wrongly finds an
    easy take.

    See below ...

    The other methods [...] seem to understand the position much better.

    Paul, please. A method does not understand a position.

    So I don't like pure Axelisation here, despite the answer being
    correct from a binary standpoint.

    (From above) It seems you are being here even more picky than usual
    (-;

    Now not even a correct solution is sufficient for you, because it does
    not pinpoint the position in the doubling window perfectly ...

    The solution? With so much play left in the position, there is no
    need to penalise for crossovers and gaps here.

    I get your point, but then you need to define "so much play left". You
    know that I do not like this kind of hand-waving, but rather prefer to
    stay algorithmic.

    Alternatively, perhaps use one of the above two methods for this type
    of long-distance race (sorry, Axel)?

    The last page of my article mentions an extension of my method for long
    races like this (which are much rarer than most people think, see figure
    14). With it, you will get

    74 - 96/5 + 2*(107 - 96) = 76.8 < 78

    compared to my standard method's result of

    80 - 96/3 + 2*(107 - 96) = 70 < 76

    Does this make you happier?

    Best regards

    Axel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Axel Reichert on Fri Aug 19 02:13:26 2022
    On Friday, August 19, 2022 at 8:11:11 AM UTC+1, Axel Reichert wrote:
    "[email protected]" <[email protected]> writes:

    It's a correctly Axelised take (so I took) but Isight wrongly finds an
    easy take.
    See below ...

    The other methods [...] seem to understand the position much better.

    Paul, please. A method does not understand a position.
    So I don't like pure Axelisation here, despite the answer being
    correct from a binary standpoint.
    (From above) It seems you are being here even more picky than usual
    (-;

    Now not even a correct solution is sufficient for you, because it does
    not pinpoint the position in the doubling window perfectly ...
    The solution? With so much play left in the position, there is no
    need to penalise for crossovers and gaps here.
    I get your point, but then you need to define "so much play left". You
    know that I do not like this kind of hand-waving, but rather prefer to
    stay algorithmic.
    Alternatively, perhaps use one of the above two methods for this type
    of long-distance race (sorry, Axel)?
    The last page of my article mentions an extension of my method for long
    races like this (which are much rarer than most people think, see figure
    14). With it, you will get

    74 - 96/5 + 2*(107 - 96) = 76.8 < 78

    compared to my standard method's result of

    80 - 96/3 + 2*(107 - 96) = 70 < 76

    Does this make you happier?

    Best regards

    Axel

    Yes, it makes me happier.
    I think this position is interesting because it's a situation where a world-class
    player would be unlikely to use your method completely literally (even the long-race version)
    but they would adjust by realising that penalising the high-stack gap isn't really appropriate.

    I really doubt that any human player could make the take/pass decision with any confidence, because
    humans can't cope with this type of marginality in a position which goes well beyond exact calculation.

    So maybe my previous posting could have been framed differently. Rather than a framing of [This is
    a problem with Isight] which may be unfair and may have annoyed you, the framing probably should have been
    "Here's a way in which a strong player might (and probably would [if they use Isight at all]) use Isight as a base but adjust for improved results."
    So, it's just a framing issue.
    Sorry, if my post annoyed you.

    If we use the long-race version but omit the high-stack penalty (which really does seem irrelevant here), we get 74 - 95/5 + 2 * (107 - 95), we get 79 which passes.
    Following the theme of my previous postings, I strongly prefer a verdict of "marginal pass" to a verdict of "clear take".
    I actually prefer my method above (getting 79) in my position even though it leads to a (very slightly) bad pass.
    I don't think any human (even Mochy) would regret having passed this. 0.015 take/pass errors come with the territory of human play.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Axel Reichert@21:1/5 to [email protected] on Fri Aug 19 17:16:04 2022
    "[email protected]" <[email protected]> writes:

    So maybe my previous posting could have been framed differently.
    Rather than a framing of [This is a problem with Isight] which may be
    unfair and may have annoyed you, the framing probably should have been "Here's a way in which a strong player might (and probably would [if
    they use Isight at all]) use Isight as a base but adjust for improved results." So, it's just a framing issue. Sorry, if my post annoyed
    you.

    No worries, I am not so easily annoyed, and even if so, will poke fun at
    you for compensation. (-:

    Best regards

    Axel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)