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.
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.
I don't think python makes any guarantees that 12/6 is evaluated
as 2 rather than 1.99999999999999999999999999 .....
In practice, you do get things like
1/10 == 0.09999999999999999999999999999999
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.
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..?
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.
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 IEEEWhile it is generally correct that comparing two floating point numbers
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.
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 wouldn't have believed it if I didn't see it with my own eyes.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
12/6 in C++ is also 1.99999999999999999999999999
In practice, you do get things likeBut 1/10 in C++ == 0.09999999999999999999999998
1/10 == 0.09999999999999999999999999999999
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 numberthat is periodic in the binary system has this issue due to the limited precision.
On 9/22/2022 5:28 PM, Frank Berger wrote:that is periodic in the binary system has this issue due to the limited precision.
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
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.
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 likeBut 1/10 in C++ == 0.09999999999999999999999998
1/10 == 0.09999999999999999999999999999999
It looks like C++ start counting decimal positions after
any leading zeros when rounding.
The reason: every decimal number that is periodic in the
binary system has this issue due to the limited precision.
Ha ha..! Tim, Paul, Clem, Frank, folks, I was just joking. :)
I've been fooling around with a Python program that compares the Isight decision criteria with the Trice metric.
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 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 >=.
• 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
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.
"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.
"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.
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...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 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".
"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 ignoresAh, it is nitpicking contest. I am all in. (-:
the case where the doubler's count doesn't exceed the taker's count at all.
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 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 ignoresAh, it is nitpicking contest. I am all in. (-:
the case where the doubler's count doesn't exceed the taker's count at all.
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
AxelI 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!
But it was you yourself who indicated that you weren't sufficient with a rough "It's obvious what I mean"...
standard.
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
AxelI 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"I don't know many grammatical terms, but I think I can explain the basic grammatical point.
certainly does _not_ include the possibility that you didn't exceed the speed limit at all!
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.
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?
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...
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")
"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??
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?
You just can't get that out of you, can you...? :) One more time,
I apologize for causing you so much psychological trauma. :(
"ah...Clem" <ah_clem@ymail.com> writes:
[Trice and Isight]
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...
Sure. It is just the scientific method to validate and reproduce other's research. For Tom Keith's database about 11 % of the double decisions
and about 3 % of the take decisions differ. But you lose about 35 % more equity.
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")
Wrong.
if POLT < TC:
return("D/P")
Also, I find this hard to read because you start with D/T, then D/P,
then ND/T. This jumping around regarding the winning chances is asking
for future trouble when you read the code a year from now. But no
further programming lessons from my side. Figure things out for
yourself.
No, no...please cause me more of the same
kind of psychological trauma. I love it!
It probably makes more sense to some to do the casess in numerical order (ND/T, D/T, D/P).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 14:09:57 |
| Calls: | 6,667 |
| Calls today: | 1 |
| Files: | 12,214 |
| Messages: | 5,336,558 |