I've been fooling around with a Python program that compares the Isight
decision criteria with the Trice metric.

It basically just runs through a bunch of scores and applies both
metrics to reach a verdict (ND/T, D/T, D/P) and outputs the scores where
they differ.

I'm quite familiar with the Trice metric, so I'm fairly confident I got
that right.

I'm not quite sure that I accurately translated the English formulation
into computer code for Isight. See
https://bkgm.com/articles/Reichert/insights-with-isight.pdf

Here's the code with the function taking the leader's adjusted pipcount
(LC) and trailer's adjusted pipcount (TC):

def ISightVrdict(LC,TC):
POLT = LC + LC/6

if POLT <= TC + 6 and POLT >= TC + 2:
return("D/T")
if POLT < TC + 2:
return(("D/P"))
return("ND/T")

If I got this right I'll have more to say soon. But I'd rather wait
until someone has reviewed the code. Thanks.

On Wednesday, September 21, 2022 at 7:46:15 PM UTC+1, ah...Clem wrote:
> I've been fooling around with a Python program that compares the Isight
> decision criteria with the Trice metric.
>
> It basically just runs through a bunch of scores and applies both
> metrics to reach a verdict (ND/T, D/T, D/P) and outputs the scores where
> they differ.
>
> I'm quite familiar with the Trice metric, so I'm fairly confident I got
> that right.
>
> I'm not quite sure that I accurately translated the English formulation
> into computer code for Isight. See
> https://bkgm.com/articles/Reichert/insights-with-isight.pdf
>
> Here's the code with the function taking the leader's adjusted pipcount
> (LC) and trailer's adjusted pipcount (TC):
>
> def ISightVrdict(LC,TC):
> POLT = LC + LC/6
>
> if POLT <= TC + 6 and POLT >= TC + 2:
> return("D/T")
> if POLT < TC + 2:
> return(("D/P"))
> return("ND/T")
>
>
> If I got this right I'll have more to say soon. But I'd rather wait
> until someone has reviewed the code. Thanks.

No, it's wrong because it isn't nuanced enough.
It needs to take into account that initial-doubling and redoubling have different criteria.

Paul

On 9/21/2022 6:38 PM, peps...@gmail.com wrote:

>
> No, it's wrong because it isn't nuanced enough.
> It needs to take into account that initial-doubling and redoubling have different criteria.
>

I'm just doing initial doubles at this point.

I don't think there's much to be gained by looking at recubes. Both
methods simply reduce the doubling window by one pip, so if they
disagree on the initial double they will disagree on the recube.
Likewise for when they agree.

On Wednesday, September 21, 2022 at 11:59:29 PM UTC+1, ah...Clem wrote:
> On 9/21/2022 6:38 PM, peps...@gmail.com wrote:
>
> >
> > No, it's wrong because it isn't nuanced enough.
> > It needs to take into account that initial-doubling and redoubling have different criteria.
> >
> I'm just doing initial doubles at this point.
>
> I don't think there's much to be gained by looking at recubes. Both
> methods simply reduce the doubling window by one pip, so if they
> disagree on the initial double they will disagree on the recube.
> Likewise for when they agree.

If you're just looking at initial doubles and takes, my verdict is:
Wrong from a technical and pythonic standpoint.
Right from a practical standpoint.

Explanation: Equality is very common in these computations.
However, I don't think python makes any guarantees that 12/6 is evaluated
as 2 rather than 1.99999999999999999999999999 or 2.0000000000000000000001
Such an epsilon error would mess up your code.
However, I would think that this situation is somewhat unlikely to occur in practice.
In practice, you do get things like 1/10 == 0.09999999999999999999999999999999 but I don't
think you're exposed to this type of roundoff error.
In any case, the above point is easily fixable by introducing an epsilon and replacing <= x
by <= x + epsilon (and a similar adjustment for >=).
If you were coding this professionally, an epsilon would probably be used.

Paul

On September 22, 2022 at 12:54:25 AM UTC-6, peps...@gmail.com wrote:

> I don't think python makes any guarantees that 12/6 is evaluated
> as 2 rather than 1.99999999999999999999999999 .....

I wouldn't have believed it if I didn't see it with my own eyes.
12/6 in C++ is also 1.99999999999999999999999999

> In practice, you do get things like
> 1/10 == 0.09999999999999999999999999999999

But 1/10 in C++ == 0.09999999999999999999999998

It looks like C++ start counting decimal positions after
any leading zeros when rounding.

Does anyone know how other languages, (like Delphi)
handle 12/6 and 1/10..?

> In any case, the above point is easily fixable by introducing an
> epsilon and replacing <= x by <= x + epsilon (and a similar
> adjustment for >=). If you were coding this professionally, an
> epsilon would probably be used.

I agree. Does this mean that XG wasn't coded professionally?

Maybe in XG v3.0 some bugs will be fixed by using advanced
coding techniques like using epsilons.

MK

On 9/22/2022 6:55 AM, MK wrote:
> On September 22, 2022 at 12:54:25 AM UTC-6, peps...@gmail.com wrote:
>> In practice, you do get things like
>> 1/10 == 0.09999999999999999999999999999999
>
> But 1/10 in C++ == 0.09999999999999999999999998
>
> It looks like C++ start counting decimal positions after
> any leading zeros when rounding.
>
> Does anyone know how other languages, (like Delphi)
> handle 12/6 and 1/10..?

This sort of thing can depend not just on the language, but
on the specific compiler, or even on the compiler options.

Most of these languages attempt to implement the IEEE
floating-point standard. But even that standard leaves a
few things unspecified, such as whether you're allowed to
keep extra digits of precision in memory while calculating
intermediate values in a computation. And the C++ standard
does not even specify that the IEEE floating-point standard
must be followed.

---
Tim Chow

On 9/22/2022 7:54 AM, Timothy Chow wrote:
> On 9/22/2022 6:55 AM, MK wrote:
>> On September 22, 2022 at 12:54:25 AM UTC-6, peps...@gmail.com wrote:
>>> In practice, you do get things like
>>> 1/10 == 0.09999999999999999999999999999999
>>
>> But 1/10 in C++ == 0.09999999999999999999999998
>>
>> It looks like C++ start counting decimal positions after
>> any leading zeros when rounding.
>>
>> Does anyone know how other languages, (like Delphi)
>> handle 12/6 and 1/10..?
>
> This sort of thing can depend not just on the language, but
> on the specific compiler, or even on the compiler options.
>
> Most of these languages attempt to implement the IEEE
> floating-point standard.  But even that standard leaves a
> few things unspecified, such as whether you're allowed to
> keep extra digits of precision in memory while calculating
> intermediate values in a computation.  And the C++ standard
> does not even specify that the IEEE floating-point standard
> must be followed.

While it is generally correct that comparing two floating point numbers
with the ==, >=, or <= operators can lead to these sorts of errors, the
formula above compares floats to integers, and not just any floats, but
a float obtained by multiplying an integer by 7/6. All the decimal
values are expressed as N.0 or they end with 3333333333333 or
666666666666667

So, this is not an issue for this particular set of numbers, this
specific language, and possibly the interpreter I'm using. I had heard
the creators of Python tried to remove as many "gotchas" from the
language, and it appears that they were successful in this case.

I avoided this issue when I implemented the Trice metric, since it's
based on integer arithmetic and his explanation is clear when to round
and whether the inequality is strict or not.

def TriceVerdict(LC,TC):
if LC > 62:
POLT = math.ceil(LC/10 + 1)
else:
POLT = math.floor( (LC -5)/7)
#print(f'Trice POLT: {POLT}')
if TC <= LC + POLT and TC >= LC + POLT - 3:
return("D/T")
if LC + POLT < TC:
return("D/P")
return("ND/T")

Some months ago, I asked Axel about rounding and he said to not do any
rounding. While Trice was clear what to do with the edge cases, I'm not
confident that I've turned Axel's prose into formula correctly i.e. when
to use strict inequality and when to use <= and >=.

Could someone read his text and see if you think it agrees with the
formula presented? Thanks.

On Thursday, September 22, 2022 at 2:49:22 PM UTC+1, ah...Clem wrote:
> On 9/22/2022 7:54 AM, Timothy Chow wrote:
> > On 9/22/2022 6:55 AM, MK wrote:
> >> On September 22, 2022 at 12:54:25 AM UTC-6, peps...@gmail.com wrote:
> >>> In practice, you do get things like
> >>> 1/10 == 0.09999999999999999999999999999999
> >>
> >> But 1/10 in C++ == 0.09999999999999999999999998
> >>
> >> It looks like C++ start counting decimal positions after
> >> any leading zeros when rounding.
> >>
> >> Does anyone know how other languages, (like Delphi)
> >> handle 12/6 and 1/10..?
> >
> > This sort of thing can depend not just on the language, but
> > on the specific compiler, or even on the compiler options.
> >
> > Most of these languages attempt to implement the IEEE
> > floating-point standard. But even that standard leaves a
> > few things unspecified, such as whether you're allowed to
> > keep extra digits of precision in memory while calculating
> > intermediate values in a computation. And the C++ standard
> > does not even specify that the IEEE floating-point standard
> > must be followed.
> While it is generally correct that comparing two floating point numbers
> with the ==, >=, or <= operators can lead to these sorts of errors, the
> formula above compares floats to integers, and not just any floats, but
> a float obtained by multiplying an integer by 7/6. All the decimal
> values are expressed as N.0 or they end with 3333333333333 or
> 666666666666667
>
> So, this is not an issue for this particular set of numbers, this
> specific language, and possibly the interpreter I'm using. I had heard
> the creators of Python tried to remove as many "gotchas" from the
> language, and it appears that they were successful in this case.
>
>
> I avoided this issue when I implemented the Trice metric, since it's
> based on integer arithmetic and his explanation is clear when to round
> and whether the inequality is strict or not.
>
> def TriceVerdict(LC,TC):
> if LC > 62:
> POLT = math.ceil(LC/10 + 1)
> else:
> POLT = math.floor( (LC -5)/7)
> #print(f'Trice POLT: {POLT}')
> if TC <= LC + POLT and TC >= LC + POLT - 3:
> return("D/T")
> if LC + POLT < TC:
> return("D/P")
> return("ND/T")
>
> Some months ago, I asked Axel about rounding and he said to not do any
> rounding. While Trice was clear what to do with the edge cases, I'm not
> confident that I've turned Axel's prose into formula correctly i.e. when
> to use strict inequality and when to use <= and >=.
>
> Could someone read his text and see if you think it agrees with the
> formula presented? Thanks.

I agree that your Axelisation formulas are correct with the large caveat that you are not considering redoubles.

Paul

MK schrieb am Donnerstag, 22. September 2022 um 12:55:38 UTC+2:

> I wouldn't have believed it if I didn't see it with my own eyes.
> 12/6 in C++ is also 1.99999999999999999999999999
> > In practice, you do get things like
> > 1/10 == 0.09999999999999999999999999999999
> But 1/10 in C++ == 0.09999999999999999999999998
>
> It looks like C++ start counting decimal positions after
> any leading zeros when rounding.
It is well known that computer floating point is not precise. All programming languages that work according to IEEE-754 standard show this behavior (I believe most use IEEE and probably because FPUs implement this). The reason: every decimal number that is periodic in the binary system has this issue due to the limited precision.

On 9/22/2022 5:28 PM, Frank Berger wrote:

> It is well known that computer floating point is not precise. All programming languages that work according to IEEE-754 standard show this behavior (I believe most use IEEE and probably because FPUs implement this). The reason: every decimal number that is periodic in the binary system has this issue due to the limited precision.

Yeah, yeah, yeah. I know.

I learned about all these sorts of problems with numerical analysis back
in the early 80s when I was computing Franck-Condon factors and solving
integral equations in Fortran. This was several years before the
IEEE-754 standard was implemented.

But it's a frickin' red herring for this particular application. See
the thread above.

--
Ah....Clem
The future is fun, the future is fair.

On Friday, September 23, 2022 at 2:58:44 AM UTC+1, ah....Clem wrote:
> On 9/22/2022 5:28 PM, Frank Berger wrote:
>
> > It is well known that computer floating point is not precise. All programming languages that work according to IEEE-754 standard show this behavior (I believe most use IEEE and probably because FPUs implement this). The reason: every decimal number that is periodic in the binary system has this issue due to the limited precision.
> Yeah, yeah, yeah. I know.
>
> I learned about all these sorts of problems with numerical analysis back
> in the early 80s when I was computing Franck-Condon factors and solving
> integral equations in Fortran. This was several years before the
> IEEE-754 standard was implemented.
>
> But it's a frickin' red herring for this particular application. See
> the thread above.

No, it isn't a "red herring"!
You have argued (I'll assume correctly) that your code is certain
not to cause a calculation error through rounding.
But good code demands so much more than that, and you did ask for feedback
after all.
If you wanted feedback on the pure algo with no one offering comment from
a software or IEEE standpoint, you should simply have presented precise pseudocode
and not used a specific language (python in this instance).

That's the whole point of pseudocode (which you didn't use). You abstract the pure algo
and avoid the type of discussion that you're objecting to.

It seems silly to pour water all over the floor, and then complain that the floor's wet.

Paul

On September 22, 2022 at 3:28:44 PM UTC-6, bgbl...@googlemail.com wrote:

> MK schrieb am Donnerstag, 22. September 2022 um 12:55:38 UTC+2:

>> I wouldn't have believed it if I didn't see it with my own eyes.
>> 12/6 in C++ is also 1.99999999999999999999999999
>>> In practice, you do get things like
>>> 1/10 == 0.09999999999999999999999999999999
>> But 1/10 in C++ == 0.09999999999999999999999998
>> It looks like C++ start counting decimal positions after
>> any leading zeros when rounding.

Ha ha..! Tim, Paul, Clem, Frank, folks, I was just joking. :)

I'm still laughing at my own last sentence above. :) Come
on, you all so knowledgeable people; look where you step.

On the serious side, this may mean that I may be building
up credibility here. After that, I can get away with bullshit
as much and easily as anyone of you. ;)

> The reason: every decimal number that is periodic in the
> binary system has this issue due to the limited precision.

This is one of the very few correct things said in this thread.
(Don't say I never give you credit:) The key word is "periodic"
and it also needs to be longer than number of bits available
(I'm not sure exactly but 128 bits are enough for 72 decimal
digits? I think some functions are accurate to 768(??) bits.)

Actually this is what led me to be mischievous. Did any of
you guys question whether Paul's examples are "periodic"?

MK

On 9/23/2022 3:52 AM, MK wrote:
> Ha ha..! Tim, Paul, Clem, Frank, folks, I was just joking. :)

A rare case of R. B. Sahi admitting he's wrong!

What next, claiming he knew that "corpi" wasn't a real word?

---
Tim Chow

"ah...Clem" <ah_clem@ymail.com> writes:

> I've been fooling around with a Python program that compares the Isight
> decision criteria with the Trice metric.

Not satisfied with table 9 in my article?

> Here's the code with the function taking the leader's adjusted pipcount
> (LC) and trailer's adjusted pipcount (TC):
>
> def ISightVrdict(LC,TC):
> POLT = LC + LC/6
>
> if POLT <= TC + 6 and POLT >= TC + 2:
> return("D/T")
> if POLT < TC + 2:
> return(("D/P"))
> return("ND/T")

I take issue not with the logic (you will get the correct decisions),
but with the naming: I assume that POLT is "Point Of Last Take". With
this terminology (which I borrowed from Trice)

POLT = LC + LC/6 - 2

according to the last sentence in section 5.2.

The (re)doubling windows are 3 and 4 pips wide, respectively. Hence (and
this shows where POLT gets its name from):

if POLT < TC
return("D/P")

The other "if" clause appropriately, left as an exercise to the reader.

Best regards

Axel

"ah...Clem" <ah_clem@ymail.com> writes:

> I avoided this issue when I implemented the Trice metric, since it's
> based on integer arithmetic and his explanation is clear when to round
> and whether the inequality is strict or not.

[...]

> Some months ago, I asked Axel about rounding and he said to not do any
> rounding. While Trice was clear what to do with the edge cases, I'm not
> confident that I've turned Axel's prose into formula correctly i.e. when
> to use strict inequality and when to use <= and >=.

I took great care to explain this as precise as possible, because I am
well aware that this is a crucial point. Please read "if his count exceeds the
opponent’s count by at most 6" as carefully as I wrote it (same for the
other bullet points in section 5.2). I keep repeating that equation 6
and the bullet points on page 23 are the way to go. They also clearly
show the use of strict or non-strict inequalities.

Best regards

Axel

On 9/21/2022 2:46 PM, ah...Clem wrote:

So, reading the documentation again:

• A player should double if his count exceeds the opponent’s count by at
most 6.
• A player should redouble if his count exceeds the opponent’s count by
at most 5.
• The opponent should take if the doubler’s count exceeds his count by
at least 2.

This appears to say that the doubling window includes both endpoints,
i.e. if the count exceeds by exactly 6 it's a cube and if it exceeds by
exactly 2 it's a take.

Comments cheerfully accepted.

"ah...Clem" <ah_clem@ymail.com> writes:

> • A player should double if his count exceeds the opponent’s count by at
> most 6.
> • A player should redouble if his count exceeds the opponent’s count by
> at most 5.
> • The opponent should take if the doubler’s count exceeds his count by
> at least 2.
>
> This appears to say

"This says". (-:

If you disagree then I will be eagerly waiting for better formulations
from someone with a stronger command of the English language than me (I
am no native speaker). My wording mimics Tom Keith's ...

> doubling window includes both endpoints, i.e. if the count exceeds by
> exactly 6 it's a cube and if it exceeds by exactly 2 it's a take.

Precisely.

Best regards

Axel

On Friday, September 23, 2022 at 9:59:50 PM UTC+1, Axel Reichert wrote:
> "ah...Clem" <ah_...@ymail.com> writes:
>
> > I avoided this issue when I implemented the Trice metric, since it's
> > based on integer arithmetic and his explanation is clear when to round
> > and whether the inequality is strict or not.
> [...]
> > Some months ago, I asked Axel about rounding and he said to not do any
> > rounding. While Trice was clear what to do with the edge cases, I'm not
> > confident that I've turned Axel's prose into formula correctly i.e. when
> > to use strict inequality and when to use <= and >=.
> I took great care to explain this as precise as possible, because I am
> well aware that this is a crucial point. Please read "if his count exceeds the
> opponent’s count by at most 6" as carefully as I wrote it (same for the
> other bullet points in section 5.2). I keep repeating that equation 6
> and the bullet points on page 23 are the way to go. They also clearly
> show the use of strict or non-strict inequalities.
>
Yes, it's surprising how often the strictness/ non-strictness of the inequalities
would give different cube actions.

Paul

On Friday, September 23, 2022 at 10:36:40 PM UTC+1, Axel Reichert wrote:
> "ah...Clem" <ah_...@ymail.com> writes:
>
> > • A player should double if his count exceeds the opponent’s count by at
> > most 6.
> > • A player should redouble if his count exceeds the opponent’s count by
> > at most 5.
> > • The opponent should take if the doubler’s count exceeds his count by
> > at least 2.
> >
> > This appears to say
> "This says". (-:
>
> If you disagree then I will be eagerly waiting for better formulations
> from someone with a stronger command of the English language than me (I
> am no native speaker). My wording mimics Tom Keith's ...
> > doubling window includes both endpoints, i.e. if the count exceeds by
> > exactly 6 it's a cube and if it exceeds by exactly 2 it's a take.
> Precisely.

My own English usage is really excellent (but note that I didn't say perfect).
On standardized vocab and spelling tests, I genarally score close (or equal) to 100%.

If you're striving for the "best formulation", rather than being satisfied with
a good practical guide, your algo is wrongly worded for a very obvious reason -- it
ignores the case where the doubler's count doesn't exceed the taker's count at all.

Of course, it could be argued that it goes without saying that this is an obvious pass,
but while your wording doesn't consider this, it can't be an optimal formulation.

Paul

"peps...@gmail.com" <pepstein5@gmail.com> writes:

> On Friday, September 23, 2022 at 10:36:40 PM UTC+1, Axel Reichert wrote:
>> "ah...Clem" <ah_...@ymail.com> writes:
>>
>> > • A player should double if his count exceeds the opponent’s count by at
>> > most 6.
>> > • A player should redouble if his count exceeds the opponent’s count by
>> > at most 5.
>> > • The opponent should take if the doubler’s count exceeds his count by
>> > at least 2.

[...]

> your algo is wrongly worded for a very obvious reason -- it ignores
> the case where the doubler's count doesn't exceed the taker's count at
> all.

Ah, it is nitpicking contest. I am all in. (-:

Would you agree that

50 exceeds 60 by at most 10

is a true statement? If not, would you agree that

50 - 60 <= 10

is a true inequality?

Best regards

Axel

On 9/23/2022 4:49 PM, Axel Reichert wrote:
> "ah...Clem" <ah_clem@ymail.com> writes:
>
>> I've been fooling around with a Python program that compares the Isight
>> decision criteria with the Trice metric.
>
> Not satisfied with table 9 in my article?

I need to figure things out for myself sometimes. The first question
that comes to mind is how often does it actually make a difference? So,
I'm addressing that first. Bear with me...

>

>
> I take issue not with the logic (you will get the correct decisions),
> but with the naming: I assume that POLT is "Point Of Last Take".

Thanks. That's exactly what I was looking for.

Your criticism about the variable naming is apt. The code now reads:

def ISightVerdict(LC,TC):
POLT = LC + LC/6 -2
if POLT <= TC + 4 and POLT >= TC:
return("D/T")
if POLT < TC + 2:
return(("D/P"))
return("ND/T")

This is also helpful to me for OTB decisions. POLT is LC + LC/6 -2,
it's a take if trailer's count is equal to or less than that, cube if
the leader is within four. Seems easier for me to apply than the 2 and
6 criteria.

On Saturday, September 24, 2022 at 8:25:47 AM UTC+1, Axel Reichert wrote:
> "peps...@gmail.com" <peps...@gmail.com> writes:
>
> > On Friday, September 23, 2022 at 10:36:40 PM UTC+1, Axel Reichert wrote:
> >> "ah...Clem" <ah_...@ymail.com> writes:
> >>
> >> > • A player should double if his count exceeds the opponent’s count by at
> >> > most 6.
> >> > • A player should redouble if his count exceeds the opponent’s count by
> >> > at most 5.
> >> > • The opponent should take if the doubler’s count exceeds his count by
> >> > at least 2.
> [...]
> > your algo is wrongly worded for a very obvious reason -- it ignores
> > the case where the doubler's count doesn't exceed the taker's count at
> > all.
> Ah, it is nitpicking contest. I am all in. (-:
>
> Would you agree that
>
> 50 exceeds 60 by at most 10
>
> is a true statement? If not, would you agree that
>
> 50 - 60 <= 10
>
> is a true inequality?
>
> Best regards
>
> Axel

I do not agree that "50 exceeds 60 by at most 10".
I think it is a false statement.
I read it as a conjunction of two statements as follows:
[50 exceeds 60] and [the absolute difference between 50 and 60 is at most 10].
Understood that way (my interpretation), it is clearly false.
Certainly 50 - 60 <= 10 is true -- There's a massive difference between the two languages
of mathematics and English.

I'm very confident here. "Axel exceeded the speed limit by less than 10 miles per hour"
certainly does _not_ include the possibility that you didn't exceed the speed limit at all!

You really think it does??

Also, what "nitpicking contest"?
You said that you're not an expert in English usage. I'm not an expert either but am
certainly far much more betterer in it than 99% of people in backgammon circles.
And you specifically asked for improvements in your formulation.

As I said to Ah...Clem, don't pour water all over the floor and then complain that the floor's wet.

Paul

On Saturday, September 24, 2022 at 7:27:55 PM UTC+1, peps...@gmail.com wrote:
> On Saturday, September 24, 2022 at 8:25:47 AM UTC+1, Axel Reichert wrote:
> > "peps...@gmail.com" <peps...@gmail.com> writes:
> >
> > > On Friday, September 23, 2022 at 10:36:40 PM UTC+1, Axel Reichert wrote:
> > >> "ah...Clem" <ah_...@ymail.com> writes:
> > >>
> > >> > • A player should double if his count exceeds the opponent’s count by at
> > >> > most 6.
> > >> > • A player should redouble if his count exceeds the opponent’s count by
> > >> > at most 5.
> > >> > • The opponent should take if the doubler’s count exceeds his count by
> > >> > at least 2.
> > [...]
> > > your algo is wrongly worded for a very obvious reason -- it ignores
> > > the case where the doubler's count doesn't exceed the taker's count at
> > > all.
> > Ah, it is nitpicking contest. I am all in. (-:
> >
> > Would you agree that
> >
> > 50 exceeds 60 by at most 10
> >
> > is a true statement? If not, would you agree that
> >
> > 50 - 60 <= 10
> >
> > is a true inequality?
> >
> > Best regards
> >
> > Axel
> I do not agree that "50 exceeds 60 by at most 10".
> I think it is a false statement.
> I read it as a conjunction of two statements as follows:
> [50 exceeds 60] and [the absolute difference between 50 and 60 is at most 10].
> Understood that way (my interpretation), it is clearly false.
> Certainly 50 - 60 <= 10 is true -- There's a massive difference between the two languages
> of mathematics and English.
>
> I'm very confident here. "Axel exceeded the speed limit by less than 10 miles per hour"
> certainly does _not_ include the possibility that you didn't exceed the speed limit at all!

I don't know many grammatical terms, but I think I can explain the basic grammatical point.
In the (false) sentence: "50 exceeds 60 by at most 10", the clause after the word "by" acts
as a modifier of the clause before the word "by".
It has a similar grammatical structure to:
1) Patricia wins at chess by running her opponents short of time.
Or
2) Joe won the match by a very slight margin.

These sentences have structures:
50 exceeds 60 [and 50 does something else too].
Patricia wins at chess [and her wins have an additional property too]
Joe won the match [and his win had an additional property].

Because 50 doesn't exceed 60, your statement is false.

I hope that helps.

Paul

On Sunday, September 25, 2022 at 1:31:27 AM UTC+1, peps...@gmail.com wrote:
> On Saturday, September 24, 2022 at 7:27:55 PM UTC+1, peps...@gmail.com wrote:
> > On Saturday, September 24, 2022 at 8:25:47 AM UTC+1, Axel Reichert wrote:
> > > "peps...@gmail.com" <peps...@gmail.com> writes:
> > >
> > > > On Friday, September 23, 2022 at 10:36:40 PM UTC+1, Axel Reichert wrote:
> > > >> "ah...Clem" <ah_...@ymail.com> writes:
> > > >>
> > > >> > • A player should double if his count exceeds the opponent’s count by at
> > > >> > most 6.
> > > >> > • A player should redouble if his count exceeds the opponent’s count by
> > > >> > at most 5.
> > > >> > • The opponent should take if the doubler’s count exceeds his count by
> > > >> > at least 2.
> > > [...]
> > > > your algo is wrongly worded for a very obvious reason -- it ignores
> > > > the case where the doubler's count doesn't exceed the taker's count at
> > > > all.
> > > Ah, it is nitpicking contest. I am all in. (-:
> > >
> > > Would you agree that
> > >
> > > 50 exceeds 60 by at most 10
> > >
> > > is a true statement? If not, would you agree that
> > >
> > > 50 - 60 <= 10
> > >
> > > is a true inequality?
> > >
> > > Best regards
> > >
> > > Axel
> > I do not agree that "50 exceeds 60 by at most 10".
> > I think it is a false statement.
> > I read it as a conjunction of two statements as follows:
> > [50 exceeds 60] and [the absolute difference between 50 and 60 is at most 10].
> > Understood that way (my interpretation), it is clearly false.
> > Certainly 50 - 60 <= 10 is true -- There's a massive difference between the two languages
> > of mathematics and English.
> >
> > I'm very confident here. "Axel exceeded the speed limit by less than 10 miles per hour"
> > certainly does _not_ include the possibility that you didn't exceed the speed limit at all!
> I don't know many grammatical terms, but I think I can explain the basic grammatical point.
> In the (false) sentence: "50 exceeds 60 by at most 10", the clause after the word "by" acts
> as a modifier of the clause before the word "by".
> It has a similar grammatical structure to:
> 1) Patricia wins at chess by running her opponents short of time.
> Or
> 2) Joe won the match by a very slight margin.
>
> These sentences have structures:
> 50 exceeds 60 [and 50 does something else too].
> Patricia wins at chess [and her wins have an additional property too]
> Joe won the match [and his win had an additional property].
>
> Because 50 doesn't exceed 60, your statement is false.
>
> I hope that helps.

Having said all this, I don't think there's anything wrong with your (Axel's) formulation from a practical point of view.
It's difficult to conceive of a suitably prepared reader thinking OTB: "Hmmm, my adjusted count doesn't
exceed my opponent's adjusted count at all. I don't know what to do here. What shall I do? What shall I do?
Eureka! I have an idea. I'll just walk away from the backgammon table mid-game and spend the rest of the
day watching reruns of Dallas on youtube."

But it was you yourself who indicated that you weren't sufficient with a rough "It's obvious what I mean"
standard. The below is an exact copy-paste of what you said:

BEGIN QUOTE
If you disagree then I will be eagerly waiting for better formulations
from someone with a stronger command of the English language than me (I
am no native speaker). My wording mimics Tom Keith's ...
END QUOTE

Paul

On Sunday, September 25, 2022 at 8:04:17 AM UTC+1, peps...@gmail.com wrote:
....
> But it was you yourself who indicated that you weren't sufficient with a rough "It's obvious what I mean"
> standard.
....

sufficient -> satisfied.