On Tuesday, February 2, 2021 at 10:31:58 AM UTC-7, Nasti Chestikov wrote:
> On Tuesday, 2 February 2021 at 13:30:04 UTC, kevin arbuthnot wrote:
> > On Saturday, 27 July 2019 at 23:48:05 UTC+1, bgbl...@googlemail.com wrote:
> > > Am Dienstag, 23. Juni 2015 18:46:20 UTC+2 schrieb jrobin...@gmail.com:
> >
> > > It might be surprising to you: to move the checkers in a way that more rolls work well, aka are lucky, is the very essence of the game.
> > >
> > > It is really difficult to make a bot play weak like a human. Do you believe that such unnatural play is better for beginners?
> > Although I've been playing for a few decades I don't rate myself as great, so when I first started using Gnu a few years ago, I wasn't immediately shocked to be losing a lot when I set Gnu to stronger levels, as I wanted to learn. After many games, however, I did start to be surprised by a few things.
> > First, if I set it at a low level in the early days, just to get used to it, eg, beginner or casual player, it would do stupid things, like accepting doubles from clearly losing positions, or offer doubles from the same positions, or make blatantly stupid moves in order to lose.
> > Second, when I set it to middling levels it would play well and all would seem well, until you accepted a double that it "thought" you shouldn't have accepted, eg, a 20% chance of winning, even though I had a stronger layout, and Gnu could only get ahead by throwing jokers. Well that happened a real lot. It was almost trying to dissuade you from taking any risk and punishing you for a poor decision. I wasn't sure how much it was being "lucky", so played 2000+ games and recorded the outcomes. My recent analysis of the results suggests that if I accept a double in these circumstances, ie when it would recommend that I do not accept, from that point onwards, Gnu will average 13.6 pips per throw, and I will average 7.4. That's a bit spooky, innit?
> > Using Gnu's own analysis tool, about 4 times out of 5 Gnu enjoys more "luck" than I did, often in the 20% range!
> > I also think that the analysis tool should show a total pip count thrown by each player for each game; that reveals a lot.
> There seem to be a lot of these old posts being resurrected recently.
>
> Having said that, when I can compile the source code back to the same filesize / hashsum as the currently live version then I'll take GNUDung as being honest.
>
> But I can't. So, it sits in my "this piece of crap cheats" drawer.
GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.

On Tuesday, 31 August 2021 at 18:23:53 UTC+1, Thunderground Samurai wrote:

> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, > to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no > > > luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.

From your main menu: View <-> Panels <-> Command

It will pop up a dialogue box in the bottom right hand corner of your screen. Type "show RNG" and then "show seed". That gets you the parameters used for the dice.

Save down your game and then close down GNU Backgammon. Upon restarting, choose those parameters for the dice (before rolling anything). You can then see if the dice are the same as you play differently.

Thunderground Samurai schrieb am Dienstag, 31. August 2021 um 19:23:53 UTC+2:

> GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random.. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
> Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.

That's the long awaited proof. 3 doubles in a row or 3 out of 4 rools. In the 40 years I play backgammon I have never seen this in RL. Never. What clever bastards that programmers are, providing the source code so that everyone can check the code.

On Wednesday, September 22, 2021 at 12:46:47 PM UTC-7, Frank Berger wrote:
> Thunderground Samurai schrieb am Dienstag, 31. August 2021 um 19:23:53 UTC+2:
>
> > GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
> > Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
> That's the long awaited proof. 3 doubles in a row or 3 out of 4 rools. In the 40 years I play backgammon I have never seen this in RL. Never. What clever bastards that programmers are, providing the source code so that everyone can check the code.

100% cheats. The rolls it gets after a doubling cube challenge have been accepted are off the chain. The program wins far too often considering its otherwise suspect tactics. Moving pips forward instead of pulling them off? Doubling basically automatically when you don't land a hit pip?

A good test would be to roll physical dice and then let gnugb know the results of the rolls. I'm curious if it would ever win under those circumstances. Is that possible with the current code?

On Sunday, June 11, 2023 at 4:17:19 AM UTC+1, Ricardo Costa wrote:
> On Wednesday, September 22, 2021 at 12:46:47 PM UTC-7, Frank Berger wrote:
> > Thunderground Samurai schrieb am Dienstag, 31. August 2021 um 19:23:53 UTC+2:
> >
> > > GNU backgammon is a good teacher, but there is no question at all that the program 'knows' exactly what doubles it needs to throw and when. This programs often throws three doubles in a row, or three out of four, to turn a losing position into a winning one. This happens far too often to be random. I also question the program's evaluation of luck and skill. One can beat the program 28-0, and get a low score on skill with no luck.
> > > Even so, I use it to improve my play, and simply restart the game if the program goes on one it's magical doubles sequences.
> > That's the long awaited proof. 3 doubles in a row or 3 out of 4 rools. In the 40 years I play backgammon I have never seen this in RL. Never. What clever bastards that programmers are, providing the source code so that everyone can check the code.
> 100% cheats. The rolls it gets after a doubling cube challenge have been accepted are off the chain. The program wins far too often considering its otherwise suspect tactics. Moving pips forward instead of pulling them off? Doubling basically automatically when you don't land a hit pip?
>
> A good test would be to roll physical dice and then let gnugb know the results of the rolls. I'm curious if it would ever win under those circumstances. Is that possible with the current code?

Could you give us an example of gnubg's bad play (or "suspect tactics")? This is different to the question of luck. Can you give an example of where gnubg actually played badly?

Paul

Ricardo Costa schrieb am Sonntag, 11. Juni 2023 um 05:17:19 UTC+2:

> 100% cheats. The rolls it gets after a doubling cube challenge have been accepted are off the chain.
And how stupid so many people must have been for such a long time, not finding the cheating code in GnuBG

>The program wins far too often considering its otherwise suspect tactics.
GnuBG plays a PR of about 0,45 (IIRC) and there are about 10 human players worldwide able to play below 3 on average (less is better) and no one of them regards GnuBG as using "suspect tactics". So either you are better player than the best we know (BTW How many major tournament and international titles you have won already? ) Or you might misjudge your abilities. I can't decide what I regard as more probable.

>Moving pips forward instead of pulling them off? Doubling basically automatically when you don't land a hit pip?
It would be very helpful to have an example. Than you might get an explanation.

> A good test would be to roll physical dice and then let gnugb know the results of the rolls. I'm curious if it would ever win under those circumstances. Is that possible with the current code?
I'm not sure I got it. Are you asking for entering manual dice? Yes you can do it. And this is one recommended approach. If you play enough games you'll realize that GnuBG plays better than you might expect. Another approach would be to try to understand what a pseudo-random-number generator is and what a seed is.

Ricardo Costa <hdvprojection@gmail.com> writes:

> The program wins far too often considering its otherwise suspect
> tactics.

Maybe it is YOUR tactics that is suspect?

> A good test would be to roll physical dice and then let gnugb know the
> results of the rolls. I'm curious if it would ever win under those
> circumstances. Is that possible with the current code?

Yes, set it to manual dice, roll your own (precision dice, please), do
not cheat (however tempting it may be in particular situations), and
lose against GNU Backgammon as before, a fate you share with most
humans.

Axel

P.S.: If you are serious in your endeavour, there is also an official
complaint form for backgammon software, easily googled.

On Sunday, June 11, 2023 at 2:20:34 PM UTC-7, Axel Reichert wrote:
> Ricardo Costa <hdvpro...@gmail.com> writes:
>
> > The program wins far too often considering its otherwise suspect
> > tactics.
> Maybe it is YOUR tactics that is suspect?
> > A good test would be to roll physical dice and then let gnugb know the
> > results of the rolls. I'm curious if it would ever win under those
> > circumstances. Is that possible with the current code?
> Yes, set it to manual dice, roll your own (precision dice, please), do
> not cheat (however tempting it may be in particular situations), and
> lose against GNU Backgammon as before, a fate you share with most
> humans.
>
> Axel
>
> P.S.: If you are serious in your endeavour, there is also an official
> complaint form for backgammon software, easily googled.
Where is the setting for manual dice? I'm not seeing it. Thank you.

Ricardo Costa <hdvprojection@gmail.com> writes:

> Where is the setting for manual dice? I'm not seeing it.

Several of the buzz words already match:

Settings, Options, Dice, Manual Dice

And please also google "All about GNU Backgammon".

Axel

On Monday, June 12, 2023 at 2:36:58 PM UTC-7, Axel Reichert wrote:
> Ricardo Costa <hdvpro...@gmail.com> writes:
>
> > Where is the setting for manual dice? I'm not seeing it.
> Several of the buzz words already match:
>
> Settings, Options, Dice, Manual Dice
>
> And please also google "All about GNU Backgammon".
>
> Axel
Where is the setting for manual dice? Thank you.

On Tuesday, June 13, 2023 at 7:45:55 PM UTC-7, Ricardo Costa wrote:
> On Monday, June 12, 2023 at 2:36:58 PM UTC-7, Axel Reichert wrote:
> > Ricardo Costa <hdvpro...@gmail.com> writes:
> >
> > > Where is the setting for manual dice? I'm not seeing it.
> > Several of the buzz words already match:
> >
> > Settings, Options, Dice, Manual Dice
> >
> > And please also google "All about GNU Backgammon".
> >
> > Axel
> Where is the setting for manual dice? Thank you.
Sorry, I misread your post. I see you answered the question. Thank you.

On June 11, 2023 at 5:00:38 AM UTC-6, peps...@gmail.com wrote:

> Could you give us an example of gnubg's bad
> play (or "suspect tactics")? This is different to
> the question of luck. Can you give an example
> of where gnubg actually played badly?

Paul, this thread goes back 11 years, to 2012
when I had initiated it with some examples. I
don't know if they could be proof of Noo-BG's
bad plays but they certainly can be considered
"suspect moves".

Here are a couple of examples of suspect plays
that I encountered not long ago, experimenting
with two instances of Noo-BG open, one getting
dice rolls from a file an the other being fed the
same dice rolls manually, with all other settings
being exactly the same:

game 2 move 31
Dice from file: bPcAqQA3AAAAAA:QQkFAEAAAAAE
Manual entry: bPcAQwE3AAAAAA:QQkFAEAAAAAE

game 3 move 25
Dice from file: btuTAAABAAAAAA:QYkKAEAAIAAE
Manual entry: tt0rAAABAAAAAA:QYkKAEAAIAAE

In both cases Noo-BG has zero chance of winning
and apparently makes the first move it evaluates,
as one of moves all with zero equity. But in the two
instances of the process, it makes different moves!

Unless one keeps a suspicious eye on the bots, it's
unlikely that they will see anything suspicious. But
when one does notice such moves, then he would
be well justified to not share the same trusting of
the bots as with you guys and he may also be well
justified to suspect "what else"...

I personally thing Noo-BG looks ahead before cube
decisions, like Ex-Gee and actually more obviously
but since it doesn't allow external dice DLL's, we can't
test if it makes multiple and/or multithreaded calls
like Ex-Gee does.

I suggest you guys don't rush to bash bot suspecters
before you make genuine efforts to acknowledge and
reasonably explain what causes those suspicions.

MK

On June 11, 2023 at 3:06:33 PM UTC-6, Frank Berger wrote:

> And how stupid so many people must have
> been for such a long time, not finding the
> cheating code in GnuBG

It's very possible that people who may have
looked for it weren't capable of finding it.

On the other hand, people like you who may
be capable of finding it probably nefer felt a
need to look for because they assumed that
it wouldn't be there.

Give me an honest answer. Have you ever
combed through Noo-BG's code looking for
evidence of cheating?

And a bonus question, how can you be sure
that the executable distributed matches the
source code that you would be looking at??

> GnuBG plays a PR of about 0,45 (IIRC) and
> there are about 10 human players worldwide
> able to play below 3 on average ....

This is a circular fallacy. You can't measure a
measuring stick against itself as the measuring
unit.

Will you bet money on Noo-BG based on my
expected winning chances derived from my
PR calculated by Noo-BG? If not, shut up and
fuck off!

> I'm not sure I got it. Are you asking for entering
> manual dice? Yes you can do it. And this is one
> recommended approach.

Without allowing keyboard input, it's impossible
to automate manual dice which is very tedious
and thus probably hardly ever used.

> Another approach would be to try to understand
> what a pseudo-random-number generator is and
> what a seed is.

To suggest that a bot that plays strong enough
with manual dice wouldn't cheat with internal
dice is like saying that people who are already
rich wouldn't steal. Learn to think unconditionedly,
unassumedly...

MK

On June 11, 2023 at 3:20:34 PM UTC-6, Axel Reichert wrote:

> P.S.: If you are serious in your endeavour,
> there is also an official complaint form for
> backgammon software, easily googled.

I think the creator of that form, Gary wong,
also among the creators of Noo-BG, was
the biggest, most-insulting asshole of all
time in RGB. Some of the items in his form
had already been proven at the time he had
created it but, of course, that didn't matter.
Do you think he would bet money on his
own bot if someone offered to provide
circumstantial evidence for it? How about
you? Would you bet monet on that Noo-BG
doesn't cheat?

MK

On Wednesday, June 21, 2023 at 10:16:21 AM UTC+1, MK wrote:
....
> > GnuBG plays a PR of about 0,45 (IIRC) and
> > there are about 10 human players worldwide
> > able to play below 3 on average ....
>
> This is a circular fallacy. You can't measure a
> measuring stick against itself as the measuring
> unit.
....

This is actually a good point by Murat.
The PR measures how accurately someone follows the bot.
So using gnubg's PR to assess gnubg isn't really a valid test.

For those that believe in market efficiency, a wealthy person
can offer to back gnubg in a money session against any taker,
and point out that no one accepts the offer.

Or a few ultra long matches can be played, or many short matches,
against top humans and we can see what happens.

Gnubg needs to eat ham and mustard sandwiches before playing at its best.
Therefore no test is valid unless a graphic of a ham and mustard sandwich
is displaying on one of the user's monitors.

Paul

On June 21, 2023 at 11:49:16 AM UTC-6, peps...@gmail.com wrote:

> On Wednesday, June 21, 2023 at 10:16:21 AM UTC+1, MK wrote:

>>> GnuBG plays a PR of about 0,45 (IIRC) and
>>> there are about 10 human players worldwide
>>> able to play below 3 on average ....

>> This is a circular fallacy. You can't measure a
>> measuring stick against itself as the measuring
>> unit.

> This is actually a good point by Murat.
> The PR measures how accurately someone
> follows the bot. So using gnubg's PR
> to assess gnubg isn't really a valid test.

> For those that believe in market efficiency,

This would exclude people who can't afford
and/or who don't want to gamble (since it's
a game of luck afterall).

> a wealthy person can offer to back gnubg
> in a money session against any taker, and
> point out that no one accepts the offer.

Why not a simple prize contest open to all?

A wealthy person can offer a sum assuming
that he will lose it but being okay with that
for the good cause of promoting the game.

A person who really believes that no human
can beat a certain bot, doesn't even need to
be wealthy in order to offer a prize sum since
he wouldn't be risking to lose it.

> Or a few ultra long matches can be played,
> or many short matches, against top humans
> and we can see what happens.

By "top humans", if you mean the small circle
of mentally ill gambler "giants", then it will be
an exclusive "by invitation only" masturbation
contest among prequalified ones by the bots.

> Gnubg needs to eat ham and mustard
> sandwiches...

It sounds like you have been eating too many
fried brain sandwiches with mustard... :(

https://duckduckgo.com/?q=fried+brain+sandwich&ia=web

MK

On 2023-06-21, MK <murat@compuplus.net> wrote:

> I personally thing Noo-BG looks ahead before cube
> decisions, like Ex-Gee and actually more obviously
> but since it doesn't allow external dice DLL's, we can't
> test if it makes multiple and/or multithreaded calls
> like Ex-Gee does.

With gnubg it should be possible to generate dice with a user-provided
program by hijacking the "read dice from file" feature, by reading them
from a named pipe.

I confirmed it works on Unix this way:

- create a named pipe:

mkfifo /tmp/p

- write dice generated by an external program to it. I used the
following simple Python script, but anything that writes two numbers
between 1 and 6 per line will do.

from random import randint
while True:
d1 = randint(1, 6)
d2 = randint(1, 6)
print(d1, d2)
# if you fear gnubg discards rolls it doesn't like
# you could log d1 and d2 somewhere here
# and compare this log with the match record

python /tmp/rng.py > /tmp/p

- start gnubg and choose to read the dice from /tmp/p as RNG

It should be possible to do something similar on Windows. It has named
pipes as well but their names are restricted to awkward paths. They
could be tricky to select in the file explorer widget as the file to
read the dice from.

I'd be interested if you or someone else tried this on Windows and
reported how it went.

On June 21, 2023 at 3:43:42 PM UTC-6, Philippe Michel wrote:

> With gnubg it should be possible to generate
> dice with a user-provided program by hijacking
> the "read dice from file" feature, by reading them
> from a named pipe.
> I confirmed it works on Unix this way:
> .....
> I'd be interested if you or someone else tried
> this on Windows and reported how it went.

Just a couple of quick thoughts/questions
before anyone tries it on Windows.

- Before feeding the dice to the pipe, we need
to wait until Noo-BG is done with deciding its
cube decision. If it's followed by a cube action,
it's easy but how would we know if there is no
cube action?

- If we wait too long, because we won't know
when it's ready to read the dice from the pipe,
then it will think it reached the EOF and try to
rewind the file.

With manual dice, it displays a dice dialog box
and waits for input. With reading from a file or
a pipe, it would need to do the same, to enable
the script to wait for a similar "ready to receive
dice" cue.

In that case, it would be easier for Noo-BG to
accept keyboard input for manual dice, which
can be emulated by passing a keyboard event
from a script or a tiny compiled executable. (I
can't understand why you guys refuse to add
this simple, basic capability that exists in every
other stupid bot out there..?)

MK

On 2023-06-21, MK <murat@compuplus.net> wrote:

> Just a couple of quick thoughts/questions
> before anyone tries it on Windows.
>
> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision. If it's followed by a cube action,
> it's easy but how would we know if there is no
> cube action?
>
> - If we wait too long, because we won't know
> when it's ready to read the dice from the pipe,
> then it will think it reached the EOF and try to
> rewind the file.

I'm not sure about Windows, but I would not expect these to be issues.
The pipe is a kind of waiting queue. The RNG fills it with dice rolls
then gets blocked. Gnubg consumes them and would get blocked if the pipe
became empty. In practice, after some quantity of dice rolls is read and
the queue is drained enough, the writing RNG gets unblocked and replenish
the queue.

The interest for this use case is that the interface to access both ends
of it is the same as writing and reading a file, with no EOF or disk
full issues, only blocking until the situation sorts itself out or one
of the involved processes is exited.

> In that case, it would be easier for Noo-BG to
> accept keyboard input for manual dice, which
> can be emulated by passing a keyboard event
> from a script or a tiny compiled executable. (I
> can't understand why you guys refuse to add
> this simple, basic capability that exists in every
> other stupid bot out there..?)

GUI programming is not my cup of tea. Maybe someone else will do it.

I'm a bit skeptical about the advantage of keyboard input (2 keys +
something else, the return key or a click, to validate) vs. one click on
the dicerolls pad.

Maybe I'm biased because I used a French keyboard where the digits are
on shifted keys, but even if this were not the case, or with a numeric
keypad, I tend to think that mixing keyboard and mouse use would be more
cumbersome.

MK <murat@compuplus.net> writes:

> - Before feeding the dice to the pipe, we need
> to wait until Noo-BG is done with deciding its
> cube decision.

[...]

> - If we wait too long, because we won't know
> when it's ready to read the dice from the pipe,
> then it will think it reached the EOF and try to
> rewind the file.

A pipe is not a file.

https://en.wikipedia.org/wiki/Anonymous_pipe

Axel

MK <murat@compuplus.net> writes:

> It's very possible that people who may have
> looked for it weren't capable of finding it.

"Judge, there was a murder, but I could not find evidence for it."

Very convincing.

> Without allowing keyboard input, it's impossible
> to automate manual dice which is very tedious

Nope. Been there, done that. Read the dice from a file. For the
paranoids, try to fill it via a (named) pipe.

> To suggest that a bot that plays strong enough
> with manual dice wouldn't cheat with internal
> dice is like saying that people who are already
> rich wouldn't steal.

Dice paranoids usually complain about bots being "too strong, so it must
be cheating". If changing to manual dice does not change the severity of
the defeat, it is a strong hint that the bot is not "too strong" for the
(internal) dice to be fair.

Axel

On June 22, 2023 at 2:54:24 PM UTC-6, Philippe Michel wrote:

> On 2023-06-21, MK <mu...@compuplus.net> wrote:

>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.

> I'm not sure about Windows, but I would not
> expect these to be issues. The pipe is a kind
> of waiting queue. The RNG fills it with dice rolls
> then gets blocked. Gnubg consumes them and
> would get blocked if the pipe became empty.

Then, what's the difference between reading
from a file and from a pipe? The idea was to
prevent the bot from looking at the upcoming
dice rolls before it makes its cube decision.
"Filling" the pipe with defeats this purpose.

> The interest for this use case is that the
> interface to access both ends of it is the
> same as writing and reading a file, with no
> EOF or disk full issues, only blocking until
> the situation sorts itself out or one of the
> involved processes is exited.

Blocked writing/reading a single dice roll at
a time can avoid technical problems but the
idea is to give each dice roll to the bot after
it finishes its cube decision. Without a "cue"
from the bot, the blocked writing process will
wait forever and the blocked reading side will
also wait forever...

>> (I can't understand why you guys refuse to
>> add this simple, basic capability that exists
>> in every other stupid bot out there..?)

> GUI programming is not my cup of tea.
> Maybe someone else will do it.

It won't require GUI programming. It's easier.
Noo-BG already accepts keyboard input for
all kinds of other user actions.

> I'm a bit skeptical about the advantage of
> keyboard input (2 keys + something else,
> the return key or a click, to validate)

Only 2 keystrokes, sent and read immediately.

> vs. one click on the dicerolls pad.

It's not an issue of 1 click vs 2 keystrokes. It's
trivially easy to automate sending keystrokes
but practically impossible to automate sending
mouse clicks on dice icons at different relative
screen coordinates.

> I tend to think that mixing keyboard and
> mouse use would be more cumbersome.

They can coexist without any problems. Like I
said, even the stupidest bots implement both.
If not both, then it's the mouse input that will
be the missing feature, as it's the hardest of
the two to implement.

MK

On June 22, 2023 at 3:14:24 PM UTC-6, Axel Reichert wrote:

> MK <mu...@compuplus.net> writes:

>> - Before feeding the dice to the pipe, we need
>> to wait until Noo-BG is done with deciding its
>> cube decision.
> [...]
>> - If we wait too long, because we won't know
>> when it's ready to read the dice from the pipe,
>> then it will think it reached the EOF and try to
>> rewind the file.

> A pipe is not a file.

It is a file, written to and read from using the
same functions as any other file.

> https://en.wikipedia.org/wiki/Anonymous_pipe

Philippe was talking about "named pipes" and
you give a link to "anonymous pipes". They are
not the same. Depending on the modes, a read
function may wait or return EOF/null byte. Why
do you always complicate the discussion with
things that are not essential to the subject..? :(

Making it read from any kind of pipe won't keep
the bot from looking ahead before cube actions
if the dice roll is written to the pipe beforehand!

MK

On June 22, 2023 at 3:54:47 PM UTC-6, Axel Reichert wrote:

> MK <mu...@compuplus.net> writes:

>> It's very possible that people who may have
>> looked for it weren't capable of finding it.

> "Judge, there was a murder, but I could not
> find evidence for it."
> Very convincing.

You fail to understand the logical argument.

> Nope. Been there, done that. Read the dice
> from a file. For the paranoids, try to fill it via
> a (named) pipe.

I already explained that, unlike real or emulated
manual dice, reading from a file or a pipe is not
a "solution" to preventing the bot from looking
ahead, which was the original intentention.

>> To suggest that a bot that plays strong enough
>> with manual dice wouldn't cheat with internal
>> dice is like saying that people who are already
>> rich wouldn't steal.

> If changing to manual dice does not change
> the severity of the defeat, it is a strong hint
> that the bot is not "too strong" for the (internal)
> dice to be fair.

You went from asking for "evidence" to settling
for just "strong hint" but regardless, you fail to
understand the logical argument itself, which
doesn't require anyone to be "dice paranoid".

MK

MK <murat@compuplus.net> writes:

> The idea was to prevent the bot from looking at the upcoming dice
> rolls before it makes its cube decision.

See roll.c for whether this happens.

> idea is to give each dice roll to the bot after
> it finishes its cube decision.

The bot asks for the dice roll after its cube decision, see roll.c.

Axel