A general comment about racing algos.
For money play, these have the form:
if your advantage is at least X, double only if the cube is centred.
If your advantage is at least X + delta, double whether the cube is centred
or not.
If your disadvantage is greater than Y, drop.

I would think that all racing algos can improve on this by specifically
asking for adjustments with borderline cases.
For example, the drop/take clause in 8/9/12 could probably be improved
by saying:
If your disadvantage is 11.5% or not as bad, take.
If your disadvantage is 12.5% or worse, drop.
If your disadvantage is strictly between 11.5 and 12.5%, look
at factors that are not measured by the count (wastage, crossovers, gaps
etc.) If consideration of these factors benefits you, take. If the consideration benefits your opponent, drop. If the factors don't accumulate
to anyone's advantage, use the original 12%.

Ain't that a better idea?
And, of course, do the same for all cube decisions in all racing algos.

Paul

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

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

adjustments with borderline cases

[...]

If your disadvantage is strictly between 11.5 and 12.5%, look at
factors that are not measured by the count (wastage, crossovers, gaps
etc.) If consideration of these factors benefits you, take. If the consideration benefits your opponent, drop. If the factors don't
accumulate to anyone's advantage, use the original 12%.

Your example is based on Roberties 8/9/12 method, which was typically
used without any adjustments. Looking at adjustments only in borderline
cases of course will be better than "pure" Robertie, but most likely
still be terrible, because a straight pipcount is so much worse than
methods with adjustments, see table 9 of my article: Your cube decisions
will very often be awfully wrong, even if not borderline according to
"pure" Robertie.

Now if we apply your argument to my Isight method, at what ADDITIONAL
features would you propose to look? Looking at EXISTING features again
is unlikely to help, otherwise the optimizer would have simply given a different weight factor for an existing feature.

Best regards

Axel

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

On Sunday, May 8, 2022 at 2:36:51 PM UTC+1, Axel Reichert wrote:
...

Now if we apply your argument to my Isight method, at what ADDITIONAL features would you propose to look? Looking at EXISTING features again
is unlikely to help, otherwise the optimizer would have simply given a different weight factor for an existing feature.

Great question, and a practical example did actually occur in one of my games with XG.
In this game, one of the sides had a large stack on on the 6, another large stack on the 4 and
a single checker on the 5.
Assuming the other side had a smooth position, the other side is doing better than Isight thinks,
because Isight doesn't know that there's likely to be an ugly gap on the 5, which the present Isight
count is ignoring. So, if this was borderline, I would have biased the decision against
Mr Gap-Too-Much. However, this case turned out not to be an example, because Isight wasn't
borderline here (but was correct).

Paul

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

On Sunday, May 8, 2022 at 8:37:15 PM UTC+1, Axel Reichert wrote:

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

In this game, one of the sides had a large stack on on the 6, another large stack on the 4 and a single checker on the 5. Assuming the
other side had a smooth position, the other side is doing better than Isight thinks, because Isight doesn't know that there's likely to be
an ugly gap on the 5, which the present Isight count is ignoring.

Sounds a bit like the "surface criterion" from

https://www.bkgm.com/articles/GOL/Dec00/pipples.htm

I like this concept, which is elegant and intuitive, but I think it
needs further simplification. Over the years since the Isight method has been published, I have received a couple of e-mail suggestions for improvements (presumably not quantified, but based on gut feeling), all
of them too complicated for my taste. At least for me, my method neatly occupies the sweet spot between accuracy and effort, which should be no surprise, because I optimized on both.

In Seret's there is also a "zero criterion", which also fits your
example from above.

Maybe I will play around a bit, but maybe I should wait a bit more:
After all, your feedback is very valuable and you got "hooked" to my
method just recently. So I am hoping for more to come. (-:

Best regards

Axel

I have noticed a surprisingly large number of positions in my games where the threshold is reached exactly.
For example, I'm deciding whether to take or drop and the difference (7/6 * opponent's adjusted count - my adjusted count) is exactly 2.
In these exact-border positions, does Isight score much better than 50%?

For example, if we called these positions, "point of first drop" instead of "point of last take", would the algo perform worse?
I'd kind of be surprised if so, to any significant degree.
So these might be candidates for my idea of looking for factors not considered by Isight.
But you're right that it would be obviously bad thinking to say "But I have a big ace point stack so that makes me worse."
Well no, because Isight has already considered that. We correct for things that Isight hasn't considered like potential weaknesses
that aren't evident now, but are looming.

This reminds me of my grandmother who didn't like it when a distant relative visited her, made several necessary phone calls concerning
a problem with the relative's son, and then paid money (a cheque + cash) to compensate my grandmother for the higher phone bill.

The conversation went like this:
Grandma: "Her visit was terrible! She left me with a phone bill of £60 [a large amount in those days]"
Ma: "But she took that into consideration when she paid you the extra money." Grandma: "But she only paid me £15!"
Ma: "No, she paid you £15 cash but she also left you a cheque for £15. That makes £30."
Grandma: "But the phone bill was £60! Not £30! She totally ripped me off!" Ma: "But the rest of the money was your phone bill"
Grandma: "But my phone bill should never be £60!"
Ma: "No, your phone bill was £30. The extra £30 you paid was taken into account by the money she left you."

Paul

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

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

In this game, one of the sides had a large stack on on the 6, another
large stack on the 4 and a single checker on the 5. Assuming the
other side had a smooth position, the other side is doing better than
Isight thinks, because Isight doesn't know that there's likely to be
an ugly gap on the 5, which the present Isight count is ignoring.

Sounds a bit like the "surface criterion" from

https://www.bkgm.com/articles/GOL/Dec00/pipples.htm

I like this concept, which is elegant and intuitive, but I think it
needs further simplification. Over the years since the Isight method has
been published, I have received a couple of e-mail suggestions for
improvements (presumably not quantified, but based on gut feeling), all
of them too complicated for my taste. At least for me, my method neatly occupies the sweet spot between accuracy and effort, which should be no surprise, because I optimized on both.

In Seret's there is also a "zero criterion", which also fits your
example from above.

Maybe I will play around a bit, but maybe I should wait a bit more:
After all, your feedback is very valuable and you got "hooked" to my
method just recently. So I am hoping for more to come. (-:

Best regards

Axel

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

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

In these exact-border positions, does Isight score much better than 50%?

For example, if we called these positions, "point of first drop"
instead of "point of last take", would the algo perform worse? I'd
kind of be surprised if so, to any significant degree.

The "long race offset" is -2. If I change it to -2.01, the total error increases by 1 %. If I change it to -1.99, the total error decreases by
1 %. But one of the design goals was not to use fractional numbers. And
I am strongly determined to stick to it.

Best regards

Axel

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