Re: Stepping down as Debian gnubg maintainer

[Øystein Schønning-Johansen]

Thank you for your effort, Russ!

To those of us left, I think we should try to get an automatic package
build system. I guess if we were hosting at GitHub we could do GitHub
Actions to automatically build packages for any pull requests. Do we have
something like that in Savannah?

-Øystein

On Sun, 8 Sept 2024, 23:06 Russ Allbery,  wrote:

> Hello all,
>
> (Please cc me on replies that you want me to see, since I may not be
> reading the list.)
>
> I'm stepping down as the maintainer of the Debian gnubg package due to
> lack of time.  Since I've been packaging gnubg for Debian since 2005 (good
> lord), I thought I'd let everyone know that the package will need a new
> maintainer.  The Debian package is also the source of the Ubuntu package.
>
> I've just pushed an update to 1.08.003 with the 3D board re-enabled as
> part of orphaning the package, so hopefully I'm leaving gnubg in good
> shape.  It's now marked as orphaned in Debian and is ready for anyone else
> to adopt.
>
> I'm afraid that I can't help with uploads or package sponsorship, but
> there are groups within Debian such as debian-mentors that may be able to
> help.  I believe there is also a team in Debian devoted to packaging games
> that may be able to provide assistance.
>
> Thank you for the excellent software!  I've gotten many hours of enjoyment
> out of it over the years.  Also thank you for being an excellent upstream
> for packaging and for all of your helpful responses to my questions and
> various mistakes and confusions.
>
> --
> Russ Allbery (ea...@eyrie.org) 
>
>

Re: Skill level names

[Øystein Schønning-Johansen]

I support this!

man. 8. juli 2024 kl. 00:06 skrev Philippe Michel :

> Currently gnubg uses relatively obscure names for its skill levels.
>
> In the player settings, which is stronger between World Class, Supremo,
> Grandmaster is not obvious at first sight.
>
> In the analysis results, Supernatural and Awful are a bit awkward (the
> latter is excluded from the Japanese translation!)
>
> Would you mind if we simply used "-ply" as regular levels (keeping
> only one at 2-ply) for bot player settings and something like "0-ply
> beginner", etc... for the weakend levels.
>
> For the analysis results we could use the denominations from BMAB
> (https://bgmastersab.com/about) without the 0/1/2/3 subdivisions:
> error rate <= 5 Super Grandmaster
><= 8 Grandmaster
><= 13 Master
><= 20 Advanced
><= 32 Intermediate
>else either Casual or Beginner
>
>
>

Re: Conversion to git: mapping cvs userids to git authors

[Øystein Schønning-Johansen]

Hi!

I have changed my real life name to Øystein Schønning-Johansen. If the
system understand utf8, your can keep the ø's. If not, replace with Os.

(Maybe I should update the AUTHORS file as well)

Looking forward to use git.

-Ø

On Sun, 25 Feb 2024, 23:07 Philippe Michel, 
wrote:

> When converting the gnubg CVS repository to git, it will be necessary to
> map the savannah accounts used with cvs to git authors, with a format
> of: Full Name 
>
> I extracted a list of all cvs commits and their authors and could find
> almost all names and (possibly obsolete) addresses in the ChangeLog
> file. A tentative mapping is in this file:
> http://philippe.michel7.free.fr/gnubg/authormap
>
> If you are, or have been, involved with gnubg development, would you
> mind looking if your name is in it and if this is the case send me any
> needed correction ?
>
> Note that some appear twice, including under an "uid." account ; I
> suppose this comes from an change of account or some internal change at
> savannah.
>
>

Mac OS builds. Or even iPad?

[Øystein Schønning-Johansen]

Hi!

I'm asking for a friend, as the apple products really aren't my style.

Are there any builds of GNU Baclgammon for Mac avalable? or even iPad?

-Øystein

Re: GNUbg version 1.08.001 available

[Øystein Schønning-Johansen]

Thank you again for your effort. Really much appreciated.

Do you have the raw neural network weight files?

-Øystein

tir. 6. feb. 2024 kl. 08:13 skrev Philippe Michel :

> A new version of GNUbg is available at https://www.gnu.org/software/gnubg/
> with the following improvements or new features since the previous version.
>
> Playing skill:
>
> Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube
> error rates are approximately halved and the repartition of errors
> (premature doubles vs. missed doubles vs. take or pass errors) is now
> similar to higher plies instead of being mostly premature doubles.
>
> GUI:
>
> New button to analyse the current match with one click instead of going
> through a menu. Optionally runs in background and allows to start
> browsing the results while the analysis is still running.
>
> New button to analyse a file. This offers three usage modes:
> - batch analysis, similar to what was already existing
> - single file analysis, similar to the current match analysis above
> - smart analysis: single file analysis of the most recent file of a
>   directory (presumably where the user saves its exported matches
>   when playing online).
>
> Feature to show how the player's GNU error rate has evolved throughout
> the player's history, as provided by the database records.
>
> The above "one click analysis" features have added two more buttons to
> the toolbar, and this could make it too wide for some screens. Using an
> icons-only toolbar allows to work around this issue ; every button has a
> tooltip and the settings are autosaved.
>
> Improvement the the existing (but almost undocumented and only available
> from the CLI) possibility to always show a list of players at the bottom
> of the board
>
> Other miscellaneous improvements:
>
> Much more extensive Japanese translation.
>
> Many bug fixes.
>
>

Re: # of hidden nodes

[Øystein Schønning-Johansen]

BTW, if you want to increase the size and retrain, I would rather add an
extra hidden layer between 128 and the output layer (say 64 nodes), than
increasing the current hidden layer with more nodes.

... But you might have different plans...

-Ø

On Thu, 28 Dec 2023, 01:26 Mark Higgins,  wrote:

> Thx!
>
> On Wed, Dec 27, 2023 at 7:20 PM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> The normal contact position neural network had 250 inputs, 128 hidden
>> nodes and 5 outputs.
>>
>> -Ø
>>
>> On Wed, 27 Dec 2023, 23:23 Mark Higgins,  wrote:
>>
>>> Can someone remind me pls - how many hidden nodes does the gnubg 0-ply
>>> bot use in its neural networks? Thx!
>>>
>>>

Re: # of hidden nodes

[Øystein Schønning-Johansen]

The normal contact position neural network had 250 inputs, 128 hidden nodes
and 5 outputs.

-Ø

On Wed, 27 Dec 2023, 23:23 Mark Higgins,  wrote:

> Can someone remind me pls - how many hidden nodes does the gnubg 0-ply bot
> use in its neural networks? Thx!
>
>

Re: Backgammon API

[Øystein Schønning-Johansen]

I've been thinking of a backgammon protocol the whole day now. Here are
some of my viewpoints.

As Guido says, both UCI and xboard are terrible, and I think they have some
weaknesses, yes. It is really hard to define a perfect protocol and it
cannot be perfect on the first attempt anyway. I think it is important that
we find the right balance. We don't want too much done in the GUI and we
don't want too much at the engine side either. I think the state of a match
can be handled by the GUI. The engine should hence be "stateless" and able
to answer to the following commands:

evaluate
find_best_cube_action
find_best_move
rollout_move
rollout_cube

In addition there should be some options exchanging keywords and some
handshaking and initialisation instructions. The options description can be
defined better later, but make sure that engine takes care of how to find
moves and evaluate at different settings. I strongly believe that such
things should be handled by the engine and not the GUI.

I actually disagree with Guido when it comes to raw sockets. I think raw
sockets are good. With raw sockets a engine programmer can just write
directly to stdout and never even think of XML, JSON, Protobuf, or what
ever next will be the retired data exchange format. It works fine over ssh
and it is easy for an engine developer to debug.

-Øystein


tir. 14. nov. 2023 kl. 08:46 skrev Guido Flohr :

> Hi,
>
> > On 13 Nov 2023, at 21:22, Carsten Wenderdel 
> wrote:
> >
> > In chess there is UCI, an interface understood by virtually all engines,
> bots and GUIs. Wouldn’t it be great if we had something similar for
> backgammon? Someone could write a new engine or GUI without worrying too
> much about the other. If someone wanted to create a JavaScript or Flutter
> GUI on top of GnuBG, it would be possible.
>
> I have both implemented UCI and xboard and imho both ”protocols” are
> terrible. We should learn from their mistakes.
>
> > In chess UCI uses standard input and output. I believe a modern
> interpretation should be based on web technologies.
>
> Absolutely.
>
> What would really help would be a documentation of the external interface
> of GNUBG. That should allow anybody with decent knowledge in JavaScript,
> Python, Perl, you name it to write an adapter that translates GNUBG’s
> external interface to a new protocol.
>
> For that new protocol, I think it makes sense to look at the FIBS
> protocol. Of course, I wouldn’t use raw sockets nowadays but a REST API or
> GraphQL but if board representations, moves, etc. resemble FIBS, it should
> be easier to modify existing clients to speak the new protocol.
>
> Cheers,
> Guido
>
>
>
>

Re: Using GnuBG to test own bot

[Øystein Schønning-Johansen]

For the first question "Is it possible to use GnuBG to test an own
implementation of a bot?", I would say yes, go ahead.

I actually think it will be very hard to implement a bot on your own
without having anything to verify against.
I have used GNU Backgammon to verify my own codes over the years.

However, what is not allowed is to "copy" code and claim that you wrote it.
Your code should be your own work.

-Øystein

tir. 8. aug. 2023 kl. 15:08 skrev Daniel Lidström :

> Hi Ian
>
> Thanks for writing up all the details. You’ve answered all my questions
> well and I now understand why there are no bot tournaments. I was kind of
> looking for rankings and competitions between programs using a protocol
> similar to UCI for chess. I was trying to satisfy my curiosity regarding
> the techniques involved in backgammon programming but now I think I will
> settle for playing and improving myself.
> Thanks to all who replied.
>
> /Daniel
> On 8 Aug 2023 at 10:46 +0200, Ian Shaw , wrote:
>
> Hi Daniel,
>
> There is a mechanism for using GnuBg to plug in another playing engine,
> but I've no idea how it works or even whether it has been implemented other
> than the setting being available. You can find it in the GUI under
> Settings, Players, External.
>
> set player external - Have another process make all moves for a player
> Usage: set player  external 
>
> I don't know what the file is supposed to contain.
>
>
> There are no recent bot competitions, and the formats there used to be
> were of such short duration that there was nothing meaningful to be gained
> from the results. Frank Berger took BGBlitz to some, and he reads sees this
> forum, so maybe he can give you some information. You need to play
> thousands or millions of games to distinguish between the bots, because
> they are all so similar in strength, and that doesn’t fit well with formal
> competitions.
>
> The strongest current bots, ranked by public perception, are:
> 1. Extreme Gammon (XG)
> 2. GnuBg
> 3. BGBlitz by Frank Berger.
>
> Older bots such as Snowie and Jellyfish are no longer underdevelopment,
> and I understand XG is headed the same way. I'm not aware of any other bots
> that approach these five in playing strength. Snowie is about as string as
> GnuBG. Jellyfish is older and weaker than the other four. I think older
> bots such as Tesauro's TDGammon and others are significantly weaker than
> these five.
>
> My personal view is that if XG is stronger, it is by very little. It's
> main advantages are that people many prefer the GUI, and that it is faster
> for evaluations and rollouts. I think it has some inherent design
> advantages in that it was designed for multi-threaded operation. GnuBG was
> designed before that era, so the multi-threaded features have been
> retro-fitted, for example, use of SSE and AVX instructions, multi-threaded
> rollouts.
>
> I hope this helps. (I'm not one of the developers; I've just been lurking
> here a long time.)
> Ian Shaw
>
>
> -Original Message-
> From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
>  On Behalf Of Daniel
> Lidström
> Sent: Monday, August 7, 2023 9:49 AM
> To: bug-gnubg@gnu.org
> Subject: Using GnuBG to test own bot
>
> Hi
>
> Is it possible to use GnuBG to test an own implementation of a bot? I’ve
> been looking for up-to-date info on backgammon programming but haven’t
> found much. Most sources are old. Where can I find current info? For
> example, which programs are competing nowadays. Which are strongest? Are
> there active bot competitions?
>
> /Daniel
>
>

Re: human level opponents in GNUbg?

[Øystein Schønning-Johansen]

(not harsh at all, Joseph!)

Yes! I think everyone agree to that. The engine and the gui should be
separated in two processes with a protocol between them.

BTW. There is a new initiative to develop a new backgammon engine. So far
it has been some discussions. It will be coded from scratch in Rust. If
anyone wants to participate, I can send an invite to a slack workspace.

-Øystein


On Fri, 4 Aug 2023, 19:38 Joseph Heled,  wrote:

>
> I don't want to sound harsh, but if we lost all GUI support then GNUbg is
> no more alive than XG.
>
> -Joseph
>
>
> On Sat, 5 Aug 2023 at 02:07, Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Yes!
>>
>> We could actually train neural networks with different characteristics.
>>
>> Let's say we do one loop through the training dataset, and for each
>> position we add a little notch to the winning probabilities for all
>> positions that have an opponent checker on the bar (and maybe even a bigger
>> notch if there's two or more checkers on the bar). Then we do supervised
>> training with this modified trainset. This will hopefully create a more
>> aggressive player that will be more eager to hit loose on checkers, and
>> hopefully create a player with an attacking style.
>>
>> Then - Let's say we do one loop through the training dataset, and for
>> each position we subtract a little notch to the winning probabilities for
>> all positions that have a blot that can be hit (and maybe even a bigger
>> notch if there's several of it's blot that can be hit). Then we do
>> supervised training with this modified trainset. This will hopefully create
>> a more careful player that will rather create high stacks than playing
>> flexible. Typically seen by beginner players. 4-1 opening roll is then
>> played 13/8, they seldom split backcheckers etc.
>>
>> Of course I have no idea if this will work or not. But I think I will be
>> able to do something like this. (But not now as I'm leaving for vacation
>> tomorrow morning)
>>
>> We probably need some interface that can read custom neural networks. I
>> have lost the touch when it comes to GTK coding, but someone may be able to
>> specify.
>>
>> -Øystein
>>
>>
>>
>> fre. 4. aug. 2023 kl. 15:39 skrev Superfly Jon :
>>
>>> Different nets sound like a good addition for people who want to play
>>> against the computer.  This could be combined with an old idea of having a
>>> list of opponents with different characteristics (e.g. more / less
>>> aggressive) where the move equities are adjusted based e.g. on the number
>>> of blots, leading to weaker play with different styles.  Maybe the
>>> different neural nets already do this to some degree?
>>>
>>> Unfortunately I haven't the time to commit to this currently, but maybe
>>> others might and I may have more time in the future.
>>>
>>> Jon
>>>
>>> On Tue, 1 Aug 2023 at 06:52, Joseph Heled  wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> As part of my recent research (Elo systems and PR) I generate a number
>>>> of neural nets, ranging from 500 Elo to about 1800.
>>>>
>>>> I thought it might be a nice feature to have for beginners, to play a
>>>> weaker, less frustrating, computer opponent. Might also be useful for
>>>> stronger players - practicing playing against weaker players.
>>>>
>>>> I am willing to adapt the nets to GNUbg. If anyone wants to collaborate
>>>> with me on the rest, i.e. user interface and glue to the rest of the
>>>> system, please contact me and we can discuss feasibility.
>>>>
>>>> -Joseph
>>>>
>>>

Re: human level opponents in GNUbg?

[Øystein Schønning-Johansen]

Yes!

We could actually train neural networks with different characteristics.

Let's say we do one loop through the training dataset, and for each
position we add a little notch to the winning probabilities for all
positions that have an opponent checker on the bar (and maybe even a bigger
notch if there's two or more checkers on the bar). Then we do supervised
training with this modified trainset. This will hopefully create a more
aggressive player that will be more eager to hit loose on checkers, and
hopefully create a player with an attacking style.

Then - Let's say we do one loop through the training dataset, and for each
position we subtract a little notch to the winning probabilities for all
positions that have a blot that can be hit (and maybe even a bigger notch
if there's several of it's blot that can be hit). Then we do supervised
training with this modified trainset. This will hopefully create a more
careful player that will rather create high stacks than playing flexible.
Typically seen by beginner players. 4-1 opening roll is then played 13/8,
they seldom split backcheckers etc.

Of course I have no idea if this will work or not. But I think I will be
able to do something like this. (But not now as I'm leaving for vacation
tomorrow morning)

We probably need some interface that can read custom neural networks. I
have lost the touch when it comes to GTK coding, but someone may be able to
specify.

-Øystein



fre. 4. aug. 2023 kl. 15:39 skrev Superfly Jon :

> Different nets sound like a good addition for people who want to play
> against the computer.  This could be combined with an old idea of having a
> list of opponents with different characteristics (e.g. more / less
> aggressive) where the move equities are adjusted based e.g. on the number
> of blots, leading to weaker play with different styles.  Maybe the
> different neural nets already do this to some degree?
>
> Unfortunately I haven't the time to commit to this currently, but maybe
> others might and I may have more time in the future.
>
> Jon
>
> On Tue, 1 Aug 2023 at 06:52, Joseph Heled  wrote:
>
>>
>> Hi,
>>
>> As part of my recent research (Elo systems and PR) I generate a number of
>> neural nets, ranging from 500 Elo to about 1800.
>>
>> I thought it might be a nice feature to have for beginners, to play a
>> weaker, less frustrating, computer opponent. Might also be useful for
>> stronger players - practicing playing against weaker players.
>>
>> I am willing to adapt the nets to GNUbg. If anyone wants to collaborate
>> with me on the rest, i.e. user interface and glue to the rest of the
>> system, please contact me and we can discuss feasibility.
>>
>> -Joseph
>>
>

Re: "XG update" - anyone wants to chime in?

[Øystein Schønning-Johansen]

I think this is sad news. I have never been an XG user myself, but having a
commercial product available is important for the backgammon community
(even when an open source project exists).

I think the price indication of the IPR is a bit high. (I guess Xavier
reads this)

I'm estimating a bit. If someone buys the IPR for say $1m and goes to a
bank to get a loan for this amount he/she will probably have an interest
rate at 5% (at least).
If he/she then annually pays $50k to cover the interest, these $50k must be
covered by sales of a product based on the IPR. Before he/she can do that,
some development must be done (development = expenses). Then there are some
marketing costs etc. Can the sales of such a product reach $50k annually,
just to cover financial expenses? If a licence is sold for $100 (a price
increase from today's $60 pr. installation), he/she must sell 500 licenses
each year. I don't know the figures Xavier has today, but since he has
developed this he doesn't have financial expenses for the IPR.

-Øystein

tor. 13. juli 2023 kl. 07:41 skrev Joseph Heled :

>
> This is both funny and sad. Anyone wants to chime in with thoughts and
> prayers?
>
> https://www.facebook.com/groups/1017340842031433/posts/1770919363340240/
>
> -Joseph
>
>

Re: Development - an outsider’s perspective

[Øystein Schønning-Johansen]

tir. 3. jan. 2023 kl. 22:44 skrev Philippe Michel :

> This is not a core library approach either, but I think that in chess
> open source software they tend to use a similar approach, with a few GUI
> applications and many engines using a common communication protocol.
>
> That may be an intresting project for those interested in GUI
> programming. A backgammon GUI front-end, with various back-ends to
> communicate with gnubg, fibs, dailygammon, another GUI over a chat
> application, etc...
>

Yes! The computer chess community did it right! However they ended up with
two different protocols, WinBoard and UCI, which are pretty different.

So, if we plan to make an Engine/GUI separation, we need a good protocol.
We have to define such. Even that is challenging.
What should the engine store and what should the GUI store? Should the
engine know the state of the board, or should that be transferred over the
protocol? Where should the game/match be stored? And what about a rollout?
Should the GUI or the engine organize the rollout? And should we be nice
with others and base a protocol on something? A REST API? Just not SOAP!
*sigh* These are questions that made me abandon the idea...

-Øystein

Best way of converting CVS repo to git ?

[Øystein Schønning-Johansen]

Hi, savannah-users!

I'm one of the maintainers/developers of the GNU project GNU Backgammon
(gnubg) and we are actually still using CVS as our main repo. We would like
to convert our main code base to git, as we strongly believe this has
become the new standard for developing open source projects. Hopefully,
converting from CVS to git will attract new contributors to the project.

The question is: How is it best to do this?

I have already added the git feature on the project admin page, but the git
repo is (of course) still empty.

Best regards,
Øystein Schønning-Johansen
Maintainer/Developer of GNU Backgammon

Re: AW: Development - an outsider’s perspective

[Øystein Schønning-Johansen]

Happy new year to all!

I agree that converting from cvs to git is a good idea. However, GitHub as
the git repo provider may not be the best, and I think that should be
discussed. (I do love GitHub, and I use it for all my personal projects,
but there are some issues ... )

What I rather suggest is that we take a chat with savannah hackers. There
must be other GNU projects that also have the desire to convert from cvs to
git.

Best regards,
-Øystein

PS:
There's a lot of things I would love to do with the code base:
- Move to git
- Get rid of Hungarian naming variables and have better abstract types.
Like there should be a type for board position, move, dice roll, etc.
- Separate the engine from the GUI (This s a huge task that require a lot
of redesign)
- Get the GUI part compatible to GTK4 (This is easier if the above point is
done)
- (lot's of other stuff)


tir. 3. jan. 2023 kl. 00:17 skrev Philippe Michel :

> Hello Carsten,
>
> I agree that using git would have many advantages. I had tried to
> convert the repository (with cvs-fast-export) some time ago, but I'm not
> too familiar with git and wasn't sure the result was right. The
> documentation of cvs-fast-export gives a lot of warnings... On the other
> hand the structure of the gnubg repository seems relatively simple: it
> must have been 10 years or so that branches have not been used.
>
> > About a migration to git: I tried two different tools with different
> results:
> >
> > a) cvs-fast-export, from https://gitlab.com/esr/cvs-fast-export
> > b) cvs2git, part of cvs2svn, from https://github.com/mhagger/cvs2svn
>
> > For a) you can see the result here:
> > https://github.com/carsten-wenderdel/gnubg-fast-export
>
> > - When converting both modules “gnubg” and “gnubg-nn” it moved the
> > latter as a folder “nn” into the “gnubg” folder. That’s strange, but
> > if those two modules/folders don’t reference each other, it shouldn’t
> > harm. Also once in git, those folders can be moved without losing the
> > history.
>
> I converted the gnubg and gnubg-nn subdirectories in separate git repos.
> This seemed more natural to have gnubg at the root of its repo.
>
> > - It didn’t convert the tags properly. We could add tags manually, but
> > still not good.
>
> I don't see anything wrong at your github URL. The tags are present and
> switching to one of them seems to show the right version of the files.
>
> FWIW, what I did was :
>
> rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg/ gnubg-full-cvs/
>
> cvsconvert -v -A authormap gnubg-full-cvs/gnubg
>
> Then, in the created gnubg-full-cvs-gnubg-nn-git directory :
>
> git gc --aggressive
> git checkout master
>
> At this point "git tag" shows the tags, "git checkout " shows
> the right files as far as I can see.
>
> > Another open question: As “author” git would always use the user
> > handle of the CVS committer. Do we want to have full name and email
> > address instead? That’s possible if those tools would be fed with a
> > file mapping those user handles (like “plm”) to full name / email
> > address.
> > As with CVS committer and author often were different people this
> > might not be wanted though.
>
> As the command I gave earlier show, I think it would be preferable to
> have real names and adresses rather than savannah handles, but I don't
> understand your last sentence. I think most of the time the committer
> was the author of the change ; the latter may sometimes have been an
> occasionnal contributor who may or not have been credited in the
> comment, but using names and adresses would allow to do it more
> systematically in the future, wouldn't it ?
>
> > Still hoping to hear more opinions!
>
> What puzzles me most in your suggestions is this :
>
> > > So my suggestion is to first move the repository to GitHub.
>
> Moving to gitub doesn't seem especially urgent to me. First task would
> be ensure that the conversion to a git repo is done right. Your report
> shows some uncertainties in this regard.
>
> Then I would find it natural to clone it to savannah (and, I suppose,
> have the cvs repository made unavailable or at least read-only). That
> would already allow anyone interested to easily clone the repository
> locally, to github, or elsewhere.
>
> Only then could it be envisaged to move the reference origin (and
> possibly everything else, bug reporting, binaries distribution, mailing
> list) elsewhere.
>
> I must be out of touch with the modern open source ecosystem but
>
> > Some developers care about their contribution statistics on GitHub
>
> came as a surprise to me.
>
> A significant enough contribution to have one's name in a documentation,
> readme, changelog? Great! Bug reports and occasionnal suggestions for
> something I use? Obviously! But going in priority where there are
> counters to inflate ???
>
>

Re: Preview of forthcoming gnubg release

[Øystein Schønning-Johansen]

Mark!

I don't think building on Linux systems is really difficult. I rather
suggest that you try to build it from the source at your system, and then
start a new thread here if you get into trouble.

short (untested) sketch of what you need to do:

Get the source code:
Either
 - CVS: cvs -z3 -d:pserver:anonym...@cvs.savannah.gnu.org: /sources/gnubg
co gnubg
 - Tarball: tar zxvf gnubg-release-1.0.-sources.tar.gz

cd gnubg
./autogen.sh
PYTHONWARNINGS=ignore ./configure --prefix=/usr/local
--bindir=/usr/local/bin --sysconfdir=/etc --mandir=/usr/share/man
make
sudo make install

You may have to install some developer tools and libraries before you
start. You probably need GTK developer libraries, and of course a C
compiler (like GCC) and some of the basic developer tools like make aud
automake/autoconf etc. Check the package manager of your distribution.

-Øystein



ons. 9. nov. 2022 kl. 16:09 skrev Mark Neidorff :

> On Monday, November 7, 2022 6:04:28 PM EST guyschwartz wrote:
>
> > Is there a version for android?
>
> >
>
> >
>
> > Sent from my Verizon, Samsung Galaxy smartphone
>
> > Get Outlook for Android
>
> ...and please don't forget linux!!!
>
> --
>
> A verbal contract isn't worth the paper it's printed on.
>
>

Re: Preview of forthcoming gnubg release

[Øystein Schønning-Johansen]

After a first browse and playing some games, I can say it looks very good!
I cannot see any glitches or bugs.

The only comment I have after playing two matches is that it rolls very
good dice for itself. It must be cheating! ;-)

-Øystein

man. 7. nov. 2022 kl. 22:26 skrev Øystein Schønning-Johansen <
oyste...@gmail.com>:

> Sounds promising, I'll give it a try now.
> -Øystein
>
> man. 7. nov. 2022 kl. 21:51 skrev Philippe Michel <
> philippe.mich...@free.fr>:
>
>> I have uploaded a new gnubg Windows build at
>> http://philippe.michel7.free.fr/gnubg/
>>
>> If not for a report of a serious issue I will use this version for a
>> release next week.
>>
>> The corresponding sources (with a few minor changes not yet commited
>> to the cvs repository) and the translations' .po files are available
>> there as well.
>>
>> Besides bug fixes, there are four significant changes since the 1.06
>> version
>>
>> - the 3D graphics have been largely rewritted by Jon Kinsey. Although
>>   there are few visible changes at this time, this should provide the
>>   foundation for improvements and allow to use 3D with more recent
>>   versions of GTK.
>>
>> - the "score map" feature contributed by Aaron Tikuisis and Isaac
>>   Keslassy is included.
>>
>> - the Python interface uses python3 in the above Windows build. It is
>>   still possible build gnubg with python2 but it is likely that the
>>   various Linux distribution providing gnubg will use python3 as well.
>>
>> - the user interface translation is much more comprehensive that it
>>   used to be. UTF-8 encoding is used for all of them.
>>
>>

Re: Preview of forthcoming gnubg release

[Øystein Schønning-Johansen]

Sounds promising, I'll give it a try now.
-Øystein

man. 7. nov. 2022 kl. 21:51 skrev Philippe Michel :

> I have uploaded a new gnubg Windows build at
> http://philippe.michel7.free.fr/gnubg/
>
> If not for a report of a serious issue I will use this version for a
> release next week.
>
> The corresponding sources (with a few minor changes not yet commited
> to the cvs repository) and the translations' .po files are available
> there as well.
>
> Besides bug fixes, there are four significant changes since the 1.06
> version
>
> - the 3D graphics have been largely rewritted by Jon Kinsey. Although
>   there are few visible changes at this time, this should provide the
>   foundation for improvements and allow to use 3D with more recent
>   versions of GTK.
>
> - the "score map" feature contributed by Aaron Tikuisis and Isaac
>   Keslassy is included.
>
> - the Python interface uses python3 in the above Windows build. It is
>   still possible build gnubg with python2 but it is likely that the
>   various Linux distribution providing gnubg will use python3 as well.
>
> - the user interface translation is much more comprehensive that it
>   used to be. UTF-8 encoding is used for all of them.
>
>

Re: Rollouts

[Øystein Schønning-Johansen]

It's just an option for use with initial positions, such that the first
roll is never a double. Nice if you want to roll out a match equity table.
I'm not sure how it handle the turn, when this option is used. I think I
have to read the code to answer that.

-Ø

On Mon, Oct 17, 2022, 14:22 Ezequiel Galarce  wrote:

> Hi, I can't understand what the "Rollout as initial position" option is
> for.
>

Re: Tools to convert xg file format to sgf

[Øystein Schønning-Johansen]

The Smart Game Format (sgf) is pretty good documented here:
https://www.red-bean.com/sgf/

It was developed for Go, but Gary liked it, so he made a spec for
backgammon.

-Øystein

lør. 15. okt. 2022 kl. 18:56 skrev Turker Eflanli :

> It just parses the file, with the python scripts attached to this email
> thread, then shows biggest jokers and biggest blunders, nothing fancy, just
> makes it easier to concentrate on big errors
>
> On Sat, Oct 15, 2022 at 11:03 Chris Wilson  wrote:
>
>> Sounds interesting. Would you be willing to make your program public? I'd
>> love to see its output.
>>
>> On Sat, Oct 15, 2022 at 7:50 AM Turker Eflanli 
>> wrote:
>>
>>> Thanks! However, I have a program that reads an XG file and creates a
>>> report. I would like to do the same on an sgf file, so I either need to
>>> convert it to xg format or need to figure out the sgf format itself so I
>>> can update my own program. I want to be able to do all this without the
>>> help of either XG or GNU interfaces
>>>
>>> On Sat, Oct 15, 2022 at 10:44 AM Chris Wilson 
>>> wrote:
>>>
>>>> XG supports importing .sgf files. Look under File>Import>GnuBG.
>>>>
>>>> Chris
>>>>
>>>> On Sat, Oct 15, 2022 at 7:36 AM Turker Eflanli 
>>>> wrote:
>>>>
>>>>> Does anyone know a way to convert a GNU analyzed sgf file to xg
>>>>> format? If not, is there documentation that explains the sgf format?
>>>>>
>>>>> Thanks in advance
>>>>> Turker Eflanli
>>>>>
>>>>> On Sun, Aug 14, 2022 at 3:36 AM Øystein Schønning-Johansen <
>>>>> oyste...@gmail.com> wrote:
>>>>>
>>>>>> Thank you so much, Turker.
>>>>>>
>>>>>> I see I get some problems with this code when I try to read the
>>>>>> WC2022 final, however, I think the problems are solvable.
>>>>>>
>>>>>> I've gathered the code in a github repository:
>>>>>> https://github.com/oysteijo/xgdatatools
>>>>>>
>>>>>> And just as I did that, I also saw that another github user has
>>>>>> already done the same 3 years ago:
>>>>>> https://github.com/zkitX/xgdatatools
>>>>>>
>>>>>> -Øystein
>>>>>>
>>>>>> fre. 12. aug. 2022 kl. 19:09 skrev Turker Eflanli <
>>>>>> turkerefla...@gmail.com>:
>>>>>>
>>>>>>> Here they are - I don't remember where I had downloaded them from
>>>>>>>
>>>>>>> On Fri, Aug 12, 2022 at 12:01 PM Øystein Schønning-Johansen <
>>>>>>> oyste...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thank you so much, Turker!
>>>>>>>>
>>>>>>>> However, it would still be good to have the Petch-tools. :-)
>>>>>>>>
>>>>>>>> -Øystein
>>>>>>>>
>>>>>>>> fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli <
>>>>>>>> turkerefla...@gmail.com>:
>>>>>>>>
>>>>>>>>> Øystein,
>>>>>>>>>
>>>>>>>>> Find attached the raw file that you can analyze in GNU
>>>>>>>>>
>>>>>>>>> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
>>>>>>>>> oyste...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>> I was thinking of analysing the WC 2022 final and found the final
>>>>>>>>>> available in .xg format.
>>>>>>>>>>
>>>>>>>>>> I think Michael Petch wrote some tools to convert xg file into
>>>>>>>>>> sgf format. Are these tools available somewhere?
>>>>>>>>>>
>>>>>>>>>> It states at: https://www.extremegammon.com/XGformat.aspx
>>>>>>>>>> that the python source for his tools are here:
>>>>>>>>>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>>>>>>>>>
>>>>>>>>>> However, it looks like this site is down.
>>>>>>>>>>
>>>>>>>>>> BTW: How is Michael? Is he still subscribing to this list? I've
>>>>>>>>>> not heard from him in a long time. He posts on his FB profile, but 
>>>>>>>>>> he isn't
>>>>>>>>>> very responsive. :-)
>>>>>>>>>>
>>>>>>>>>> -Øystein
>>>>>>>>>>
>>>>>>>>>

Re: Preview of next gnubg release

[Øystein Schønning-Johansen]

Hi!

I found another glitch! When setting up a position in edit mode, and then
releasing the edit button, I am not able to roll the dice on my turn. This
is indeed different behaviour compared to linux build and the "official"
Windows-build.

-Øystein

ons. 24. aug. 2022 kl. 10:18 skrev Øystein Schønning-Johansen <
oyste...@gmail.com>:

> Ha!
>
> Sorry for the late reply. Now that I actually have a Windows computer and
> some other postings on the list got me interested again; I finally
> downloaded this "dev" release. 20220703
>
> It looks fine to me. I love the new !Score map! feature!
> After playing a few games, I've not seen any glitches so far.
>
> When it comes to the python interface, I personally never use TkInter.
> (Just the tty). I also think that the python interface is really for
> "hackers" only, and it might be just as good to leave this out the build.
>
> Does it still use GTK2? Yiikes!
>
> Also, I see that this build is with SSE/SSE2 support. Can you make your
> "dev"-build with AVX support?
>
> -Øystein
>
>
>
> ons. 11. mai 2022 kl. 11:57 skrev Jon Kinsey :
>
>> Which version of GTK is this using, 2 I’m guessing. I stopped with the 3d
>> changes as gtk3 hasn’t got great 3d widget support. Gtk4 does though so
>> would be up for helping with a gtk4 upgrade and finishing the modern 3d
>> changes.
>>
>> Jon
>>
>> > On 10 May 2022, at 22:23, Philippe Michel 
>> wrote:
>> >
>> > I have uploaded a gnubg Windows build that should be close to its next
>> > release at http://philippe.michel7.free.fr/gnubg/
>> >
>> > The corresponding sources (with a few minor changes not yet commited
>> > to the cvs repository) and the translations' .po files are available
>> > there as well.
>> >
>> > Besides bug fixes, there are four significant changes since the 1.06
>> > version
>> >
>> > - the 3D graphics have been largely rewritted by Jon Kinsey. Although
>> >  there are few visible changes at this time, this should provide the
>> >  foundation for improvements and allow to use 3D with more recent
>> >  versions of GTK.
>> >
>> > - the "score map" feature contributed by Aaron Tikuisis and Isaac
>> >  Keslassy is included.
>> >
>> > - the Python interface uses python3 in the above Windows build. It is
>> >  still possible build gnubg with python2 but it is likely that the
>> >  various Linux distribution providing gnubg will use python3 as well.
>> >
>> > - the user interface translation is much more comprehensive that it
>> >  used to be. UTF-8 encoding is used for all of them.
>> >
>> >
>> > Besides general bug reports, I would be especially interested by
>> > feedback on the following points:
>> >
>> > - things that I cannot check myself: does it work on Windows 11? Is
>> >  the GUI in general, not specifically in 3D, fine on high resolution
>> >  (more than 1920x1080), high DPI screens?
>> >
>> > - the defaults for the scoremap feature. For instance it starts every
>> >  evaluation at 0 ply and one can reevalute at a higher level ; I like
>> >  retaining the previous level but that means that following initial
>> >  evaluations are slower. Default match length for a checker move
>> >  evaluation is 3 ; I like 5 but it is slower, especially combined
>> >  with the above.
>> >
>> > - if you use the Python interface, how do you do it ? From the tty
>> >  only ? There is a regression in the GUI version: the tkinter
>> >  interface from the previous version does not seem to work with
>> >  Python3 ; I got a lot of deprecation warnings on Linux and couldn't
>> >  make it work at all under Windows.
>> >  I'm not familiar with Python, but it seems the more popular modern
>> >  fancy interface to Python are the Jupyter notebooks. What would be
>> >  needed to make that available in Linux? (where we use the system
>> >  Python) On Windows? (where we provide it)
>> >
>> >
>> > Updates to the .po translation files would be useful (there is now a
>> > 100% complete Finnish file, the other languages lag far behind).
>> >
>> >
>> > There is no real prospect of a MacOS build. A useful start would be to
>> > find someone familiar with building software from MacPorts or Homebrew
>> > who would be willing to maintain a gnubg port there.
>> >
>>
>>

Re: Preview of next gnubg release

[Øystein Schønning-Johansen]

Ha!

Sorry for the late reply. Now that I actually have a Windows computer and
some other postings on the list got me interested again; I finally
downloaded this "dev" release. 20220703

It looks fine to me. I love the new !Score map! feature!
After playing a few games, I've not seen any glitches so far.

When it comes to the python interface, I personally never use TkInter.
(Just the tty). I also think that the python interface is really for
"hackers" only, and it might be just as good to leave this out the build.

Does it still use GTK2? Yiikes!

Also, I see that this build is with SSE/SSE2 support. Can you make your
"dev"-build with AVX support?

-Øystein



ons. 11. mai 2022 kl. 11:57 skrev Jon Kinsey :

> Which version of GTK is this using, 2 I’m guessing. I stopped with the 3d
> changes as gtk3 hasn’t got great 3d widget support. Gtk4 does though so
> would be up for helping with a gtk4 upgrade and finishing the modern 3d
> changes.
>
> Jon
>
> > On 10 May 2022, at 22:23, Philippe Michel 
> wrote:
> >
> > I have uploaded a gnubg Windows build that should be close to its next
> > release at http://philippe.michel7.free.fr/gnubg/
> >
> > The corresponding sources (with a few minor changes not yet commited
> > to the cvs repository) and the translations' .po files are available
> > there as well.
> >
> > Besides bug fixes, there are four significant changes since the 1.06
> > version
> >
> > - the 3D graphics have been largely rewritted by Jon Kinsey. Although
> >  there are few visible changes at this time, this should provide the
> >  foundation for improvements and allow to use 3D with more recent
> >  versions of GTK.
> >
> > - the "score map" feature contributed by Aaron Tikuisis and Isaac
> >  Keslassy is included.
> >
> > - the Python interface uses python3 in the above Windows build. It is
> >  still possible build gnubg with python2 but it is likely that the
> >  various Linux distribution providing gnubg will use python3 as well.
> >
> > - the user interface translation is much more comprehensive that it
> >  used to be. UTF-8 encoding is used for all of them.
> >
> >
> > Besides general bug reports, I would be especially interested by
> > feedback on the following points:
> >
> > - things that I cannot check myself: does it work on Windows 11? Is
> >  the GUI in general, not specifically in 3D, fine on high resolution
> >  (more than 1920x1080), high DPI screens?
> >
> > - the defaults for the scoremap feature. For instance it starts every
> >  evaluation at 0 ply and one can reevalute at a higher level ; I like
> >  retaining the previous level but that means that following initial
> >  evaluations are slower. Default match length for a checker move
> >  evaluation is 3 ; I like 5 but it is slower, especially combined
> >  with the above.
> >
> > - if you use the Python interface, how do you do it ? From the tty
> >  only ? There is a regression in the GUI version: the tkinter
> >  interface from the previous version does not seem to work with
> >  Python3 ; I got a lot of deprecation warnings on Linux and couldn't
> >  make it work at all under Windows.
> >  I'm not familiar with Python, but it seems the more popular modern
> >  fancy interface to Python are the Jupyter notebooks. What would be
> >  needed to make that available in Linux? (where we use the system
> >  Python) On Windows? (where we provide it)
> >
> >
> > Updates to the .po translation files would be useful (there is now a
> > 100% complete Finnish file, the other languages lag far behind).
> >
> >
> > There is no real prospect of a MacOS build. A useful start would be to
> > find someone familiar with building software from MacPorts or Homebrew
> > who would be willing to maintain a gnubg port there.
> >
>
>

Re: GNU Backgammon

[Øystein Schønning-Johansen]

Yes!

I am also very skeptical of the effect of skewed match equity tables. Why
should this work?
If the best player is better he has a higher probability of winning, so
his/her doubling point is appearing earlier.

However in a position type where skill is not really dominant, say no
contact position, the doubling from the strongest player should rather be
delayed to avoid the underdog being lucky.

I strongly believe that cube handling in matches of uneven players should
rather consider the skill needed to play the specific position on the
board. Just making a skewed MET is in my opinion not the solution.

As a serious besserwisser, I am (in this case) not willing to make any
effort to do any type of experiments to prove me right. (I'm just using the
same logic as flat-earthers and ani-vaxxers etc.) :-)

-Øystein

tir. 23. aug. 2022 kl. 19:56 skrev Joseph Heled :

>
> A personal note, if I may.
>
> Back in the day I dabbled with rating adjusted equity tables, i.e. having
> the stronger player use an adjusted equity table based on the rating
> difference.
>
> I was never able to make it work. If anything, it ended up with the higher
> rated "player" doing worse. It's possible I implemented it wrong, but I
> would like to see some evidence first ...
>
> Also, using different equity tables rarely makes a difference in actual
> play. Again I struggled to prove that one equity table is much better in
> practice than others.
> With todays computing power it should be much easier to set up
> experiments. Anyone up to the task?
>
> (Ian might remember how I distributed the rollouts for the net training. I
> could not have done it without you or the others!!!)
>
> -Joseph
>
>
> On Wed, 24 Aug 2022 at 05:12, Ian Shaw  wrote:
>
>> Thanks David.
>>
>>
>>
>> That T-12 is very interesting. I see that the subsequent tables are based
>> on an increasing cubeless win % by 1% per 50 rating points.
>>
>>
>>
>> The Elo formula gives a higher win rate for a given rating (in a 1-point
>> match) than the equivalent Jacobs Table.
>>
>>
>>
>> *Table #*
>>
>> *Page*
>>
>> *Rating point difference*
>>
>> *Jacobs Table cpw*
>>
>> *Elo cpw*
>>
>> T-13
>>
>> 32
>>
>> 0 (even)
>>
>> 50.0
>>
>> 50.0
>>
>> T-15
>>
>> 34
>>
>> 100
>>
>> 52.0
>>
>> 52.9
>>
>> T-17
>>
>> 36
>>
>> 200
>>
>> 54.0
>>
>> 55.7
>>
>> T-19
>>
>> 38
>>
>> 300
>>
>> 56.0
>>
>> 58.6
>>
>>
>>
>> I’ll try to construct the xml files for the tables over the next few
>> days.
>>
>>
>>
>> -- Ian
>>
>>
>>
>>
>>
>>
>>
>> *From:* pub...@booksongaming.com 
>> *Sent:* 23 August 2022 17:33
>> *To:* Ian Shaw ; 'Øystein Schønning-Johansen' <
>> oyste...@gmail.com>; 'Ezequiel Galarce' ;
>> 'bug-gnubg' 
>> *Subject:* RE: GNU Backgammon
>>
>>
>>
>> Ian et al,
>>
>>
>>
>> I also included T-12 which gives the parameters for subsequent tables.
>> Let me know if you want more.
>>
>>
>>
>> I’m also not sure how happy the list-serv is with 5MB of attachments. I
>> can find other ways to send them if need be.
>>
>>
>>
>> Best,
>>
>>
>>
>> David
>>
>>
>>
>> *From:* Ian Shaw 
>> *Sent:* Tuesday, August 23, 2022 12:59 AM
>> *To:* public@booksongamingcom ; 'Øystein
>> Schønning-Johansen' ; 'Ezequiel Galarce' <
>> egala...@gmail.com>; 'bug-gnubg' 
>> *Subject:* RE: GNU Backgammon
>>
>>
>>
>> Hi David,
>>
>>
>>
>> From
>> https://bkgm.com/articles/Sengoku/GraphicalMatchEquity/FishEffects/index.html
>> I understand that these are the tables used for compiling the METs.
>>
>>
>>
>> Since we have a jac50, I assume that one would be T-14.
>>
>> If you could send a picture of T-17 and T-19, that would be great.
>>
>>
>>
>> *Table #*
>>
>> *Page*
>>
>> *Rating point difference*
>>
>> T-13
>>
>> 32
>>
>> 0 (even)
>>
>> T-15
>>
>> 34
>>
>> 100
>>
>> T-17
>>
>> 36
>>
>> 200
>>
>> T-19
>>
>> 38
>>
>> 300
>>
>>
>>
>> Thanks,
>>
>> Ian Sha

Re: GNU Backgammon

[Øystein Schønning-Johansen]

Hmmm

If my archive remembers correctly there never was a jac200 table. I don't
have a copy of "Can a Fish Taste Twice as Good?", is it even a table in
that book? I find no file called jac200.xml in the CVS attic either. So if
there was a file called jac200,xml it must have been a local contribution
that never was checked in.

The guy who contributed this was named Craig Campbell. (Must be 20 years
ago or so) Is it possible to get hold of him?

-Øystein

man. 22. aug. 2022 kl. 17:27 skrev Ezequiel Galarce :

> I don't know, I'm asking the creator of the equity table, maybe he has it
>
> El lun., 22 ago. 2022 16:06, Ian Shaw  escribió:
>
>> H Ezequiel,
>>
>>
>>
>> Now that you mention it, I think you’re right. I wonder why it’s been
>> omitted from the installation.
>>
>>
>>
>> Does anyone here have a copy of the jac200 MET?
>>
>>
>>
>> -- Ian
>>
>>
>>
>> *From:* Ezequiel Galarce 
>> *Sent:* 22 August 2022 15:01
>> *To:* Ian Shaw 
>> *Subject:* Re: GNU Backgammon
>>
>>
>>
>> Hello, I have contacted the creator of "jac050" and "jac100" and he told
>> me that he thinks he remembers that he had made a "jac200", I don't have
>> any data.
>>
>>
>>
>> El lun., 22 ago. 2022 12:51, Ian Shaw 
>> escribió:
>>
>> Hi Ezequiel,
>>
>>
>>
>> I don’t think the jac200 table is available on line.
>>
>>
>>
>> If you have the raw data, it’s easy to make a MET that gnubg can use. I
>> could create one if you can find the data.
>>
>>
>>
>> Regards,
>>
>> Ian
>>
>>
>>
>>
>>
>> *From:* Ezequiel Galarce 
>> *Sent:* 19 August 2022 22:19
>> *To:* Ian Shaw 
>> *Subject:* Re: GNU Backgammon
>>
>>
>>
>> Hello good evening, can you get the equity table "jac200.xml"?
>>
>>
>>
>> El vie., 19 ago. 2022 14:54, Ian Shaw 
>> escribió:
>>
>>

Re: Tools to convert xg file format to sgf

[Øystein Schønning-Johansen]

Thank you so much, Turker.

I see I get some problems with this code when I try to read the WC2022
final, however, I think the problems are solvable.

I've gathered the code in a github repository:
https://github.com/oysteijo/xgdatatools

And just as I did that, I also saw that another github user has already
done the same 3 years ago:
https://github.com/zkitX/xgdatatools

-Øystein

fre. 12. aug. 2022 kl. 19:09 skrev Turker Eflanli :

> Here they are - I don't remember where I had downloaded them from
>
> On Fri, Aug 12, 2022 at 12:01 PM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Thank you so much, Turker!
>>
>> However, it would still be good to have the Petch-tools. :-)
>>
>> -Øystein
>>
>> fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli <
>> turkerefla...@gmail.com>:
>>
>>> Øystein,
>>>
>>> Find attached the raw file that you can analyze in GNU
>>>
>>> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
>>> oyste...@gmail.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> I was thinking of analysing the WC 2022 final and found the final
>>>> available in .xg format.
>>>>
>>>> I think Michael Petch wrote some tools to convert xg file into sgf
>>>> format. Are these tools available somewhere?
>>>>
>>>> It states at: https://www.extremegammon.com/XGformat.aspx
>>>> that the python source for his tools are here:
>>>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>>>
>>>> However, it looks like this site is down.
>>>>
>>>> BTW: How is Michael? Is he still subscribing to this list? I've not
>>>> heard from him in a long time. He posts on his FB profile, but he isn't
>>>> very responsive. :-)
>>>>
>>>> -Øystein
>>>>
>>>

Re: Tools to convert xg file format to sgf

[Øystein Schønning-Johansen]

Thank you so much, Turker!

However, it would still be good to have the Petch-tools. :-)

-Øystein

fre. 12. aug. 2022 kl. 16:58 skrev Turker Eflanli :

> Øystein,
>
> Find attached the raw file that you can analyze in GNU
>
> On Fri, Aug 12, 2022 at 10:12 AM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Hi!
>>
>> I was thinking of analysing the WC 2022 final and found the final
>> available in .xg format.
>>
>> I think Michael Petch wrote some tools to convert xg file into sgf
>> format. Are these tools available somewhere?
>>
>> It states at: https://www.extremegammon.com/XGformat.aspx
>> that the python source for his tools are here:
>> http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git
>>
>> However, it looks like this site is down.
>>
>> BTW: How is Michael? Is he still subscribing to this list? I've not heard
>> from him in a long time. He posts on his FB profile, but he isn't very
>> responsive. :-)
>>
>> -Øystein
>>
>

Tools to convert xg file format to sgf

[Øystein Schønning-Johansen]

Hi!

I was thinking of analysing the WC 2022 final and found the final available
in .xg format.

I think Michael Petch wrote some tools to convert xg file into sgf format.
Are these tools available somewhere?

It states at: https://www.extremegammon.com/XGformat.aspx
that the python source for his tools are here:
http://vcs.capp-sysware.com/gitweb/?p=backgammon/xgdatatools.git

However, it looks like this site is down.

BTW: How is Michael? Is he still subscribing to this list? I've not heard
from him in a long time. He posts on his FB profile, but he isn't very
responsive. :-)

-Øystein

Re: gnubg score map feature

[Øystein Schønning-Johansen]

What about granting Aaron write access to the CVS?
-Ø

On Tue, Sep 14, 2021 at 8:37 AM Christian Anthon 
wrote:

> The easiest way is to post the code on the gnubg bug tracker on savannah
>
> On Mon, 13 Sep 2021 at 08.29, Gnubg  wrote:
>
>> Hi Aaron,
>>
>> I forward your e-mail to the list. You can also subscribe there though
>> there is not much traffic for a while.
>> https://mail.gnu.org/mailman/listinfo/bug-gnubg
>>
>> Ciao
>>
>> Achim
>>
>> Anfang der weitergeleiteten Nachricht:
>>
>>
>> *Von: *Aaron Tikuisis 
>> *Betreff: **gnubg score map feature*
>> *Datum: *12. September 2021 um 22:43:00 MESZ
>> *An: *"bug-gnubg-ow...@gnu.org" 
>> *Kopie: *Isaac Keslassy 
>>
>> Dear (whoever runs this email address),
>>
>> Isaac Keslassy and I worked a bit more on the score map feature,
>> including getting rid of some bugs. (Notably, it doesn't seg fault any more
>> 😉 - and I've been using our build of gnubg all the time for some months.)
>> I'd like to share the updated code with the community, though I don't have
>> cvs access. (I've found that some other people are interested in this
>> feature, though they aren't enthusiastic about having to compile the code
>> themselves.) Could you let me know how I can upload the updated code?
>>
>> Best regards,
>> Aaron
>>
>>
>>

Re: GNU Backgammon Clones

[Øystein Schønning-Johansen]

Yeah!

Good points, Ian. Maybe it is possible to "reverse engineer" the
executable code of the potential clones and see if it matches the weights
of a neural network from GNU Backgammon. The weights of a neural network
will indeed be sequential in memory as in GNU Backgammon. This will be
strong enough prof to bust someone. THat is a much stronger prof than
vaguely claiming they play the same moves. However, these take
competence of decomiling and investigation of windows executables. (A
competence I do not have, but may be able to learn)

However:
What do we intend to do if we can confirm that these are real clones?
I guess the "author" doesn't make a lot of dough from his sales?

-Øystein

On Wed, Jun 23, 2021 at 10:46 AM Ian Shaw  wrote:

> Hi Jeurgen,
>
>
>
> The techniques for creating a strong backgammon program are well known,
> and any strong bot is going to make the same move as another strong bot,
> simply because it is the correct move.
>
>
>
> The main way to demonstrate that the nets are identical is to show that
> they make the same move in all circumstances. This is complicated by the
> fact that the net can be set with various evaluation parameters so that the
> same network will make different moves, depending on the search depth,
> move-pruning settings and so on.
>
>
>
> I’m afraid I can’t help with getting hold of old versions. Perhaps some of
> the developers would know if they are somewhere in the depository.
>
>
>
> What is the problem you are trying to solve? Gnubg is an open source
> program, so people are allowed to take it and use it as they like, even to
> the point to selling it. However, they would be breaching the licence if
> they didn’t include the gnu licence in their software and make the source
> code available. Is this your concern.
>
>
>
> Regards,
>
> n  *Ian Shaw*
>
>
>
> *From:* Bug-gnubg [mailto:bug-gnubg-bounces+ian.shaw=
> riverauto.co...@gnu.org] *On Behalf Of *Juergen Schaefer
> *Sent:* 22 June 2021 22:35
> *To:* bug-gnubg@gnu.org
> *Subject:* GNU Backgammon Clones
>
>
>
> Hi !
>
>
>
> GNU Backgammon Clones
>
>
>
> It's a very "sensitive theme" and a difficult problem: cloning.
>
> Is it possible to track down, to prove that a certain program is a clone
> of GNU Backgammon ?
>
>
>
> Since about 20 years there are some programs commercially available (by
> the same author)...
>
> frankly spoken I believe that all these programs are not driven by an
> original engine,
> but their evaluation engines are based on GNU Backgammon.
> IMHO in fact it's GNUBG in disguise, simply put: clones.
>
>
>
> We have only the source code of one program (GNUBG) - a direct comparison
> isn't possible.
>
> So I can only try to collect circumstantial evidence instead.
>
>
>
> GNUBG started in 1999, shortly afterwards (about 2001) the first suspected
> program
>
> was on the market.
> Until now there are at least 6 of them published by the same author.
>
>
>
> The features of the "clones" are very similar to GNUBG's - the playing
> strength also.
>
>
> Whereas the GUI of the "clones" is "shaky", almost clumsy.
>
>
>
> For example there is a serious bug in the move generator, a "clone"
> doesn't accept
>
> a possible move while bearing off !!
>
>
>
> "Clone"  Opponent pip count 87:27
> Bar 1x   1   3x
> 9   1x   2   2x
> 18  2x   3   2x
> 20  3x   4   2x
> 22  3x   6   1x
> 23  3x   ab  5x
> 24  2x
>
> Opponent rolls 5+3 - the (best) legal move 6/3 4/off isn't shown
> respectively
> won`t be accepted at all by the "clone" GUI, the "clone program" accepts
> only
> 6/1 3/off and 6/1 4/1 !!
>
>
>
> Really bad for a program that plays at world class level !
>
>
>
> GNUBG has 5 main levels:
> 1. World class
> 2. Expert
> 3. Advanced
> 4. Intermediate
> 5. Beginner
>
>
>
> Might happen by accident that the "clone programs" also always have 5
> levels.
>
>
>
> But how about the "treacherous" beaver feature:
> beavers are not part of the official backgammon rules - so why bother with
> this superfluous stuff ?
>
>
>
> How many programs do you know which have implemented the option beaver
> being open source - exactly one, GNUBG - who else ?
>
>
>
> The "clones" use another dice generator which appearantly isn't working
> very well:
> 2 identical games within a few hours with 8 moves respectively 36 moves
> each.
> How likely is that ?
>
>
>
> The identical games were played the same day within a few hours...the dice
> generator of the "clones" seems to work quite odd...doesn't it ?
>
>
> Repeating dice numbers within such a short period - Mersenne Twister
> provides
> better randomness.
>
>
>
> I think all "clone programs" are neural nets like GNUBG - not only like
> GNUBG,
> IMHO GNUBG based.
>
>
> Although at first sight it might look like that these programs have no
> bearoff database
>
> nor weight files. Probably incorporated directly into the exe-files which
> are quite large
>
> (about 4 MB) ?!
>
>
>
> I am convinced that none of the "clone programs" will

Re: Snowie and GNUBG

[Øystein Schønning-Johansen]

Absolutely true. I would love to see a web based graphic user interface for
the gnu backgammon engine. Say React or Angular or something
javascript-ish. (Non of these are my cup of tea)

-Øystein

On Wed, Dec 2, 2020, 21:16 Rich Heimlich  wrote:

> There's one other big reality here and that's that people are quickly
> tiring of downloading apps, especially like this one. They want to play it
> online or on their phone. They have no choice for larger PC games so Steam
> does well there, but for "throw-away games" the limitations of it being on
> Windows alone or having to compile it? No way.
>
> On Wed, Dec 2, 2020 at 2:58 PM Rich Heimlich  wrote:
>
>> Well, let's also be clear about some harsh realities here. Backgammon is
>> always going to be seen in the same light as checkers. It just is. No
>> matter how big the following, it's never going to be chess or have that
>> sort of following. It's pretty much seen as a beginner's game that you keep
>> around because it's easy to teach and play. We know differently, but that
>> takes exposure. If anyone here doubts that, just look at the OVERWHELMING
>> number of reviews of virtually any even remotely decent backgammon game.
>> They're flooded with cries of cheating dice rolls and that's simply due to
>> no one believing that backgammon could possibly be played that well. They
>> used to win at it all the time and now a computer program hoses them so
>> they swear it must be cheating -- yet the same people would not act the
>> same way about a chess program beating them. Chess is "complicated" so of
>> course a computer can beat them.
>>
>> That's the big challenge for backgammon apps today. They're all over the
>> place, generally free and lowly-regarded. Gaining market share in that sort
>> of environment is a tough climb.
>>
>

Re: Snowie and GNUBG

[Øystein Schønning-Johansen]

No, you're not.

I agree with you that GNU is stronger than Snowie from what I see, but I
have never made any full analysis as I do not have an installation of
Snowie. Since I do not have a full analysis that compares the strength, I
cannot quantify the internal strength between them. You write "much
stronger", well... I cannot say how much...

But I believe it is stronger from what I see.

-Øystein

On Fri, Nov 27, 2020 at 10:06 PM Joseph Heled  wrote:

>
> Marc Olsen, in his BG Galaxy stream, said that GNUBG is slightly stronger
> than Snowie and XG is slightly stronger than GNUBG.
>
> My recollection is that GNUBG was much stronger than Snowie even 15 years
> ago. And 2020 GNUBG is stronger than 2005 GNUBG.
>
> Am I missing something?
>
> -Joseph
>
>

Re: cvs project member checkout?

[Øystein Schønning-Johansen]

>
> Works fine from here (after I updated my very very old ssh keys anyway)
> are you sure you are on a network that allows ssh out?
>
I would strongly believe it allows since I can indeed ssh out to other
far-away computers.
I have even tried to create a new key-pair, but still no success. I can
still only do pserver:anonymous.

Update:
Aha! I found it! I have to set en environment variable:

$ export CVS_RSH=ssh

... then it works.

-Øystein

cvs project member checkout?

[Øystein Schønning-Johansen]

Hi!

When I try to checkout the sources as a project member, savannah says the
network is unreachable,

[oystein@jupiter oystein]$ cvs -z3
-d:ext:oyste...@cvs.savannah.gnu.org:/sources/gnubg
co gnubg
connect to address 209.51.188.81: Connection timed out
Trying 2001:470:142::81...
cvs.savannah.gnu.org: Network is unreachable
cvs [checkout aborted]: end of file from server (consult above messages if
any)

If I check out with pserver:anonymous, it works just fine. I have verified
my ssh key on savannah. Has anyone else had this problem? (Isaac has a
similar problem, I believe)

-Øystein

Re: The status of gnubg?

[Øystein Schønning-Johansen]

On Mon, Oct 19, 2020 at 7:52 PM Joseph Heled  wrote:

> I can comment on that: my experience from 20 years ago was that at some
> stage adding positions started to hurt the net performance. It is always a
> balancing act between getting the common/regular positions right and
> getting the edge cases right. I think that whatever you do you might want
> to start fresh and see how my "method" (as you outlined above) can be
> improved.
>

Yes, I think I remember that you have mentioned that before. The reasoning
behind it might be due to the size (hence capacity) of the neural network.
Maybe, with a bigger and deeper neural network, and modern training
algorithms, a bigger training set can be used and still get better
performance. As you say, there is a sweet spot between getting the common
positions right, and then getting the edge cases right.

Yes, the outlined method is (of course) Joseph's idea. In my view, he is
the best backgammon neural network trainer. Maybe I should start this
process on my own, and gain some experience before involving a community
with effort. It will be really unfortunate if we waste resources on a
braindead idea.

How can the outlined idea be improved? Before I get into that, I think I
need some experience, but maybe see if there's some special kind of
positions that's over or under represented in the set, and then
automagically (in some way) detect these?

-Øystein

Re: The status of gnubg?

[Øystein Schønning-Johansen]

Hi,

A method that has been tried out goes something like this:

Step 1: Collect positions:

   - Let the computer play self play, in many games.
   - While playing, at each move, check if the 2-ply move selected move is
   the same as 0-ply selected move.
   - if move_0ply != move_2ply -> store both resulting positions from the
   0-ply move and the 2-ply move in some datastore (typically just a file).
   - continue self play until you think you have collected enough
   positions. (What criteria that should be... boredom maybe?)

Step 2: Rollout.

   - All positions collected in step 1, are then rolled out such that the
   best possible evaluation is found.

Step 3: Supervised training.

   - All positions from the rollouts date above are then used for
   supervised training.


The new trained neural network you now got, is hopefully better than the
one you had before you started this process? (However you MUST verify that
in some way, and it is best if you have a verification method ready before
you even start the training. If not you can verify that you have improved
the network by having the new and the old network play against each other.)

And if you still think your neural network can be further improved, just
start doing this again from Step 1.

OK. Some discussion:
The time consuming steps here are actually step 1 and step 2. Step 3,
supervised training, is pretty fast with modern methods and hardware.
Packages like Keras and PyTorch, (Chainer, Caffe, CNTK, Tensorflow or
whatever)  that can utilize GPU and TPU can train neural networks in
minutes (instead of weeks). I already have tools to convert Keras and
PyTorch neural nets to GNU Backgammon neural nets. (and the other way). So
that is good news. However, more good news: the first two steps are highly
distributable. Say we just make a simple tools chain and we start up 10-20
computers (Or maybe Ian has a lot of spare computers ;-), I guess the
modern self play can find 2-3 0-ply 2ply mismatches pr. second (I'm just
guessing?) to collect positions as described in step 1. We (or anyone
volunteering) can start each of our collection processes on the equipment
we got. Then if the same volunteers can rollout the positions with another
tool (in the same toolchain) doing step 2. I then think we can get
something going.

So, please join me in this discussion: Can we organize for such collective
effort? I can share some tools. Joseph? Do you have some input? How many
positions do you think we need? Will anyone join?

Thanks,
-Øystein

On Mon, Oct 19, 2020 at 4:01 PM Aaron Tikuisis 
wrote:

> I see, that's very interesting. I'll make sure not to use ctrl-g for
> skewed situations like this!
> So the real problem is that it thinks that gammon chances are near 0 for a
> position like this, when in fact it is 25%:
> ​ GNU Backgammon  Position ID: h+sPAQD3rQEAAA
>  Match ID   : EAEE
>  +12-11-10--9--8--7---6--5--4--3--2--1-+ O: gnubg
>  |  |   |O  O  O  O  O | O   0 points
>  |  |   |O O  O  O | O   On roll
>  |  |   | O  O |
>  |  |   | O|
>  |  |   | O|
> ^|  |BAR|  |
>  |7 |   |  |
>  |X |   |  |
>  |X |   |X   X |
>  |X |   |X   X |
>  |X   X |   | X  X   X | 0 points
>  +13-14-15-16-17-18--19-20-21-22-23-24-+ X: aaron (Cube: 1)
>
>
> I'm not an expert but I'd think the NN should be able to learn this better
> - why not just try to train it more?
>
> Is gnubg currently able to keep a database of its own 0-ply blunders?
> (Like, every time it does an evaluation, compare the higher-ply result with
> the 0-ply result and if the 0-ply errs by a large enough threshhold, add
> the position to the database.) If not, do you think it would be worth
> implementing this?
>
> Best regards, Aaron
> --
> *From:* Øystein Schønning-Johansen 
> *Sent:* October 19, 2020 9:26 AM
> *To:* Aaron Tikuisis 
> *Cc:* Joseph Heled ; Philippe Michel <
> philippe.mich...@free.fr>; bug-gnubg@gnu.org 
> *Subject:* Re: The status of gnubg?
>
> *Attention : courriel externe | external email*
> On Mon, Oct 19, 2020 at 3:10 PM Aaron Tikuisis 
> wrote:
>
> That is interesting, I did not realize that gnubg misplays race positions
> much. What are some examples?
>
>
>  Here is a position I posted a few weeks ago.
>
> GNU Backgammon  Position ID: 960BAMCw+0MAAA
>  Match ID   : cAkA
>  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
>  |  |   |O  O  O  O  O | O   0 points

Re: The status of gnubg?

[Øystein Schønning-Johansen]

On Mon, Oct 19, 2020 at 3:10 PM Aaron Tikuisis 
wrote:

> That is interesting, I did not realize that gnubg misplays race positions
> much. What are some examples?
>

 Here is a position I posted a few weeks ago.

GNU Backgammon  Position ID: 960BAMCw+0MAAA
 Match ID   : cAkA
 +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
 |  |   |O  O  O  O  O | O   0 points
 |  |   |O O  O  O | O
 |  |   | O  O |
 |  |   | O|
 |  |   | O|
v|  |BAR|  | (Cube: 1)
 |7 |   |  |
 |X |   |  |
 |X |   | X|
 |X |   | X  X   X | On roll
 |X   X |   | X  X   X | 0 points
 +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein

Money game and X to play. Try several rolls, like 52, 31 and 53 and... at
0-ply. What's the best move? 52: 6/1 6/4?
Of course, the evaluator reports 0.0 win, but since the gammons are
incorrectly evaluated by the neural network, it makes ridiculous moves.
It looks like this is a common pattern in positions which are "skewed".

-Øystein

Re: The status of gnubg?

[Øystein Schønning-Johansen]

On Mon, Oct 19, 2020 at 12:02 AM Joseph Heled  wrote:

> But someone starting work in that area can take the old frame for another
> spin. They would learn a lot, even if they don't improve anything.
>

Yes! I can confirm that.


> They can start with the "relatively" low hanging fruit of the race net.
> (even though it is not as low hanging as some may think.)
> Oystein can add more on that.
>

Oh, yes! For many years I had the impression that the race neural network
was close to perfect, and didn't care much to look into it. I now realize
that there are many positions that are actually misplayed. So, I'm
currently trying to find better methods for evaluating race position. It is
possible to calculate some positions exactly to the bitter end with simple
dynamic programming, however that is way too slow, it is also possible to
estimate winning probabilities using the Central Limit Theorem for Renewal
Processes. That is superfast, however worse than the current neural
network, I guess. The problem is to find the sweet spot between what is
feasible from a time (and memory) consuming point of view and the precision
of the evaluation.

I'm in the phase of setting up a more detailed simulation on these
different methods, such that I do have some numbers for comparison.

-Øystein

Re: The status of gnubg?

[Øystein Schønning-Johansen]

I must admit there isn't much happening at the moment. But if you do find
bugs or have ideas, feel free to post then here at the mailing list or use
the bugtracker at savannah. Of course there's no guarantee that the ideas
will be implemented or the bugs will be fixed.  If you have a pull request
^h^h^h^h patch , it is more likely that it will be committed back into the
tree.

We really need more enthusiasm!

-Øystein

On Wed, Oct 14, 2020 at 7:13 PM Aaron Tikuisis 
wrote:

> Hi,
>
> I'm very interested in backgammon, and have a background in math and
> computer science. I'm keen to understand gnubg better. Is anyone still
> working on the project?
>
> I'd even be happy to contribute, even if only in a small way. For example,
> I'm reading through the code and perhaps as I understand things I could add
> comments (e.g., I'd like to figure out what the inputs I_BACKBONE and
> I_TIMING are). I also have noticed some bugs and some ideas for
> improvements. I haven't written these down but I can if there's a chance
> they'll be fixed. (Potentially I could contribute in bigger ways, but I'd
> like to get to understand it better and know whether people are working on
> gnubg first.)
>
> Best regards,
> Aaron
>

Re: Help on building GNU BG on Windows 10

[Øystein Schønning-Johansen]

I guess you can follow these steps:
https://docs.microsoft.com/en-us/windows/wsl/install-win10

At step 6 -> Ubuntu 20.04 is probably a safe choice of distribution.
(I would probably skip the optional step "Install Windows Terminal" at step
7, however your preference may be different)

When you have a running Ubuntu in WSL2, I can assist you further.

-Øystein


On Tue, Oct 13, 2020 at 2:54 PM Turker Eflanli 
wrote:

> Hi Øystein,
>
> Yes! Exactly what I want. Can you give more details on WSL 2? Where can I
> find more instructions?
>
> Thank you!
>
> Turker
>
> On Tue, Oct 13, 2020 at 8:51 AM Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Hi Turker!
>>
>> If you just want the CLI of gnubg on Windows 10, maybe you can use WSL 2?
>> It works pretty well, and I cannot imagine that GNU Backgammon will not be
>> able to compile under WSL 2.
>>
>> -Øystein
>>
>> On Tue, Oct 13, 2020 at 2:43 PM Turker Eflanli 
>> wrote:
>>
>>> Ok, thanks for the reply.
>>>
>>> On Tue, Oct 13, 2020 at 4:31 AM Guido Flohr 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 13 Oct 2020, at 5:33, Turker Eflanli 
>>>> wrote:
>>>>
>>>> By the way, I am not interested in the graphics or board: just want to
>>>> see how the engine works. Is there a way to disable the graphics
>>>> compilation so that I can generate the *gnubg-cli* version only?
>>>>
>>>>
>>>> Unfortunately, there is no headless version of GnuBG.
>>>>
>>>> Cheers,
>>>> Guido
>>>>
>>>

Re: Help on building GNU BG on Windows 10

[Øystein Schønning-Johansen]

Hi Turker!

If you just want the CLI of gnubg on Windows 10, maybe you can use WSL 2?
It works pretty well, and I cannot imagine that GNU Backgammon will not be
able to compile under WSL 2.

-Øystein

On Tue, Oct 13, 2020 at 2:43 PM Turker Eflanli 
wrote:

> Ok, thanks for the reply.
>
> On Tue, Oct 13, 2020 at 4:31 AM Guido Flohr 
> wrote:
>
>> Hi,
>>
>> On 13 Oct 2020, at 5:33, Turker Eflanli  wrote:
>>
>> By the way, I am not interested in the graphics or board: just want to
>> see how the engine works. Is there a way to disable the graphics
>> compilation so that I can generate the *gnubg-cli* version only?
>>
>>
>> Unfortunately, there is no headless version of GnuBG.
>>
>> Cheers,
>> Guido
>>
>

Re: Error while generating bearoff database

[Øystein Schønning-Johansen]

Yes, it is bad. I'm in the process of quantifying some numbers on this.
I'll see if I can post some of my findings.

I don't think it is the fixed array size that matters. 32 should be big
enough, I believe.

However, to me it looks like the 2-sided effect is dominating. That is, the
best move is depending on the board setup of the opponent player and not
only the player's board setup. Of course this is taken into account
somewhat even with one-sided bearoff databases with full probability
distributions, however it still gets wrong, and to me it looks like this
small incorrectness is not only limited to positions with just a few rolls
left, but is rather propagated back to longer races.

(I'm still in the phase of investigating this, and I'll see if I can make a
better statement and back it up with some examples.)

-Øystein

On Tue, Oct 6, 2020 at 11:02 PM Philippe Michel 
wrote:

> On Tue, Oct 06, 2020 at 09:59:20AM +0200, Øystein Schønning-Johansen wrote:
>
> > A huge onesided non-contact database like this will misplay a lot of
> > positions.
>
> Is it really that bad ?
>
> I thought that, as long as one does not use shortcuts like the
> --no-gammons and --normal-dist options, one-sided databases were very
> accurate.
>
> Is it because the probabilites arrays size, at 32, is too small for long
> races ?
>

Re: Error while generating bearoff database

[Øystein Schønning-Johansen]

Yes! Good point actually. I did indeed assume that someone would build it
for use with GNU Backgammon and that assumption might not be right.

I can actually admit that I have been building long one-sided databases
myself (not using makebearoff tool) to get good heuristic moves and
probability estimates, so your argument is indeed valid. Thanks for
pointing that out.

-Øystein

On Tue, Oct 6, 2020 at 2:32 PM Timothy Y. Chow 
wrote:

> Øystein Schønning-Johansen wrote:
>
> >> And again: You should not build such a one-sided database in the first
> >> place. You will not get a better player if you use such a large bearoff
> >> database.
>
> I'm not saying that anyone should put in the time to fix this bug.  But
> the last time I tried to generate a database wasn't for use with GNUBG.
> It was for independent mathematical investigations.  So the fact that such
> a database won't create a better player is not, IMO, a good argument for
> saying that such a database should not be built.
>
> Tim

Re: Error while generating bearoff database

[Øystein Schønning-Johansen]

Hi,

Thanks for your bug report. Let me have a guess.

In file makebearoff.c lines 216ff:

216/* read distributions */
217
218iOffset = 2 * iOffset;
219
220nBytes = 2 * (nz + nzg);
221
222if (fseek(pfTmp, iOffset, SEEK_SET) < 0) {
223perror("fseek'ing temp file");
224exit(-1);
225}

Let me guess that iOffset in line 218 overflows. I've not checked this
theory with any math, but that is still my theory.

Could be (I'm not sure as I have not tried) it helps if we change the type
of  iOffset to unsigned long instead of long. Or maybe even type size_t,
which is probably the type the fseek() expects.

No, answering myself...The above suggested fix is not going to work.
Checking the fseek() manual it actually expects long type offset as the
argument. This is probably by design, such that you can easily move
backwards in a file. Can you make a 64bit build? Maybe that will work.

However... (and this is a HUGE "however")

Building a full onesided bearoff database to the 14.point (or even lower)
is actually not something you should do. It does not play better backgammon
if you generate this file. A huge onesided non-contact database like this
will misplay a lot of positions. It will hence not be usable for playing or
rollouts. The neural network at 2-ply plays better! Use 2-ply neural
network!

Best regards,
-Øystein
(BTW: I will not fix the bug)


On Tue, Oct 6, 2020 at 6:56 AM Joaquín Koifman  wrote:

> Hi all!
>
> When trying to generate a one-sided bearoff database greater than 13
> points I get the following error. Do you know if there is any workaround?
>
> Thanks in advance
>
> [image: image.png]
>

Re: Bug in rollout ?

[Øystein Schønning-Johansen]

Thanks, I think you are spot on, Philippe. (And so i Theo)

Easy for me does not imply that it is easy for the neural network.

-Øystein

On Wed, Sep 23, 2020 at 10:27 PM Philippe Michel 
wrote:

> On Wed, Sep 23, 2020 at 06:22:28PM +0200, Øystein Schønning-Johansen wrote:
>
> > I strongly believe that this is a pretty simple position to play
>
> For a neural net this is not so clear. With 7 men stacked on the 7 point
> this is a position that will never happen in real play and is unlikely
> in training. Neither will its immediate continuations. A plausible
> adversarial example indeed.
>
> If you look at the temperature map you will see how badly gnubg plays
> many rolls on the first turn.
>
> Using a one-sided bearoff database going to the 7 point instead of the 6
> helps (and going to the 11 point should totally eliminate the issue),
> but another issue appears : the transition from race net evaluation to
> bearoff database evaluation. If the former overvalues the position and
> its close continuations, X will tend not to move the checker from the 11
> point further than the 8 point to stay with the more generous evaluator.
>
> > I think that X (on roll) will lose about 15% gammon. It should not be
> > hard to roll this out.
>
> This is much less than that. Theodore in another follow-up got a quick
> estimate of 2%. Since O needs doublets but X needs not getting them, one
> can replace his 1/6 factor by 5/36 and get a slightly more accurate
> number of about 1%, showing that your 2 ply rollout is much better than
> 0 ply but still far from perfect.
>
> This is arguably a bug, but not a simple coding error : one (of
> undoubtly many) weak spot in evaluations.
>

Re: Bug in rollout ?

[Øystein Schønning-Johansen]

Yes, Theo, I think you might be right. I actually turned on game logging
and re-ran the rollout. I noticed that GNU Backgammon really plays the
bearin really really bad. Look at the attached games:

I just picked some games at random, and these two games really show awful
playing. Can anyone explain what is going on?

-Øystein

On Wed, Sep 23, 2020 at 6:51 PM Theodore Hwa 
wrote:

> 2% seems more like the correct number. I think the first rollout is the
> wrong one.
>
> A naive analysis: X looks virtually certain to get a piece off within 5
> rolls, which means that O has to win in 4 rolls for a gammon.  Since O has
> 13 pieces left, this means O has to roll doubles in 3 of the next 4 rolls,
> which is about 4*(1/6)^3 ~ 1.85%.
>
> Ted
>
> On Wed, 23 Sep 2020, Øystein Schønning-Johansen wrote:
>
> > Hi all!
> > I'm trying to rollout a position as cubeless moneygame. I think I see a
> bug in GNU Backgammon. So
> > here is my position:
> >
> >  GNU Backgammon  Position ID: 960BAMCw+0MAAA
> >  Match ID   : cAkA
> >  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
> >  |  |   |O  O  O  O  O | O   0 points
> >  |  |   |O O  O  O | O
> >  |  |   | O  O |
> >  |  |   | O|
> >  |  |   | O|
> > v|  |BAR|  | (Cube: 1)
> >  |7 |   |  |
> >  |X |   |  |
> >  |X |   | X|
> >  |X |   | X  X   X | On roll
> >  |X   X |   | X  X   X | 0 points
> >  +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein
> >
> > I strongly believe that this is a pretty simple position to play and I
> think that X (on roll) will
> > lose about 15% gammon. It should not be hard to roll this out.
> >
> > I generate this command file:
> >
> > [oystein@jupiter gnubg_cubeless_rollout_bug]$ cat rollout.cmd
> > set rng mersenne
> > new match 0
> > set turn 1
> > set board 960BAMCw+0MAAA
> > set rollout trials 1296
> > set rollout cubeful off
> > set rollout initial false
> > set rollout quasirandom on
> > set rollout truncation enable off
> > set rollout bearofftruncation exact off
> > set rollout bearofftruncation onesided off
> > set rollout cubedecision plies 0
> > set rollout cubedecision cubeful off
> > set rollout cubedecision prune off
> > set rollout cubedecision noise 0
> > set rollout chequerplay plies 0
> > set rollout chequerplay cubeful off
> > set rollout chequerplay prune off
> > set rollout chequerplay noise 0
> > show rollout
> > show board
> >
> > rollout
> >
> > I can then start this rollout with the command file as input.
> >
> > [oystein@jupiter gnubg_cubeless_rollout_bug]$ gnubg -t < rollout.cmd
> >
> > And the result becomes:
> >
> > Rollout done. Printing final results.
> >
> > Current Position:
> >   0.96 0.00 0.00 - 0.04 0.147699 0.00 CL -1.147507
> >  [0.08 0.00 0.00 - 0.08 0.007830 0.00 CL  0.007830]
> 1r
> > Full cubeless rollout with variance reduction
> > 1296 games, Mersenne Twister dice gen. with seed 642205659 and
> quasi-random dice
> > Play: 0-ply cubeful
> > Cube: 0-ply cubeful
> > Time elapsed 2s Estimated time left 0s
> > Estimated SE for "Current Position" after 1296 trials  0.007830
> >
> > As seen, the rollout says 14.77% gammons. I can believe that! But now
> comes the funny thing. Try the
> > same thing but with checkerplay 2-ply. That mean changing one line in
> the command file to read:
> >
> > set rollout chequerplay plies 2
> >
> > And then run again. The new result is then:
> >
> > Rollout done. Printing final results.
> >
> > Current Position:
> >   0.98 0.00 0.00 - 0.02 0.027877 0.00 CL -1.027681
> >  [0.05 0.00 0.00 - 0.05 0.011880 0.00 CL  0.011726]
> 1r
> > Full cubeless rollout with variance reduction
> > 1296 games, Mersenne Twister dice gen. with seed 642390699 and
> quasi-random dice
> > Play:  2-ply cubeless
> > keep the first 0 0-ply moves and up to 5 more moves within equity 0.08
> > Skip pruning for 1-ply moves.
> > Cube: 0-ply cubeful
> > Time elapsed 1m21s Estimated time left 0s
> > Estimated SE for "Current Position" after 1296 trials  0.011726
> >
> > As seen here, the gammon losses are now only 2.79%. I do not believe
> this result at all! Also look at
> > the standard deviation of this value. Could it be that the number is
> wrong due to a missing
> > initialisation or something?
> >
> > Please help me investigate.
> >
> > -Øystein
> >
> >


logfile-0001140-a.sgf
Description: application/go-sgf


logfile-137-a.sgf
Description: application/go-sgf

Bug in rollout ?

[Øystein Schønning-Johansen]

Hi all!

I'm trying to rollout a position as cubeless moneygame. I think I see a bug
in GNU Backgammon. So here is my position:

 GNU Backgammon  Position ID: 960BAMCw+0MAAA
 Match ID   : cAkA
 +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
 |  |   |O  O  O  O  O | O   0 points
 |  |   |O O  O  O | O
 |  |   | O  O |
 |  |   | O|
 |  |   | O|
v|  |BAR|  | (Cube: 1)
 |7 |   |  |
 |X |   |  |
 |X |   | X|
 |X |   | X  X   X | On roll
 |X   X |   | X  X   X | 0 points
 +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein

I strongly believe that this is a pretty simple position to play and I
think that X (on roll) will lose about 15% gammon. It should not be hard to
roll this out.

I generate this command file:

[oystein@jupiter gnubg_cubeless_rollout_bug]$ *cat rollout.cmd*
set rng mersenne
new match 0
set turn 1
set board 960BAMCw+0MAAA
set rollout trials 1296
set rollout cubeful off
set rollout initial false
set rollout quasirandom on
set rollout truncation enable off
set rollout bearofftruncation exact off
set rollout bearofftruncation onesided off
set rollout cubedecision plies 0
set rollout cubedecision cubeful off
set rollout cubedecision prune off
set rollout cubedecision noise 0
set rollout chequerplay plies 0
set rollout chequerplay cubeful off
set rollout chequerplay prune off
set rollout chequerplay noise 0
show rollout
show board

rollout

I can then start this rollout with the command file as input.

[oystein@jupiter gnubg_cubeless_rollout_bug]$ *gnubg -t < rollout.cmd*

And the result becomes:

Rollout done. Printing final results.

Current Position:
  0.96 0.00 0.00 - 0.04 0.147699 0.00 CL -1.147507
 [0.08 0.00 0.00 - 0.08 0.007830 0.00 CL  0.007830] 1r
Full cubeless rollout with variance reduction
1296 games, Mersenne Twister dice gen. with seed 642205659 and quasi-random
dice
Play: 0-ply cubeful
Cube: 0-ply cubeful
Time elapsed 2s Estimated time left 0s
Estimated SE for "Current Position" after 1296 trials  0.007830

As seen, the rollout says 14.77% gammons. I can believe that! But now comes
the funny thing. Try the same thing but with checkerplay 2-ply. That mean
changing one line in the command file to read:

set rollout chequerplay plies 2

And then run again. The new result is then:

Rollout done. Printing final results.

Current Position:
  0.98 0.00 0.00 - 0.02 0.027877 0.00 CL -1.027681
 [0.05 0.00 0.00 - 0.05 0.011880 0.00 CL  0.011726] 1r
Full cubeless rollout with variance reduction
1296 games, Mersenne Twister dice gen. with seed 642390699 and quasi-random
dice
Play:  2-ply cubeless
keep the first 0 0-ply moves and up to 5 more moves within equity 0.08
Skip pruning for 1-ply moves.
Cube: 0-ply cubeful
Time elapsed 1m21s Estimated time left 0s
Estimated SE for "Current Position" after 1296 trials  0.011726

As seen here, the gammon losses are now only 2.79%. I do not believe this
result at all! Also look at the standard deviation of this value. Could it
be that the number is wrong due to a missing initialisation or something?

Please help me investigate.

-Øystein

Training data set url?

[Øystein Schønning-Johansen]

Hi again all!

I'm looking for the training data again, and I know that it used to be here:
http://files.gnubg.com/media/nn-training/pmichel/training_data/

It looks like it's not available anymore. Does anyone know where I can find
a copy of the data?

-Øystein

Re: Bug: Getting dice from random.org for the second time

[Øystein Schønning-Johansen]

Hmmm... Peter? Can you check if this bug appears both when doing
multithreading as well as when running gnubg with a single thread?

-Øystein

On Wed, Aug 12, 2020 at 5:10 PM Christian Anthon 
wrote:

> Definitely a bug of some kind. The dice generator either runs out
> prematurely or decides that 0 is a valid rolid. I added a bit of debug code
> and it ended around 450 rolls each time and decided to return 0...
>
> Counters 458 500
> Random 0
>
> C
>
> On Wed, Aug 12, 2020 at 4:57 PM Guido Flohr 
> wrote:
>
>> Hi Peter,
>>
>> On 12 Aug 2020, at 16:29, Peter Lederer  wrote:
>>
>> Hello,
>>
>> my Linux Mint is a German version. Thus GNUBG is German as well
>> ("Voreingestellt").
>>
>> I cannot change the language setting to another language. It says
>> "Locale 'en_US' not supported by C library."
>>
>>
>> See here how you can add locales in Linux Mint:
>> https://winaero.com/blog/add-locale-linux-mint/
>>
>> I think you have to add “en_US.UTF-8”, not just “en_US”.
>>
>> Regards,
>> Guido
>> —
>> Cantanea EOOD - We are hiring!
>> http://www.cantanea.com/careers/ • facebook.com/cantaneacom •
>> twitter.com/cantaneacom
>>
>>

Re: Bug: Getting dice from random.org for the second time

[Øystein Schønning-Johansen]

I've not tested, but could this be a problem at random.org? Maybe we should
start using their new JSON-RPC based API?
-Øystein

On Wed, Aug 12, 2020 at 10:40 AM Peter Lederer  wrote:

> Hello Philippe,
>
> it happens consistently. Every time.
>
> My internet connection is flawless.
>
> If I restart GNUBG it fetches the next (first for the next match) 500
> numbers without any problem.
>
> I have no idea what to change.
>
> Greets
>
> Peter
>
>
>
>
> 2020-08-11 22:21 GMT+02:00, Philippe Michel :
> > On Sat, Aug 08, 2020 at 02:40:24PM +0200, Peter Lederer wrote:
> >
> >> I use GNU Backgammon 1.06.001 Feb 28 2018 on Linux Mint 19.3 as it
> >> comes from the distribution repository.
> >>
> >> As dice generator I use random.org. The fetching of the first 500 dice
> >> works fine. When required to receive the second portion of dice it
> >> says "Your dice generator isn't working. Failing back on
> >> RNG_MERSENNE". At the same time the dice settings jump back to
> >> "Mersenne Twister" and stay there.
> >
> > The most likely cause is that gnubg couldn't contact random.org when it
> > tried to pull the second batch of dice.
> >
> > Does it happen consistently ? If not, does your machine have internet
> > access when it does ?
> >
> > FWIW, I couldn't reproduce the problem with the current gnubg version
> > (and not on linux Mint ; the random.org related code hasn't changed
> > since 1.06.001, but the system library used to establish connections is
> > almost certainly at a different version).
> >
> >
> >
>
>

Re: OpenSuse 15.1 no display for gnu-bg

[Øystein Schønning-Johansen]

I've not seen that before, but from experience I've seen that a reboot is
what makes things work again. That is especially true when it comes to
display drivers on Linux systems. Have you tried that?

-Øystein

On Tue, Jan 21, 2020, 17:11 Mark Neidorff  wrote:

> Hi,
>
>
>
> I (at last, but never mind that) updated my OpenSuse 15.0 to 15.1. The
> update looked clean. The only problem I have run into is that gnu-bg does
> not produce any output. (It worked properly when I was running 15.0) I'm
> running under KDE and using the latest video drivers from nvidia for my
> graphics card. My package manager shows that the version of gnubg (and
> related packages) is: 1.04.001-lp151.2.24
>
>
>
> Has this been seen before? Any suggestions on how to debug the problem?
> Any help would be appreciated.
>
>
>
> Thank you,
>
> Mark
>
> --
>
> You are only as old as you look.
>
>
>

Re: makebearoff -t 6x15 doesn't work for me

[Øystein Schønning-Johansen]

Thanks for your report.

The makebearoff code was written last millennium, and the problem you're
seeing is probably caused by some overflow problem in the code. These kind
of stuff was hard to check back in the 90s.

I guess it is fixable but ...

* Assuming you are able to solve the code issue (which is probably an
overflow), then you first need at computer with enough memory. 32GB RAM
computers are not uncommon these days, so that might not be a problem.
* Next, in the 90s and early 2000s when this code was written, developers
thought about size (and they still do). To mitigate the size of the
datafile the probabilities are stored in 16bit precision. With this
precision the the values actually deviate from the true values in the
higher end of the bearoff table.
* The overflow bug in makebearoff, probably also have the same
corresponding bug in the GNU Backgammon code. I far from sure a 15x6
bearoff database will work OOTB in GNU Backgammon.
* The most severe problem tough, which I've just been aware of, is that a
true 2-sided bearoff database, will give evaluation differences from onside
bearoff so high, that race bearin positions will be played incorrectly. The
current race neural network is trained to match the probabilities given by
a one-sided bearoff database. Using a setup with the current race net +
full two sided beaoff database, will do incorrect bearin moves (at least at
lower plies).

So... Having a full twosided beaoff database (15 checkers on 6 points) will
probably not improve the playing abilities of GNU Backgammon except in pure
bearoff positions.


Well that said. It is interesting to sometimes know the real winning
probabilities in a bearoff position. After all we are geeks I have
written a code that do generate a full 15 checker bearoff database with
32bit precision, but it's not storing the cubeful numbers. That makes it
54264 x  54264 x 4 bytes ~= 11GB (big). My database is incompatible with
GNU Backgammon, but I'm able to find an "exact" winning probability without
doing a rollout.

-Øystein
...


On Thu, Jan 2, 2020 at 6:36 AM Lukas Fürnkranz 
wrote:

> Hi,
>
> I tried to create a large two-sided bearoff database with:
>
> $ makebearoff -t 6x15 -f gnubg_ts.bd
>
> The program told me that the "total number of positions" is
> -1350385600, which seemed dubious to me, but I didn't abort it.
>
> After a couple of hours the program finished and I ended up with a file
> that's basically empty:
>
> $ cat gnubg_ts_test.bd
> gnubg-TS-03-03-1xxx
>
> From what I read the file is supposed to be ~22GB big.
>
> What might have gone wrong?  I had about 60GB of free space, which I
> guess should be enough.
>
> Best wishes
>
> Lukas
>

Temporal difference learning. Lambda parameter.

[Øystein Schønning-Johansen]

Hi!

As we discussed a bit last week I've started to think again. How can we
improve a backgammon engine?

I think that most of us agree that what can be improved is play in
positions where some kind of long term plan is needed. Like
"snake"-positions and backgames.

The reinforcement learning that has been used up til now is plain temporal
difference learning like described in Sutton and Barto (and done by several
science projects) with TD(lambda=0).

Do you think that the engine can be better at planning ahead, if lambda is
increased? Has anyone done a lot of experiments with lambda other than 0?
(I don't think it's code in the repo to do anything else than lambda=0, so
maybe someone with some other research code base on this can answer?) Or
someone with general knowledge of RL can answer?

-Øystein

Re: Backgammon "solved"?

[Øystein Schønning-Johansen]

No, the question is fair enough. You just have to apply the FIBS rating
formula when you have estimated a winning probability of the strongest
player.

-Ø

On Thu, Dec 5, 2019 at 11:02 PM Theodore Hwa 
wrote:

> That's not really a fair question. The point is, both GNUBG/XG and a
> "perfect bot" are so far above my level, they might as well be the same
> thing. You are essentially asking to subtract 2 big numbers to get a small
> number, which only gives a meaningful answer if the big numbers are able
> to be computed to a very high accuracy.
>
> Ted
>
> On Fri, 6 Dec 2019, Joseph Heled wrote:
>
> > (Just out of curiosity)
> > A question to you people who think bots play close to a perfect game:
> >
> > What do you believe is the difference between GNUB/XG etc and a "perfect
> bot". Say in a 25 point match. Answers in Elo difference please :)
> >
> > Thanks, Joseph
> >
> >
> >

Re: current development

[Øystein Schønning-Johansen]

I have tried some experiments, and it looks like the training dataset (for
contact positions) with the current input features, do indeed like some of
the more modern methods. Briefly summarized:

Things that improves supervised learning on the dataset:
* Deeper nets, 5-6 hidden layers combined with ReLU activation functions.
* Adam (and AdamW) optimizer.
* A tiny bit of weight decay.
* Mini-batch training.

Things that does not work:
* Dropout.
* PCA of inputs.
* RMSProp optimizer (About the same performance as SGD).

I've tried training with Keras and on GPU's, and the training is really
fast. However a plain CPU implementation of modern neural network training
algorithms is actually not much slower for me. Also porting GPU code over
into the GNU Backgammon application might not be faster as a lot of cycles
will be used shuffling data back and forth between main memory and GPU
memory.

So the process I ended up using was:
1. Test out what works with Keras+GPU
2. implement that working method in C code for CPU.
3. Train NN with that code.

I've only worked with the contact neural network, as I see some strange
issues with race dataset, and I think it require a re-rollout.

-Øystein

On Thu, Dec 5, 2019 at 12:38 PM Nikos Papachristou 
wrote:

> Hi everybody!
>
> You can view my research publications on backgammon variants at my
> website: https://nikpapa.com , or alternatively you can download my PhD
> thesis from:
> https://www.didaktorika.gr/eadd/handle/10442/43622?locale=en
>
> My personal view on improving GNUBG: Why not try to "upgrade" your
> existing supervised learning approach? There have been lots of advances in
> optimization/regularization algorithms for neural networks in the past
> years and it might be less demanding that trying a new RL self-play
> approach from scratch.
>
> Regarding expected results, I also believe that backgammon bots are very
> close to perfection and whatever improvements (from any approach) will be
> marginal.
>
>
>
> On Thu, Dec 5, 2019 at 12:14 AM Joseph Heled  wrote:
>
>> A link to something? article? software? did they use alpha-like
>> strategies?
>>
>> -Joseph
>>
>> On Thu, 5 Dec 2019 at 11:04, Philippe Michel 
>> wrote:
>>
>>> On Wed, Dec 04, 2019 at 02:07:18PM -0500, Timothy Y. Chow wrote:
>>>
>>> > Also, it's my impression that many people *don't* think this is even a
>>> > worthwhile idea to pursue.  Backgammon is already "solved," is what
>>> they
>>> > will say.  It's true that "AlphaGammon" will surely not crush existing
>>> > bots in a series of (say) 11-point matches.  At most I would expect a
>>> > slight advantage.  But to me, that is the wrong way to look at the
>>> issue.
>>> > I would like to understand superbackgames for their own sake, even
>>> though
>>> > they arise rarely in practice.  Furthermore, if we know that bots
>>> don't
>>> > understand superbackgames, then the closer a position gets to being a
>>> > superbackgame, the less we can trust the bot verdict.
>>>
>>> I'm not sure how related it may be, but there is a group of Greek
>>> academics that have published some articles on their work on a bot,
>>> Palamedes, that plays backgammon but also variants that have different
>>> rules and starting positions and lead to positions that would be very
>>> uncommon in backgammon.
>>>
>>>
>>>
>>>

Re: current development

[Øystein Schønning-Johansen]

But let's chat about the idea instead. What will it actually mean to 'apply
"AlphaZero methods" to backgammon.' ?

AlphaZero (and AlphaGo and Lc0 and SugaR NN) is just more or less the same
thing as reinforcement learning in backgammon. So, from my understanding,
it is rather AlphaZero, who has applied the backgammon methods. They are
both the chess and go variants trains with reinforcement learning pretty
much like the original GNU Backgammon, Jellyfish and Snowie. In Go they had
to make a move selection subroutine based on human play and then add MCTS
to train. Also the neural networks are deeper and more complex. The nn
inputs features are also so more complex and can to some extend resemble
convolutions known from convolutional neural network (And that the inputs
are not properly described in the high level articles.)

Apart from that, it is actually same thing: Reinforcement learning.

But how can we improve: We believe (at least I do) that the current state
of backgammon bots are so strong that it plays close to perfect in standard
positions. It is in uncommon and long term plan positions (like deep
backgames and snake rolling prime positions) bots still can improve. Let me
throw some ideas up in the air for discussion:

Can we make a RL algorithm that is so fast that it can learn on the fly?
Say we during play find a position where some indicator (that may be
another challenge) indicates that this is a position that requires long
term planning. If we then have the ability to RL train a neural net for
that specific position, that could be an huge improvement in my opinion.
(Lot's of details missing.)

And then, could the evaluations be improved if we specialize neural
networks in to specific position types, and then make a kind of nn
selection system based on k-means of the input features. I tried that many
years ago with only four classes. Those experiments showed that it's not
hopeless approach, and with faster computers it can easily create much more
than just four classes (fours was only the first number that popped into my
head those days)

Then next idea: What about huge scale distributed rollouts? Maybe we could
have a system like BOINQ to do rollouts on the fly? I'm not sure how this
should be used in a practical sense, and I'm not sure how hard it would be
to implement (with or without BOINQ framework) but I'm just kind of
brainstorming here.

-Øystein


On Wed, Dec 4, 2019 at 6:47 PM Joseph Heled  wrote:

> I was intentionally rude because I thought his original post was
> inappropriate.
>
> -Joseph
>
> On Thu, 5 Dec 2019 at 06:42, Ralph Corderoy  wrote:
> >
> > Hi Joseph,
> >
> > > I thought so.
> > >
> > > I had the same idea the day I heard they cracked go, but just saying
> > > something is a good idea is not helpful at all in my book.
> >
> > I think you're wrong.  And also a bit rude to boot.
> >
> > It's fine for Tim to suggest or ponder an idea to the list.  It may
> > encourage another subscriber, or draw out news of what a lurker has been
> > working on that's related.
> >
> > --
> > Cheers, Ralph.
> >
>
>

Re: current development

[Øystein Schønning-Johansen]

Hmmm SSE3/4 doesn't have much instructions that improves the I actually
operations needed in the matrix multiplications.
However, I think the clever boys (Michael and Philippe) have implemented
AVX support which is pretty normal on modern machines. Try to recompile
from source and see if you can get AVX support on your binary.

That said. Does modern processors come with AVX512 these days? Do we have
support for that? In it is common to have AVX512 and we don't have support
for it, maybe that is something that can go on the TODO list?

-Øystein

On Tue, Dec 3, 2019 at 10:07 PM Joseph Heled  wrote:

> Like I said, installed from the standard Ubuntu rep.
>
> Yes, info says multithread support. It says SSE/SSE2 support. What
> about SSE3/4 etc, or they confer no real improvement over SSE2?
>
> -Joseph
>
> On Wed, 4 Dec 2019 at 09:58, Øystein Schønning-Johansen
>  wrote:
> >
> > Did you compile from source or install a binary from a packet manager?
> > Does it say multi-thread support in: Help->About->Build Info ?
> >
> > -Øystein
> >
> > On Tue, Dec 3, 2019 at 9:46 PM Joseph Heled  wrote:
> >>
> >> All I know is that I installed gnubg from the repository (GNU
> >> Backgammon 1.06.002) and the rollouts speed seemed terrible.
> >>
> >> Do I need to do something in the GUI to enable multi-threading? (and I
> >> hope that by multi-threading we are talking about multi-core, not just
> >> threading, which does not help)
> >>
> >> -Joseph
> >>
> >> On Wed, 4 Dec 2019 at 09:38, Øystein Schønning-Johansen
> >>  wrote:
> >> >
> >> > On Tue, Dec 3, 2019 at 7:37 PM Joseph Heled  wrote:
> >> >>
> >> >> I am out of the loop too, but speeding up rollouts (i.e. using modern
> >> >> multicores) seems like a worthy improvement.
> >> >
> >> >
> >> > Isn't that done already?
> >> >
> >> > I think the code is multithreaded using gthreads from glib. I think
> it was done by Michael (and Philippe) some years ago. I haven't browsed the
> code that much in detail lately, so I'm not sure what it's threading on. Do
> you see an obvious improvement over the current threaded code?
> >> >
> >> > -Øystein
> >> >
> >> >
>

Re: current development

[Øystein Schønning-Johansen]

Did you compile from source or install a binary from a packet manager?
Does it say multi-thread support in: Help->About->Build Info ?

-Øystein

On Tue, Dec 3, 2019 at 9:46 PM Joseph Heled  wrote:

> All I know is that I installed gnubg from the repository (GNU
> Backgammon 1.06.002) and the rollouts speed seemed terrible.
>
> Do I need to do something in the GUI to enable multi-threading? (and I
> hope that by multi-threading we are talking about multi-core, not just
> threading, which does not help)
>
> -Joseph
>
> On Wed, 4 Dec 2019 at 09:38, Øystein Schønning-Johansen
>  wrote:
> >
> > On Tue, Dec 3, 2019 at 7:37 PM Joseph Heled  wrote:
> >>
> >> I am out of the loop too, but speeding up rollouts (i.e. using modern
> >> multicores) seems like a worthy improvement.
> >
> >
> > Isn't that done already?
> >
> > I think the code is multithreaded using gthreads from glib. I think it
> was done by Michael (and Philippe) some years ago. I haven't browsed the
> code that much in detail lately, so I'm not sure what it's threading on. Do
> you see an obvious improvement over the current threaded code?
> >
> > -Øystein
> >
> >
>

Re: current development

[Øystein Schønning-Johansen]

On Tue, Dec 3, 2019 at 7:37 PM Joseph Heled  wrote:

> I am out of the loop too, but speeding up rollouts (i.e. using modern
> multicores) seems like a worthy improvement.
>

Isn't that done already?

I think the code is multithreaded using gthreads from glib. I think it was
done by Michael (and Philippe) some years ago. I haven't browsed the code
that much in detail lately, so I'm not sure what it's threading on. Do you
see an obvious improvement over the current threaded code?

-Øystein

Re: current development

[Øystein Schønning-Johansen]

Hi Sarah!

Thanks for taking contact. Good to hear that you like GNU Backgammon.
Is it still under development? Hmmm... debatable. There has not been many
major improvements the last few years.

Take a look at the projects ChangeLog.
http://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/ChangeLog?revision=1.2654&view=markup

As you see there isn't much happening.

Of course you can contribute if you want. After all this project is Open
Source an anyone can do whatever changes they want.
Just post comments here on the mailing list, and it can shear up some of
the sleeping developers.

If you are a developer and want to contribute with code, we can of course
provide you write access to the cvs repository. (Yes, it is as old that
it's using cvs to do code revision).
Since everyone is more or less "sleeping", there is no real TODO list.
Maybe some code janitor work? Refactoring? Maybe c99-ify some of the code.
Maybe you can suggest a feature? Or report a bug?

Even though I'm not doing much on GNU Backgammon (I've not done much the
last 10 years) these days, I guess if we just chat about some details, it
might be the spark that starts up a new motivation among us. There are some
discussions still on this mailing list, last week there was a new Match
Equity Table presented (Thanks Ian). If we just chat more, maybe something
can start flowing again. I'm getting more time as my kids grow older. So,
who knows what happens.

Best regards,
-Øystein


On Tue, Dec 3, 2019 at 3:58 PM Sarah Payne  wrote:

> Hello there. Been a huge fan for many years of gnu backgammon, many thanks
> to everyone involved. Is the software still under development with new
> versions coming? Is it possible to contribute directly to this project?
>
>
>
> Thanks
>
>
>
> Sarah
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

Re: Training data on FTP down?

[Øystein Schønning-Johansen]

Thanks a lot! I believe these files are really valuable for the whole
backgammon community.
-Øystein

On Thu, Nov 28, 2019 at 8:47 AM Joseph Heled  wrote:

> Thank you. Looks good enough for me.
>
> -Joseph
>
> On Thu, 28 Nov 2019 at 20:39, Philippe Michel 
> wrote:
> >
> > On Wed, Nov 27, 2019 at 10:30:38AM +0100, Øystein Schønning-Johansen
> wrote:
> >
> > > I'm trying to download the training data from the site.
> > > http://files.gnubg.org/media/nn-training/
> > >
> > > Seems to me that the site does not respond. What's happening? Have the
> site
> > > been taken all down?
> >
> > I have uploaded it at ftp://alpha.gnu.org/gnu/gnubg/nn-training/
> >
> > As far as I can see, the files.gnubg.org server (that was managed by
> > Michael Petch) has disappeared.
> >
> > The Windows installer and the source archive for the last release are at
> > ftp://ftp.gnu.org/gnu/gnubg/ but whatever else was on this server is
> > lost : older installers for XP, binary packages for MacOS, etc...
> > The latter were pretty old and probably wouldn't work on recent MacOS
> > releases anyway. Some of it could probably be rebuilt but don't have the
> > computers needed for that.
> >
> >
>

Training data on FTP down?

[Øystein Schønning-Johansen]

Hi!

I'm trying to download the training data from the site.
http://files.gnubg.org/media/nn-training/

Seems to me that the site does not respond. What's happening? Have the site
been taken all down?

regards,
-Øystein

Re: [Bug-gnubg] Web version of GNU Backgammon

[Øystein Schønning-Johansen]

On Tue, Sep 24, 2019 at 10:09 PM Philippe Michel 
wrote:

> Was OpenGL really the only issue ?


Probably not! (This is a good point, so thanks for pointing this out.) I
didn't try much, but I assumed that the OpenGL 3D board was among the
problems. I took one of the plain builds I had, I did not try to
reconfigure and recompile.

However, I managed to get the broadway backend work with other desktop
applications. I didn't test those much either, but at least I got the GUI
displayed in the browser.

-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Web version of GNU Backgammon

[Øystein Schønning-Johansen]

Cool project. You have used emscripten to port the C code to webassembly?
Isn't there a port og GTK done with emscripten? Another way to port to web
would be to display the application itself with a different GTK backend.
I've tried that with the Broadway backend that can display GTK applications
directly in the browser. I've tried it with GNU Backgammon, however I think
it fails for GNU Backgammon due to the OpenGL stuff.

How did you make the user interface? Is it pure js or do you use any fancy
like React or Angular or Vue?

(I guess JavaScript is the next thin on my *must learn* list)

Thanks!
-Øystein

On Sun, Sep 22, 2019 at 9:47 AM Joseph Heled  wrote:

> A wonderful initiative. Perhaps one day we will have a reasonable Android
> version and all will be well.
>
> -Joseph
>
> On Sun, 22 Sep 2019 at 19:00, Theodore Hwa 
> wrote:
>
>> Hi gnubg users,
>>
>> I have ported GNU Backgammon to the web, replacing the GTK UI with a
>> Javascript UI. You can see it hosted here:
>> http://xenon.stanford.edu/~hwatheod/gnubg_web/gnubg_web.html
>>
>> As of now, you have to enter moves manually, like "8/5 6/5". You can
>> enter
>> arbitrary gnubg command line commands, so nearly all the features of the
>> original are available.
>>
>> The project repository is here:
>> https://github.com/hwatheod/gnubg-web
>>
>> Some technical details: This was done by compiling gnubg's C source code
>> into Javascript/Webassembly with Emscripten.  A browser supporting
>> Webassembly is required (the latest versions of most modern browsers do).
>>
>> Any comments, suggestions, contributions are appreciated!
>>
>> Ted Hwa
>>
>> ___
>> Bug-gnubg mailing list
>> Bug-gnubg@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] The race training and benchmark datasets

[Øystein Schønning-Johansen]

Yes! It is really a naïve parallel operation, that's why I tried to do this
with OpenMP. (I've used OpenMP with great success in other projects).
I guess your suggestion is actually more pragmatic and doesn't need any
more coding. I'll try that. Thanks.

-Øystein

On Mon, Jun 17, 2019 at 9:33 AM Joseph Heled  wrote:

> You have many independent runs, right? Why worry about multi-threading?
> Divide the set into (say) 16 threads (or whatever makes sense for your CPU)
> and run each set on another thread.
>
> -Joseph
>
> On Mon, 17 Jun 2019 at 19:28, Øystein Schønning-Johansen <
> oyste...@gmail.com> wrote:
>
>> Thanks for your input. I'm still thinking about this.
>> I really cannot decide which rollout code to use. :-)
>>
>> - sagnubg is really good but I have to tweak it a bit to make it work.
>> I'm also not sure it is multi-threading.
>> - GNU Backgammon, for sure it is good, but I probably have to build some
>> scripts to run this through. Indeed multi-threading seems to work.
>> - My own little rollout code. It really works good, but when I add
>> multi-threading with OpenMP, it really does not speed up at all. Getting
>> this working is actually what I'm spending time on now. I'm really
>> scratching my head.
>>
>> As you mention, the tool I posted some weeks ago can indeed be used for
>> some of the positions. That was actually the main reason I created the tool
>> in the first place. I think you are right. I have to start with the
>> positions with a lot of checkers born off. I can probably sort out in a
>> simple way. I should also only handle positions where gammon and backgammon
>> are not a subject. I can probably handle those separately.
>>
>> -Øystein
>>
>> On Sun, Jun 16, 2019 at 10:33 PM Philippe Michel <
>> philippe.mich...@free.fr> wrote:
>>
>>> On Mon, Jun 10, 2019 at 02:49:26PM +0200, Øystein Schønning-Johansen
>>> wrote:
>>>
>>> > I will try re-rolling out these positions. Do you have any experience
>>> of
>>> > how to do good rollouts of race positions? Good rollout settings for
>>> race
>>> > positions?
>>>
>>> When I re-rolled out the benchmarks I mostly used the settings that had
>>> been used previously. I think I changed the rolloutLimit parameter
>>> somehow (the number of alternatives included for checker plays). It is
>>> currently set to 10 for doublets and 5 for other rolls. I don't remember
>>> exactly what I did ; maybe it used to be 5 in all cases.
>>>
>>> I previously wrote it would be useful to have variance reduction in
>>> sagnubg, but this is not very important since it does 0-plys rollouts
>>> (VR works for them, but it is slow and simply doing more trials is about
>>> as good in terms of SD vs. time used). Doing 7776 trials instead of 1296
>>> doesn't seem unrealistic.
>>>
>>> From the other parameters :
>>>
>>> s version 1.93 weights 1.00 moves2plyLimit 20 rolloutLimit 5
>>> nRollOutGames 1296 cubeAway 7 include0Ply 1 evalPlies 2 shortCuts 1
>>> osrGames 1296 osrInRoll 1
>>>
>>> experimenting with osrInRoll set to 0 may be interesting. I dont know if
>>> OSR
>>> is used for speed or for accuracy...
>>>
>>> Another interesting thing to try, if it is practical, would be to use
>>> the
>>> software you mentionned a few weeks ago to calculate exact values.
>>>
>>> For instance, sort the positions by leading player's pipcount. Start
>>> from the smallest ones with your software ; that should tackle the
>>> hypergammon-like positions with few checkers and ideally the very
>>> unbalanced ones where the trailer can only try to save the gammon. The
>>> latter may well be misplayed in the current rollouts.
>>>
>> ___
>> Bug-gnubg mailing list
>> Bug-gnubg@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] The race training and benchmark datasets

[Øystein Schønning-Johansen]

Thanks for your input. I'm still thinking about this.
I really cannot decide which rollout code to use. :-)

- sagnubg is really good but I have to tweak it a bit to make it work. I'm
also not sure it is multi-threading.
- GNU Backgammon, for sure it is good, but I probably have to build some
scripts to run this through. Indeed multi-threading seems to work.
- My own little rollout code. It really works good, but when I add
multi-threading with OpenMP, it really does not speed up at all. Getting
this working is actually what I'm spending time on now. I'm really
scratching my head.

As you mention, the tool I posted some weeks ago can indeed be used for
some of the positions. That was actually the main reason I created the tool
in the first place. I think you are right. I have to start with the
positions with a lot of checkers born off. I can probably sort out in a
simple way. I should also only handle positions where gammon and backgammon
are not a subject. I can probably handle those separately.

-Øystein

On Sun, Jun 16, 2019 at 10:33 PM Philippe Michel 
wrote:

> On Mon, Jun 10, 2019 at 02:49:26PM +0200, Øystein Schønning-Johansen wrote:
>
> > I will try re-rolling out these positions. Do you have any experience of
> > how to do good rollouts of race positions? Good rollout settings for race
> > positions?
>
> When I re-rolled out the benchmarks I mostly used the settings that had
> been used previously. I think I changed the rolloutLimit parameter
> somehow (the number of alternatives included for checker plays). It is
> currently set to 10 for doublets and 5 for other rolls. I don't remember
> exactly what I did ; maybe it used to be 5 in all cases.
>
> I previously wrote it would be useful to have variance reduction in
> sagnubg, but this is not very important since it does 0-plys rollouts
> (VR works for them, but it is slow and simply doing more trials is about
> as good in terms of SD vs. time used). Doing 7776 trials instead of 1296
> doesn't seem unrealistic.
>
> From the other parameters :
>
> s version 1.93 weights 1.00 moves2plyLimit 20 rolloutLimit 5 nRollOutGames
> 1296 cubeAway 7 include0Ply 1 evalPlies 2 shortCuts 1 osrGames 1296
> osrInRoll 1
>
> experimenting with osrInRoll set to 0 may be interesting. I dont know if
> OSR
> is used for speed or for accuracy...
>
> Another interesting thing to try, if it is practical, would be to use the
> software you mentionned a few weeks ago to calculate exact values.
>
> For instance, sort the positions by leading player's pipcount. Start
> from the smallest ones with your software ; that should tackle the
> hypergammon-like positions with few checkers and ideally the very
> unbalanced ones where the trailer can only try to save the gammon. The
> latter may well be misplayed in the current rollouts.
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] The race training and benchmark datasets

[Øystein Schønning-Johansen]

Thanks,

I will try re-rolling out these positions. Do you have any experience of
how to do good rollouts of race positions? Good rollout settings for race
positions?

-Øystein



On Sun, Jun 9, 2019 at 11:38 PM Philippe Michel 
wrote:

> On Fri, Jun 07, 2019 at 08:30:10PM +0200, Øystein Schønning-Johansen wrote:
>
> > (Of course I remove any position duplicated in the two datasets, such
> that
> > the training and validation set are disjoint.)
>
> Is it really important (in general) ? I know one shouldn't use the same
> dataset but is some limited random overlap really an issue ? I didn't
> verify how limited it is in the case of gnubg's databases, though...
>
> > I train a neural network. If I validate the training with a 10% fraction
> of
> > the training dataset itself, I get a MSE error of about 1.0e-04. But if I
> > validate against the dataset generated from train.bm-1.00.bz2 I get an
> MSE
> > error of 7e-04. About 7 times higher!
> >
> > This makes me believe that the rolled out positions in the
> race-train-data
> > file is rolled out in an other way (different tool, different settings,
> > different neural net?) than the positions in train.bm-1.00.bz2.
>
> Different tool and different neural net.
>
> For the benchmark databases it is recorded as a comment at the beginning
> of the file :
>
> s version 1.93 weights 1.00 moves2plyLimit 20 rolloutLimit 5 nRollOutGames
> 1296 cubeAway 7 include0Ply 1 evalPlies 2 shortCuts 1 osrGames 1296
> osrInRoll 1
>
> This is version 1.93 of the sagnubg tool, using the 1.OO weights file
> (the current one). I rerolled the benchmark databases with it after the
> new weights file was generated.
>
> The training database was rolled out with a slightly modified gnubg
> (merely to have gnubg -t print the rollout results in the right format).
>
> This was done with earlier weights. I didn't kept notes but I think I
> used one intermediate weights set for the race and possibly more than
> one for the crashed net (rollout the training database with the 0.90
> net, train a new net, reroll the training database with it, etc...). For
> the contact net I'm not sure.
>
> In any case, this was with different weights than the current benchmark
> database.
>
> > Joseph? Philippe? Ian? Others? Do you know how these data where
> generated?
> > Is it maybe worth rolling these positions out again? I do remember that
> > Joseph made a separate rollout tool, but I'm not sure what Philippe did?
>
> It is likely the different errors you got have another cause : as far as
> I can see,the sagnubg tool used for creating the benchmark databases
> doesn't use variance reduction.
>
> That should be enough of a reason to seriously consider rerolling them,
> but we would have to implement variance reduction in sagnubg first or
> use gnubg with some substantial pre- and post-processing.
>
> > (I also remember that the original benchmark was move based, and it
> > calculates the loss based on incorrect moves picked, and that it might
> not
> > be that interesting if the rollout values are abit wrong)
>
> I'm afraid they may not be just a bit wrong. It seems the standard
> deviation of a 1296 trials rollout without variance reduction is larger
> than the vast majority of the "errors" found when running the benchmark.
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

[Bug-gnubg] The race training and benchmark datasets

[Øystein Schønning-Johansen]

Hi, all!

Out of curiosity I've just started to look into the race datasets. I notice
something really strange.

I take all the positions from
http://files.gnubg.com/media/nn-training/pmichel/training_data/race-train-data.bz2
and from this I create a dataset for training.

Then I take all positions from the benchmark dataset.
http://files.gnubg.com/media/nn-training/pmichel/benchmarks/train.bm-1.00.bz2.
and generate a validation training set.

(Of course I remove any position duplicated in the two datasets, such that
the training and validation set are disjoint.)

I train a neural network. If I validate the training with a 10% fraction of
the training dataset itself, I get a MSE error of about 1.0e-04. But if I
validate against the dataset generated from train.bm-1.00.bz2 I get an MSE
error of 7e-04. About 7 times higher!

This makes me believe that the rolled out positions in the race-train-data
file is rolled out in an other way (different tool, different settings,
different neural net?) than the positions in train.bm-1.00.bz2.

Joseph? Philippe? Ian? Others? Do you know how these data where generated?
Is it maybe worth rolling these positions out again? I do remember that
Joseph made a separate rollout tool, but I'm not sure what Philippe did?

(I also remember that the original benchmark was move based, and it
calculates the loss based on incorrect moves picked, and that it might not
be that interesting if the rollout values are abit wrong)

Best regards,
-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] An old bug and possible neural nets input change

[Øystein Schønning-Johansen]

On Thu, Jun 6, 2019 at 12:21 AM Philippe Michel 
wrote:

> Interesting diagram. I suppose the hc_0 and hc_1 prefixes mean the
> inputs are for the player on roll and for the other respectively ?
>

Yes! hc is for "hand crafted" features, the cleaned dataset I used also
have features
prefixed by "b" for "base inputs". 0 is for the player on roll, and 1 is
for the opponent.


> The sum of the values seems to be about 0.5. Should the sum be 1 and the
> basic inputs amount for the complement ? If this is the case, do you
> have the actual sum for the listed inputs ?
>

No, the diagram is not normalized. The abscissa is the drop of error-rate
(I think it is
a mean_absolute_error) when randomizing the samples of that feature.
I can see if I can make a corresponding plot with the base inputs.


> PIPLOSS for one of the players is indeed at the top of the list, but
> aggregated for both players MOBILITY seems to be about equal. The second
> one, ENTER is interesting, it is 0 when the player doesn't have a man on
> the bar so, when it matters, it may well be the most important input.
>

Sure. I'll keep that in mind.


> The first random ideas that come to mind :
>
> - could it worthwile to add a few of the complex features like MOBILITY
> and
> ENTER to the pruning nets ?
>
> - the paper by Berliner mentionned by Ian in another follow-up describes
> his efforts to improve PIPLOSS from a simple but not that good algorithm
> to more or less what we have. Since, according to your analysis, the
> value of this input is very asymetrical between the players, maybe a
> simpler version could be used for at least one of them. That's assuming
> one can come up with something approximate that is much faster but not
> too less accurate.
>

Sure, I also guess we can look at all the different features, and maybe
even come
up with some new ideas. Having a good dataset as the one you have gathered
(Thanks Philippe!)
makes it really simple to train new neural networks and we can try out a
lot of features. I can
now train a contact neural network within a few minutes.

Best regards,
-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] An old bug and possible neural nets input change

[Øystein Schønning-Johansen]

Sorry the late answer, Philippe!

This is a really interesting find. I totally agree with you. The code that
calculates PIPLOSS is really unreadable and un-maintainable. Some years ago
I wrote a structure to hold the board state, and I then also had to adapt
the input calculation to this new board data structure. I stared at this
code for a long long time, but I gave up. It was too complex. For PIPLOSS,
P1 and P2 (and TIMING) I more or less left the code without the potential
speedups the board data structure could give me. However, I did not see
this "bug". And indeed, as you say, this is by far the most expensive
neural net input to calculate.

However, it is slow to calculate, but it seems like it is also one of the
most important inputs. I did a boruta feature importance analysis of the 50
handcrafted inputs, and at the absolute top spot of feature importance
PIPLOSS shines out.
Look at this figure:
https://drive.google.com/file/d/1CscetLk2b8OLrlpOKzV2rCrXLNwex6EF/view?usp=sharing

So... I think maybe we have to keep the input, but maybe we can recalc it
the correct value, and then retrain. Further improvements to the neural
networks should include some feature engineering. I think there is some
potential.

Thanks for the interesting find!
-Øystein





On Wed, May 15, 2019 at 7:16 PM Philippe Michel 
wrote:

> One of gnubg's inputs is the following quantity :
>
> /* Average number of pips opponent loses from hits.
>  *
>  * Some heuristics are required to estimate it, since we have no idea
> what
>  * the best move actually is.
>  *
>  * 1. If board is weak (less than 3 anchors), don't consider hitting on
>  * points 22 and 23.
>  * 2. Don't break anchors inside home to hit.
>  */
> I_PIPLOSS,
>
> The wording is a bit strange (are the comment and the definition from
> some old article by Berliner or something like that ?) It is points
> that are meant, not anchors, and the numbering is from gnubg's internal
> representation and the deep points above are the usual 23 and 24
> points.
>
> Anyway, the heuristics seem reasonable, but the code a bit later is :
>
> /* Piploss */
>
> nBoard = 0;
> for (i = 0; i < 6; i++)
> if (anBoard[i])
> nBoard++;
>
> [...]
>
> /* for every point we'd consider hitting a blot on, */
>
> for (i = (nBoard > 2) ? 23 : 21; i >= 0; i--)
> [...]
>
> nBoard is not the number of made points, it counts the merely slotted
> ones as well... And it has been the case since gnubg's source are
> under the current source control system, for at least 19 years...
>
>
> Even if the error looks gross, this is not too bad in practice :
> - the error is present in both gnubg and the training tool so the
>   weird resulting heuristic is used consistently
> - the number of pips involved is only 1 or 2 when outfield blots count
>   for ten times that
> - the patterns where the condition leads to a difference are
>   uncommon except (2 points + 1 slot)
>
> Still, using "if( anBoard[i] >= 2) nBoard++;", implementing the
> heuristics as described and retraining the contact network a little
> seem to bring a small improvement as measured by the training tool's
> benchmark.
>
>
> On the other hand, this input is the most expensive one to compute by
> far ; more than all the other combined. On my computer, skipping it
> raises the calibration result for one thread from 130k pos/s to 250k.
>
> Its coding is rather complicated. It could probably be improved somewhat
> but, since some retraining of the contact and crashed networks would be
> needed anyway, it may be more promising to use instead one or a few
> other similar metrics if they were much faster to compute.
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Collaboration anyone?

[Øystein Schønning-Johansen]

It sounds like a really cool project. If you host it on github, and then
announce it to some friends, I pretty sure you will have volunteers.

-Øystein


On Thu, May 16, 2019 at 10:30 PM Joseph Heled  wrote:

>
> Hi,
>
> (I know this is the wrong forum, but casting the net anyway)
>
> I am looking for someone who might want to collaborate on a project of
> mine about racing games .
> (It is a "fun" project, like gnubg,  by which I mean non-paid and done out
> of "love". I can't pay anyone since I am not getting paid myself).
>
> I need help in making several "simple" games playable either in the
> browser or on android. "simple" here means the graphical part is trivial,
> and UI primitive. So, a "code jockey" might do.
>
> Do you know of anyone who might be interested? Can be a young (14+) kid
> who is interested. Please pass it on.
>
> Send me an email (mailto:jhe...@gmail.com) if you need more information.
>
> Thanks, Joseph
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Large bearoff databases (was: Huge evaluation difference)

[Øystein Schønning-Johansen]

OK, I've set up a private github repo of the twosided tools. State your
github profile name in a PM if you want access.

-Øystein

On Sun, Mar 24, 2019 at 5:14 PM Øystein Schønning-Johansen <
oyste...@gmail.com> wrote:

> On Sun, Mar 24, 2019 at 4:33 PM Philippe Michel 
> wrote:
>
>> On Sun, Mar 24, 2019 at 03:17:07PM +0100, Øystein Schønning-Johansen
>> wrote:
>> > Yes. Really cool. I have earlier seen significant differences between
>> > one-sided and two-sided race evaluation, but this is not one of the
>> > positions where it is off.
>>
>> I suppose it helps that the opponent's position is a few-rolls position
>> and more balanced long races would not do as well.
>>
>
> Yes! There it actually two ways to do the dynamic programming of two sided
> databases.
> You can do it top-down. You start at the position you are interested in,
> and calculate all the
> possible following positions that can occur in a recursive manner. and
> storing each probability
> in a matrix. In this case it really helps if the position is lopsided,
> such that the game is usually
> over within a few moves. It is actually necessary.
>
>
>> > Some years ago, I used the same algorithm to calculate a full two-sided
>> > database for 15 checkers on 6 points. I can share it by bittorrent, or
>> the
>> > generating code. The data file is 11 GB.
>>
>> Would it be usable as is with the current gnubg ? Would any file larger
>> than 2 Gb be, anyway ?
>>
>
> Yes, to calculate the full two side database of 15 checkers on 6 points, I
> used a bottom-up
> calculation instead. It is (21 choose 6) squared number of position and I
> store them with float
> precision (4 byte): 54264^2 * 4 = 11778326784 = about 11GB.
>
> The maximum size of the file is depending on the file system you are using
> and hence
> the operating system. I more or less always use ext4 on Linux systems and
> have no
> problem opening such big files.
>
> However, I use different techniques to read the data from the file. I
> usually do not read the file
> into memory (however, I can if want), but rather open pointer to the file
> and use seek to position
> the fp to the right address. If the file is on SSD disk, this is usually
> fast enough! I've tried
> memmap() as well, but I got into a technical problem I think (IIRC).
>
> I think the building tools that comes with gnubg is limited by the 32bit
> file pointer size.
> The fp address was overflowing. Maybe these days, when 64 bit
> architectures and
> operating systems are really common, the code can generate even bigger
> data files.
>
> If my database can be used with GNU Backgammon. No, not right out of the
> box, but
> with a few code line inserts, I guess things will work perfectly.
>
>
>> I would be interested in the generating code, at least as an example
>> that handles the kind of issues below.
>>
>
> I'll see what I can share. I'll guess I'll post something on github.
>
>
>> Are you, Øystein, or other readers, familiar with gnubg's bearoff
>> databases format ? (I am not).
>>
>
> Well, I think Gary tried to keep it small, so it's actually using a 2byte
> format for the values.
>
>
>> Would it be enough to compile gnubg with the appropriate
>> _FILE_OFFSET_BITS=64 / _LARGEFILE_SOURCE / _LARGEFILE64_SOURCE #defines
>> and possibly some limited variables type changes in the code to be able
>> to use bigger databases, or are there more subtle limitations in the
>> current code ?
>>
>
> I'm really not sure. I think you have to just try it out and see. I will
> actually guess it does work with the settings you suggest
> (and make sure you are on a 64 bit system, of course), or will work with
> really few tweaks.
>
>
>> Similarly, to create a one-sided database for, say, 15 men up the 8
>> point plus 2 up to the 18 point, or a similar subset of "plausible"
>> positions, would it be enough to find an adequate indexing scheme ?
>>
>
> Yeah, these are issues I've been thinking of as well, can a bearoff
> database be "parted" like this? I've not found a good answer to that. The
> indexing system becomes really complicated.
>
> -Øystein
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Large bearoff databases (was: Huge evaluation difference)

[Øystein Schønning-Johansen]

On Sun, Mar 24, 2019 at 4:33 PM Philippe Michel 
wrote:

> On Sun, Mar 24, 2019 at 03:17:07PM +0100, Øystein Schønning-Johansen wrote:
> > Yes. Really cool. I have earlier seen significant differences between
> > one-sided and two-sided race evaluation, but this is not one of the
> > positions where it is off.
>
> I suppose it helps that the opponent's position is a few-rolls position
> and more balanced long races would not do as well.
>

Yes! There it actually two ways to do the dynamic programming of two sided
databases.
You can do it top-down. You start at the position you are interested in,
and calculate all the
possible following positions that can occur in a recursive manner. and
storing each probability
in a matrix. In this case it really helps if the position is lopsided, such
that the game is usually
over within a few moves. It is actually necessary.


> > Some years ago, I used the same algorithm to calculate a full two-sided
> > database for 15 checkers on 6 points. I can share it by bittorrent, or
> the
> > generating code. The data file is 11 GB.
>
> Would it be usable as is with the current gnubg ? Would any file larger
> than 2 Gb be, anyway ?
>

Yes, to calculate the full two side database of 15 checkers on 6 points, I
used a bottom-up
calculation instead. It is (21 choose 6) squared number of position and I
store them with float
precision (4 byte): 54264^2 * 4 = 11778326784 = about 11GB.

The maximum size of the file is depending on the file system you are using
and hence
the operating system. I more or less always use ext4 on Linux systems and
have no
problem opening such big files.

However, I use different techniques to read the data from the file. I
usually do not read the file
into memory (however, I can if want), but rather open pointer to the file
and use seek to position
the fp to the right address. If the file is on SSD disk, this is usually
fast enough! I've tried
memmap() as well, but I got into a technical problem I think (IIRC).

I think the building tools that comes with gnubg is limited by the 32bit
file pointer size.
The fp address was overflowing. Maybe these days, when 64 bit architectures
and
operating systems are really common, the code can generate even bigger data
files.

If my database can be used with GNU Backgammon. No, not right out of the
box, but
with a few code line inserts, I guess things will work perfectly.


> I would be interested in the generating code, at least as an example
> that handles the kind of issues below.
>

I'll see what I can share. I'll guess I'll post something on github.


> Are you, Øystein, or other readers, familiar with gnubg's bearoff
> databases format ? (I am not).
>

Well, I think Gary tried to keep it small, so it's actually using a 2byte
format for the values.


> Would it be enough to compile gnubg with the appropriate
> _FILE_OFFSET_BITS=64 / _LARGEFILE_SOURCE / _LARGEFILE64_SOURCE #defines
> and possibly some limited variables type changes in the code to be able
> to use bigger databases, or are there more subtle limitations in the
> current code ?
>

I'm really not sure. I think you have to just try it out and see. I will
actually guess it does work with the settings you suggest
(and make sure you are on a 64 bit system, of course), or will work with
really few tweaks.


> Similarly, to create a one-sided database for, say, 15 men up the 8
> point plus 2 up to the 18 point, or a similar subset of "plausible"
> positions, would it be enough to find an adequate indexing scheme ?
>

Yeah, these are issues I've been thinking of as well, can a bearoff
database be "parted" like this? I've not found a good answer to that. The
indexing system becomes really complicated.

-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Huge evaluation difference

[Øystein Schønning-Johansen]

Yes. Really cool. I have earlier seen significant differences between
one-sided and two-sided race evaluation, but this is not one of the
positions where it is off.

Some years ago, I used the same algorithm to calculate a full two-sided
database for 15 checkers on 6 points. I can share it by bittorrent, or the
generating code. The data file is 11 GB.

-Øystein

On Sun, 24 Mar 2019 15:00 Philippe Michel,  wrote:

> On Thu, Mar 21, 2019 at 12:54:18PM +0100, Øystein Schønning-Johansen wrote:
>
> > Cubeless prob. of saving gammon: 0.129424
> > 16: 13/12 12/6  -> 0.913103
> > 16: 13/12 8/2   -> 0.938736
> > 16: 13/12 7/1   -> 0.942557
> > 16: 8/7 8/2 -> 0.984595
> > 16: 8/7 7/1 -> 0.984930
> > 16: 7/6 7/1 -> 0.922614
> > 61: 13/7 8/7-> 0.984416
> > 61: 13/7 6/5-> 0.984048
> > 61: 8/2 7/6 -> 0.915246
> > 61: 8/2 6/5 -> 0.984322
> > 61: 7/1 6/5 -> 0.984760
>
> It looks like the one-sided bearoff database is accurate to at leat 3
> digits :-).
>
> > > > > 1. Cubeful 2-ply13/6 Eq.: -2.201
> > > > >0.000 0.000 0.000 - 1.000 0.913 0.000
> > > > > 2-ply cubeful prune [world class]
> > > > > 2. Cubeful 2-ply8/2 7/6  Eq.: -2.204
> > > (-0.003)
> > > > >0.000 0.000 0.000 - 1.000 0.915 0.000
> > > > > 2-ply cubeful prune [world class]
> > > > > 3. Cubeful 2-ply7/6 7/1  Eq.: -2.213
> > > (-0.013)
> > > > >0.000 0.000 0.000 - 1.000 0.923 0.000
> > > > > 2-ply cubeful prune [world class]
> > > > > 4. Cubeful 2-ply13/12 8/2Eq.: -2.234
> > > (-0.034)
> > > > >0.000 0.000 0.000 - 1.000 0.939 0.000
> > > > > 2-ply cubeful prune [world class]
> > > > > 5. Cubeful 2-ply13/12 7/1Eq.: -2.240
> > > (-0.039)
> > > > >0.000 0.000 0.000 - 1.000 0.943 0.000
> > > > > 2-ply cubeful prune [world class]
> > > > > 6. Cubeful 2-ply13/7 6/5 Eq.: -2.294
> > > (-0.093)
> > > > >0.000 0.000 0.000 - 1.000 0.984 0.000
> > > > > 2-ply cubeful prune [world class]
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Huge evaluation difference

[Øystein Schønning-Johansen]

Sure I can. The system actually calculates the probability of saving gammon
for all possible position that can come up. (That's the dynamic programming
part) So, since I've already calculated all these probabilities, it's easy
to get those numbers after a specific roll+move.

 oystein@LinuxGPU4:~/octopus/twoside$ ./lopsided --mode=gammonsave
23631 2231
#off:  0  board: 23|63|1-|-
chk(bb): xx|xx|x-|- back: 13 #out: 10 #cross: 26
#off:  7  board: 2231--|--|--|-
chk(bb): --|--|--|- back:  4 #out:  0 #cross:  8
Cubeless prob. of saving gammon: 0.129424
16: 13/12 12/6  -> 0.913103
16: 13/12 8/2   -> 0.938736
16: 13/12 7/1   -> 0.942557
16: 8/7 8/2 -> 0.984595
16: 8/7 7/1 -> 0.984930
16: 7/6 7/1 -> 0.922614
61: 13/7 8/7-> 0.984416
61: 13/7 6/5-> 0.984048
61: 8/2 7/6 -> 0.915246
61: 8/2 6/5 -> 0.984322
61: 7/1 6/5 -> 0.984760

Note that I didn't bother to order the moves in the printout. That will be
available in next version. :-)
And since this is with the other player on roll, it is then the probability
of winning gammon for the other player that is listed. The best move is
therefore the move with lowest value, 13/6, listed at the top..

-Øystein



On Wed, Mar 20, 2019 at 11:10 PM Philippe Michel 
wrote:

> On Wed, Mar 20, 2019 at 11:40:41AM +0100, ?ystein Sch?nning-Johansen wrote:
>
> > I managed to calculate the gammon saving probability of the posted
> position
> > in a few minutes using about 15GB of memory. (I also have a slower
> version
> > of the tool that uses sparse matrices to store the probabilities, but I
> did
> > not try that today)
> >
> > oystein@LinuxGPU4:~/octopus/twoside$ ./lopsided --mode=gammonsave
> > 23631 2231
> > #off:  0  board: 23|63|1-|-
> > chk(bb): xx|xx|x-|- back: 13 #out: 10 #cross: 26
> > #off:  7  board: 2231--|--|--|-
> > chk(bb): --|--|--|- back:  4 #out:  0 #cross:  8
> > Cubeless prob. of saving gammon: 0.129424
>
> This is not directly comparable with the numbers below since your number
> is before the roll. Can you compute it from the other side (probability
> of winning a gammon) for the first 2 or 3 choices of playing a 61 roll ?
>
> > > 1. Cubeful 2-ply13/6 Eq.: -2.201
> > >0.000 0.000 0.000 - 1.000 0.913 0.000
> > > 2-ply cubeful prune [world class]
> > > 2. Cubeful 2-ply8/2 7/6  Eq.: -2.204
> (-0.003)
> > >0.000 0.000 0.000 - 1.000 0.915 0.000
> > > 2-ply cubeful prune [world class]
> > > 3. Cubeful 2-ply7/6 7/1  Eq.: -2.213
> (-0.013)
> > >0.000 0.000 0.000 - 1.000 0.923 0.000
> > > 2-ply cubeful prune [world class]
> > > 4. Cubeful 2-ply13/12 8/2Eq.: -2.234
> (-0.034)
> > >0.000 0.000 0.000 - 1.000 0.939 0.000
> > > 2-ply cubeful prune [world class]
> > > 5. Cubeful 2-ply13/12 7/1Eq.: -2.240
> (-0.039)
> > >0.000 0.000 0.000 - 1.000 0.943 0.000
> > > 2-ply cubeful prune [world class]
> > > 6. Cubeful 2-ply13/7 6/5 Eq.: -2.294
> (-0.093)
> > >0.000 0.000 0.000 - 1.000 0.984 0.000
> > > 2-ply cubeful prune [world class]
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Huge evaluation difference

[Øystein Schønning-Johansen]

I wrote a little tool some years ago, that calculate the "exact" value for
such racing position. It calculates the probabilities with a top-down
dynamic programming way and uses *-minimax algorithm to fill in the values
and prune useless moves.

It is really unusable in real life situation as the evaluation usually
takes a few minutes (depending on the position, of course), and the
calculation uses a lot of memory! However I was hoping this method could
have been used in establishing a training dataset, but I've not build such
a dataset yet. :-o

I managed to calculate the gammon saving probability of the posted position
in a few minutes using about 15GB of memory. (I also have a slower version
of the tool that uses sparse matrices to store the probabilities, but I did
not try that today)

oystein@LinuxGPU4:~/octopus/twoside$ ./lopsided --mode=gammonsave
23631 2231
#off:  0  board: 23|63|1-|-
chk(bb): xx|xx|x-|- back: 13 #out: 10 #cross: 26
#off:  7  board: 2231--|--|--|-
chk(bb): --|--|--|- back:  4 #out:  0 #cross:  8
Cubeless prob. of saving gammon: 0.129424

If anyone is interested, I'll share some code.

-Øystein

On Tue, Mar 19, 2019 at 10:36 PM Philippe Michel 
wrote:

> On Mon, Mar 18, 2019 at 10:25:52AM +0100, Terje Pedersen wrote:
>
> > I just ran into a huge evaluation difference between XG and Gnu BG:
> >
> > XGID=-BCFCA---acbb-:1:1:1:16:0:0:0:5:10
> >
> > I got dinged with a -0.684 error here while XG says it is a -0.0013
> > error to play 13/6.
> >
> > Desktop version says it is:
> >
> > 7. Cubeful 0-ply13/6 Eq.:  -2,264 (
> -0,328)
> >0,000 0,000 0,000 - 1,000 0,964 0,000
> > 0-ply cubeful prune [expert]
> >
> > but still wildly off. Perhaps difficult to fix these kind of problems?
>
> The position is of a kind that was probably not common in the racing
> neural net training database. X's formation just doesn't happen in real
> play, does it ?
>
>  GNU Backgammon  Position ID: 2wUAAAb3OwgAAA
>  Match ID   : UQmnAAAE
>  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: GNUbg
>  | X|   |   O  O  O  O | OO  0 points
>  |  |   |  O  O  O | OO
>  |  |   |  O   | O
>  |  |   |  | O
>  |  |   |  | O
> v|  |BAR|  | 5 point match
>  |6 |   |  |
>  |X |   |  |
>  | X  X |   | X|
>  | X  X |   | X  X | Rolled 61
>  | X  X |   | X  X | 0 points
>  +12-11-10--9--8--7---6--5--4--3--2--1-+ X: You (Cube: 2)
> Pip counts : O 19, X 99
>
> "Fixing" this at the neural net level doesn't look easy. Adding a few
> hundreds or thousands of similar positions in the training data would
> probably help but it is difficult to guess in advance if the improvement
> would be significant.
>
> It wouldn't change the program's strength (it doesn't get into these
> positions) but may avoid or at least mitigate this kind of embarrassing
> result when analysing.
>
> What you can do if it is important for you (for the analysis feature of
> Backgamon Studio, I suppose) is to use the largest one-sided bearoff
> database, available there :
> ftp://ftp.demon.nl/pub/Museum/Demon/games/gnubg/databases/os/
>
> If the download size is an issue, you can compute it yourself with the
> makebearoff utility from gnubg ; os13.bd (with the back checker up to
> the midpoint, as in your position) should take about one day, smaller
> ones would be much faster.
>
> With it, I get :
>
> 1. Cubeful 2-ply13/6 Eq.: -2.201
>0.000 0.000 0.000 - 1.000 0.913 0.000
> 2-ply cubeful prune [world class]
> 2. Cubeful 2-ply8/2 7/6  Eq.: -2.204 (-0.003)
>0.000 0.000 0.000 - 1.000 0.915 0.000
> 2-ply cubeful prune [world class]
> 3. Cubeful 2-ply7/6 7/1  Eq.: -2.213 (-0.013)
>0.000 0.000 0.000 - 1.000 0.923 0.000
> 2-ply cubeful prune [world class]
> 4. Cubeful 2-ply13/12 8/2Eq.: -2.234 (-0.034)
>0.000 0.000 0.000 - 1.000 0.939 0.000
> 2-ply cubeful prune [world class]
> 5. Cubeful 2-ply13/12 7/1Eq.: -2.240 (-0.039)
>0.000 0.000 0.000 - 1.000 0.943 0.000
> 2-ply cubeful prune [world class]
> 6. Cubeful 2-ply13/7 6/5 Eq.: -2.294 (-0.093)
>0.000 0.000 0.000 - 1.000 0.984 0.000
> 2-ply cubeful prune [world class]
>
> It may seem radical to use a 1.5 Gb database just for this but, besides
> the disk space needed, it is essentially free. The file is not read, it
> is merely mapped into memory and the r

Re: [Bug-gnubg] Surprising behaviour in cubeless play

[Øystein Schønning-Johansen]

I also believe this behavior is intentionally like this. I certainly do not
remember, but I think the best answer will be provided by Jørn.

On Sat, Feb 23, 2019 at 10:03 PM Philippe Michel 
wrote:

> When choosing to play without doubling cube (in settings / options /
> cube), the following warning is displayed :
>
> "Use of the doubling cube is disabled.
> Note that you'll have to disable the Jacoby rule if you want gammons and
> backgammons to be scored (see `help set jacoby')."
>
> What could be the point of this behaviour ? Shouldn't the Jacoby rule
> always be ignored in cubeless play ?
>
> The way this is documented suggests this is a choice, not an oversight.
> Does anyone who has been following gnubg's development for long enough
> remember why it is done this way ?
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Race position theoretical question?

[Øystein Schønning-Johansen]

Yes! This position actually proves that there are positions that can both
loose backgammon and still be won. X can get all his checkers off in 15
rolls (with only 6-6 rolls), while O also may use 15 rolls to get off all
checkers. Based on this example, I actually guess there are several
positions with this property.

Josephs position also work, but it has to be the race leading player on
roll.

Thanks guys,
-Øystein


On Tue, Jan 29, 2019 at 9:46 PM Philippe Michel 
wrote:

> On Tue, Jan 29, 2019 at 08:00:22PM +0100, Øystein Schønning-Johansen wrote:
> > Hi all!
> >
> > Here is a theoretical question for all of you:
> >
> > Can a race (aka. non-contact) position, be possible to lose backgammon
> with
> > a good dash of unluck, and still be possible to win (with a good dash of
> > luck).
>
> Something like this ?
>
>  GNU Backgammon  Position ID: /P8BAPD/Bw
>  Match ID   : UQkA
>  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: GNUbg
>  |  |   |   X  O   | 0 points
>  |  |   |   X  O   |
>  |  |   |   X  O   |
>  |  |   |   X  O   |
>  |  |   |   F  F   |
> v|  |BAR|  |
>  |  |   |  |
>  |  |   |  |
>  |  |   |  |
>  |  |   |  | On roll
>  |  |   |  | 0 points
>  +12-11-10--9--8--7---6--5--4--3--2--1-+ X: You (Cube: 2)
> Pip counts : O 45, X 315
>
> X wins if he rolls only 6-6s and O only 2-1s, and loses a backgammon if
> he is moderately unlucky.
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

[Bug-gnubg] Race position theoretical question?

[Øystein Schønning-Johansen]

Hi all!

Here is a theoretical question for all of you:

Can a race (aka. non-contact) position, be possible to lose backgammon with
a good dash of unluck, and still be possible to win (with a good dash of
luck). It is assumed that the player is really trying to get of the
backgammon, and plays the best move to get off the backgammon. We do not
take stupidity into account.

A bit more mathematically stated:
Let S be the set of all possible race positions.
Let A be the subset of S where P(lose backgammon) > 0.
Let B be the subset of S where P(win) > 0.

Is the intersection of A and B an empty set?

I think it is, but I cannot find a simple proof. (It probably is an obvious
proof to this, however I'm too narrow minded to see it.)

If it is not an empty set, can you please post a position in this
intersection?

Thanks,
-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Gnubg pubeval score

[Øystein Schønning-Johansen]

Thanks for your effort Philippe. Your numbers looks correct.

However, I think it is important to state some more details.

First: Are the games played to completion? Or are the games terminated at
race or bearoff or ...
Second: Does the pubeval evaluate all the position classes? I once did the
mistake in a similar experiment where the pubeval player actually used a
full bearoff look up table.
And then: These are cubeless moneygames I assume. These are not one-point
matches.

(Another potential bug is the opening roll. I guess that it is taken care
of.)

Thanks again for you effort, Philippe.
-Øystein


On Fri, Jan 25, 2019 at 9:51 PM Philippe Michel 
wrote:

> On Tue, Jan 22, 2019 at 08:31:08AM -0800, Robert Edgar wrote:
>
> > Can anyone confirm the score of a recent version of gnubg vs. pubeval? I
> > hacked the source and found that gnubg v1.06 averaged +1.1ppg (82% wins)
> > over 10k games, but a recent paper Papahristou & Refanidis (2017) quotes
> > +0.60 ppg which is only marginally better than TD-Gammon (+0.59). My
> > number seems high, but +0.6 seems too low considering how much effort
> > went into optimizing the gnubg code.
>
> Three 10k games trials with the current net give (for 0 ply evaluations) :
> +0.635ppg (71.1% wins)
> +0.630ppg (70.9% wins)
> +0.645ppg (71.7% wins)
>
> Without counting backgammons the nubers become 0.612, 0.603 and 0.620.
>
> +1.1ppg and 82% wins is simply impossible. There must be some bug in
> your pubeval implementation or usage.
>
> Amusingly, the message quoted in Ian Shaw's answer is from a thread
> started by someone who got a similarly high number (from his own program
> rather than gnubg) and it was due to such a bug :
> https://lists.gnu.org/archive/html/bug-gnubg/2012-01/msg00019.html
>
>
> FWIW, I ran shorter trials at 1 ply and 2 ply.
> 1000 games @ 1 ply : +0.66ppg
> 100 games @ 2 ply : +0.70ppg
>
> If someone is interested, I could do these with 10 times more games (it
> would take a few hours instead of a few minutes) but there would still
> be a lot of uncertainty in the 2 ply result.
>
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Gnubg pubeval score

[Øystein Schønning-Johansen]

How does the paper report this? Does it take gammon and backgammons into
account (ie. cubeless moneygame) or does it just count win/loss ratio (ie.
like one-point-match) ?

-Øystein

On Tue, Jan 22, 2019 at 11:05 PM Robert Edgar  wrote:

> Can anyone confirm the score of a recent version of gnubg vs. pubeval? I
> hacked the source and found that gnubg v1.06 averaged +1.1ppg (82% wins)
> over 10k games, but a recent paper Papahristou & Refanidis (2017) quotes
> +0.60 ppg which is only marginally better than TD-Gammon (+0.59). My
> number seems high, but +0.6 seems too low considering how much effort
> went into optimizing the gnubg code.
>
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Stopsend me email

[Øystein Schønning-Johansen]

Hi, if you follow the link at the very end of this email (or any email from
the mailing list) you will find instructions on how to unsubscribe. If you
have any problems unsubscribe, please contact the mailing list admin. The
admin email address is also given at the linked web page.

Regards,
Øystein

On Mon, 19 Nov 2018 23:13 niv niv  Pls dont send me emails
> Ty
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] gnubackgammon

[Øystein Schønning-Johansen]

On Sat, Jul 28, 2018 at 10:27 AM Ralph Corderoy 
wrote:

>
> Can we rewind a bit because the mailing list isn't privy to what's
> happened.
>
> Your first problem was the missing toolbar, so no New, Accept, Decline,
> Undo, etc., buttons, but the rest of the game was present and working?
>

Sorry about this. Just to recap. Brenda reported the missing toolbar
problem. I replied to try the F11 or Esc button, and Brenda reported that
it worked fine.
I consider the Gdk error problem as a new issue.

Thanks, Ralph for clearing up the confusion.

So... I assume you are using this on a windows computer, Brenda? To me it
looks like the settings files are stored (at default) in the following
directory:
C:\Users\\.gnubg\

Can you check this directory and look for the files .gnubgrc and
.gnubgautorc . Can you attach these files to an reply to this message?

You can also try to confirm my suspicion by renaming these two files, and
re-launch GNU Backgammon. If it then starts, I think we can solve the
problem.

-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] gnubackgammon

[Øystein Schønning-Johansen]

Hi again, Brenda.

Now I'm a bit more uncertain what cases your problem. I'm adding the
mailing list such that other users and developers may be able to help.

I think you have to describe what you do get this error message. Is it when
you start GNU Backgammon? From my hunch, I guess there is something bogus
in your settings file.
I'm actually not sure where and what the settings file is called? Is it
.gnubgautorc? (If I'm wrong please correct me someone)

Can you, if you find this file, mail it here to the mailing list?

Thanks,
-Øystein

On Fri, Jul 27, 2018 at 11:18 PM Brenda Langridge 
wrote:

> Now every time I try to load it I get  message that says:
> "Gdk ERROR.  That is a fatal error aborting,,,"
>
> What should I do with this?
> \
> Brenda
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] gnubackgammon

[Øystein Schønning-Johansen]

Hmmm... can it be that you are playing in full screen mode?

Try hitting F11 or Esc.

-Øystein

On Sun, Jul 22, 2018 at 8:20 AM Brenda Langridge 
wrote:

> I have been playing gnubg backgammon got quite a while now and really
> enjoy it.  When I used to load it, I always got the tool bar.  Now
> suddenly I don't get that
>
> version any more.  How  can I get it back?
>
> (`'·.¸ (`'·.¸ * * ¸.·'´) ¸.·'´ )
>  «´¨`·.*Brenda*.·´¨`»  Langridge
> ( ¸.·'´(¸.·'´ * * `'·.¸) `'·.¸ )
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Possible evaluation bug

[Øystein Schønning-Johansen]

Hehe!

The difference I spot is the move filters. However the analysis uses less
filtering than hint, and yet it is analysis which get's it wrong? Strange.
In my settings I have:

  Move filter for 2 ply:
keep the first 0 0-ply moves and up to 8 more moves within equity
0.16
Skip pruning for 1-ply moves.

I wonder what happens if I increase this to 16/0.32 ?

Hah! Then I get the same thing as you!

Rolled 51 (-0.066):
 1. Cubeful 2-ply24/18Eq.: -1.8477
   0.1439 0. 0. - 0.8561 0.7156 0.4286
2-ply cubeful prune [world class]
 2. Cubeful 2-ply24/19 6/5Eq.: -1.9908 (-0.1431)
   0.1062 0. 0. - 0.8938 0.7347 0.6269
2-ply cubeful prune [world class]
 3. Cubeful 2-ply24/19 7/6Eq.: -2.0118 (-0.1641)
   0.1022 0. 0. - 0.8978 0.7392 0.6261
2-ply cubeful prune [world class]
*4. Cubeful 2-ply24/19 18/17  Eq.: -2.0615 (-0.2139)
   0.0892 0. 0. - 0.9108 0.7435 0.6447
2-ply cubeful prune [world class]

So the conclusion must be that there is something funny with the
movefilters. Don't know what.

-Øystein





On Sat, Feb 17, 2018 at 1:57 PM, Terje Pedersen  wrote:

> Sure.
>
> Best regards,
> TP
>
>
> On Sat, Feb 17, 2018 at 1:51 PM, Øystein Schønning-Johansen
>  wrote:
> > This observation can be a clue, indeed.
> >
> > Can you do:
> > show evaluation
> > show analyzis
> >
> > That will hopefully give us the difference in the settings, that lead to
> the
> > different results.
> >
> > -Øystein
> >
> > On Sat, Feb 17, 2018 at 1:36 PM, Terje Pedersen 
> wrote:
> >>
> >> I tried adding:
> >>
> >> set evaluation chequerplay evaluation prune off
> >>
> >> to the command file but the output is the same.
> >>
> >> I have noticed that if I use 'hint' instead of 'analyze move' I get a
> >> completely different result.
> >>
> >> set player 0 human
> >> new match 0
> >> set output rawboard off
> >> set xgid XGID=BBCA-AB-B--eB-:0:0:1:51:0:3:0:5:10
> >> move 24/19 18/17
> >> previous
> >> hint
> >>
> >> Perhaps it could be a clue. Not sure.
> >>
> >> Best regards,
> >> TP
> >>
> >>
> >> On Sat, Feb 17, 2018 at 1:05 PM, Øystein Schønning-Johansen
> >>  wrote:
> >> > Yes! Things looks correct.
> >> >
> >> > I browse the code history from your release to the one I'm using. The
> >> > only
> >> > change I can see that may matter, is the use of pruning neural
> networks
> >> > in
> >> > move selections.
> >> > Can you try also with pruning turned turned off. Does that change
> >> > anything?
> >> >
> >> > -Øystein
> >> >
> >> > On Sat, Feb 17, 2018 at 12:38 PM, Terje Pedersen 
> >> > wrote:
> >> >>
> >> >> Hi!
> >> >>
> >> >> Initially it triggered on an ubuntu server: 4.4.0-67-generic
> >> >> #88-Ubuntu that runs the same 1.05.000 version of gnu bg then I tried
> >> >> it on my Windows 10 machine and got the same result.
> >> >>
> >> >> (No game) show matchequitytable
> >> >> Match equity table: Kazaross XG2 25 point MET
> >> >> (/usr/local/share/gnubg/met/Kazaross-XG2.xml)
> >> >>
> >> >> looks good.
> >> >>
> >> >> I'll give 1.06 version a try and see if it will handle this position
> >> >> differently.
> >> >>
> >> >> Thanks for your reply!
> >> >>
> >> >> Best regards,
> >> >> TP
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Sat, Feb 17, 2018 at 11:44 AM, Øystein Schønning-Johansen
> >> >>  wrote:
> >> >> > Really strange. However it is a heisenbug (of course). I cannot
> >> >> > recreate
> >> >> > the
> >> >> > bug on my system. (GNU Backgammon 1.06.000  Dec 13 2017, Arch
> Linux)
> >> >> >
> >> >> > Here is how the same thing looks at my system:
> >> >> >
> >> >> >  GNU Backgammon  Position ID: PgAAALYLBDMMAA
> >> >> >  Match ID   : cImmADAE
> >> >> >  +13-14-15-16-17-18--19-20-21

Re: [Bug-gnubg] Possible evaluation bug

[Øystein Schønning-Johansen]

This observation can be a clue, indeed.

Can you do:
show evaluation
show analyzis

That will hopefully give us the difference in the settings, that lead to
the different results.

-Øystein

On Sat, Feb 17, 2018 at 1:36 PM, Terje Pedersen  wrote:

> I tried adding:
>
> set evaluation chequerplay evaluation prune off
>
> to the command file but the output is the same.
>
> I have noticed that if I use 'hint' instead of 'analyze move' I get a
> completely different result.
>
> set player 0 human
> new match 0
> set output rawboard off
> set xgid XGID=BBCA-AB-B--eB-:0:0:1:51:0:3:0:5:10
> move 24/19 18/17
> previous
> hint
>
> Perhaps it could be a clue. Not sure.
>
> Best regards,
> TP
>
>
> On Sat, Feb 17, 2018 at 1:05 PM, Øystein Schønning-Johansen
>  wrote:
> > Yes! Things looks correct.
> >
> > I browse the code history from your release to the one I'm using. The
> only
> > change I can see that may matter, is the use of pruning neural networks
> in
> > move selections.
> > Can you try also with pruning turned turned off. Does that change
> anything?
> >
> > -Øystein
> >
> > On Sat, Feb 17, 2018 at 12:38 PM, Terje Pedersen 
> wrote:
> >>
> >> Hi!
> >>
> >> Initially it triggered on an ubuntu server: 4.4.0-67-generic
> >> #88-Ubuntu that runs the same 1.05.000 version of gnu bg then I tried
> >> it on my Windows 10 machine and got the same result.
> >>
> >> (No game) show matchequitytable
> >> Match equity table: Kazaross XG2 25 point MET
> >> (/usr/local/share/gnubg/met/Kazaross-XG2.xml)
> >>
> >> looks good.
> >>
> >> I'll give 1.06 version a try and see if it will handle this position
> >> differently.
> >>
> >> Thanks for your reply!
> >>
> >> Best regards,
> >> TP
> >>
> >>
> >>
> >>
> >> On Sat, Feb 17, 2018 at 11:44 AM, Øystein Schønning-Johansen
> >>  wrote:
> >> > Really strange. However it is a heisenbug (of course). I cannot
> recreate
> >> > the
> >> > bug on my system. (GNU Backgammon 1.06.000  Dec 13 2017, Arch Linux)
> >> >
> >> > Here is how the same thing looks at my system:
> >> >
> >> >  GNU Backgammon  Position ID: PgAAALYLBDMMAA
> >> >  Match ID   : cImmADAE
> >> >  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
> >> >  | X  X |   |XO  X | OO  3 points
> >> >  |X |   |XO  X | OO
> >> >  |  |   | O| OO
> >> >  |  |   | O| OO
> >> >  |  |   | O| OO
> >> > v|  |BAR|  | 5 point match (Cube:
> 1)
> >> >  |  |   |  |
> >> >  |  |   |  |
> >> >  |  |   | X|
> >> >  |  |   | X  X  X  | Rolled 51
> >> >  |X |   | X  X  X  | 0 points
> >> >  +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein
> >> >
> >> >
> >> > Cube analysis
> >> > 2-ply cubeless equity -2.2349 (Money: -2.0391)
> >> >   0.0860 0. 0. - 0.9140 0.7715 0.4396
> >> > Cubeful equities:
> >> > 1. No double   -2.0550
> >> > 2. Double, pass+1.  (+3.0550)
> >> > 3. Double, take-2.4258  (-0.3708)
> >> > Proper cube action: No double, take (10.8%)
> >> >
> >> > Rolled 51 (-0.066):
> >> > *1. Cubeful 2-ply24/19 18/17  Eq.: -2.0615
> >> >0.0892 0. 0. - 0.9108 0.7435 0.6447
> >> > 2-ply cubeful prune [world class]
> >> >  2. Cubeful 2-ply13/7 Eq.: -2.1614
> >> > (-0.0999)
> >> >0.0707 0. 0. - 0.9293 0.7800 0.6404
> >> > 2-ply cubeful prune [world class]
> >> >  3. Cubeful 2-ply13/8 6/5 Eq.: -2.1766
> >> > (-0.1151)
> >> >0.0701 0. 0. - 0.9299 0.7866 0.6634
> >> > 2-ply cubeful prune [world class]
> >> >  4. Cubeful 2-ply18/13 6/5Eq.: -2.1963
> >> > (-0.1348)
> >> > 

Re: [Bug-gnubg] Possible evaluation bug

[Øystein Schønning-Johansen]

Yes! Things looks correct.

I browse the code history from your release to the one I'm using. The only
change I can see that may matter, is the use of pruning neural networks in
move selections.
Can you try also with pruning turned turned off. Does that change anything?

-Øystein

On Sat, Feb 17, 2018 at 12:38 PM, Terje Pedersen  wrote:

> Hi!
>
> Initially it triggered on an ubuntu server: 4.4.0-67-generic
> #88-Ubuntu that runs the same 1.05.000 version of gnu bg then I tried
> it on my Windows 10 machine and got the same result.
>
> (No game) show matchequitytable
> Match equity table: Kazaross XG2 25 point MET
> (/usr/local/share/gnubg/met/Kazaross-XG2.xml)
>
> looks good.
>
> I'll give 1.06 version a try and see if it will handle this position
> differently.
>
> Thanks for your reply!
>
> Best regards,
> TP
>
>
>
>
> On Sat, Feb 17, 2018 at 11:44 AM, Øystein Schønning-Johansen
>  wrote:
> > Really strange. However it is a heisenbug (of course). I cannot recreate
> the
> > bug on my system. (GNU Backgammon 1.06.000  Dec 13 2017, Arch Linux)
> >
> > Here is how the same thing looks at my system:
> >
> >  GNU Backgammon  Position ID: PgAAALYLBDMMAA
> >  Match ID   : cImmADAE
> >  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
> >  | X  X |   |XO  X | OO  3 points
> >  |X |   |XO  X | OO
> >  |  |   | O| OO
> >  |  |   | O| OO
> >  |  |   | O| OO
> > v|  |BAR|  | 5 point match (Cube: 1)
> >  |  |   |  |
> >  |  |   |  |
> >  |  |   | X|
> >  |  |   | X  X  X  | Rolled 51
> >  |X |   | X  X  X  | 0 points
> >  +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein
> >
> >
> > Cube analysis
> > 2-ply cubeless equity -2.2349 (Money: -2.0391)
> >   0.0860 0. 0. - 0.9140 0.7715 0.4396
> > Cubeful equities:
> > 1. No double   -2.0550
> > 2. Double, pass+1.  (+3.0550)
> > 3. Double, take-2.4258  (-0.3708)
> > Proper cube action: No double, take (10.8%)
> >
> > Rolled 51 (-0.066):
> > *1. Cubeful 2-ply24/19 18/17  Eq.: -2.0615
> >0.0892 0. 0. - 0.9108 0.7435 0.6447
> > 2-ply cubeful prune [world class]
> >  2. Cubeful 2-ply13/7 Eq.: -2.1614
> (-0.0999)
> >0.0707 0. 0. - 0.9293 0.7800 0.6404
> > 2-ply cubeful prune [world class]
> >  3. Cubeful 2-ply13/8 6/5 Eq.: -2.1766
> (-0.1151)
> >0.0701 0. 0. - 0.9299 0.7866 0.6634
> > 2-ply cubeful prune [world class]
> >  4. Cubeful 2-ply18/13 6/5Eq.: -2.1963
> (-0.1348)
> >0.0603 0. 0. - 0.9397 0.7831 0.6918
> > 2-ply cubeful prune [world class]
> >  5. Cubeful 2-ply18/17 18/13  Eq.: -2.2086
> (-0.1470)
> >0.0567 0. 0. - 0.9433 0.7815 0.7003
> > 2-ply cubeful prune [world class]
> >  6. Cubeful 2-ply18/12Eq.: -2.2291
> (-0.1676)
> >0.0544 0. 0. - 0.9456 0.7887 0.6961
> > 2-ply cubeful prune [world class]
> >  7. Cubeful 2-ply18/17 13/8   Eq.: -2.2481
> (-0.1866)
> >0.0524 0. 0. - 0.9476 0.7953 0.6954
> > 2-ply cubeful prune [world class]
> >  8. Cubeful 2-ply18/17 7/2Eq.: -2.2952
> (-0.2337)
> >0.0476 0. 0. - 0.9524 0.8135 0.7098
> > 2-ply cubeful prune [world class]
> >  9. Cubeful 0-ply24/19 6/5Eq.: -2.1277
> (-0.0661)
> >0.0653 0. 0. - 0.9347 0.7599 0.4187
> > 0-ply cubeful prune [expert]
> > 10. Cubeful 0-ply18/13 7/6Eq.: -2.1289
> (-0.0674)
> >0.0648 0. 0. - 0.9352 0.7593 0.5707
> > 0-ply cubeful prune [expert]
> >
> > I'm on this system:
> > [oystein@jupiter ~]$ gnubg -t < terjebug.txt
> > GNU Backgammon 1.06.000  Dec 13 2017
> >
> > Can you supply which OS, version/build of GNU Backgammon (well that looks
> > like you got "GNU Backgammon 1.05.000  Nov 27 2016"). Can you also state
> > which match equity table you are 

Re: [Bug-gnubg] Possible evaluation bug

[Øystein Schønning-Johansen]

Really strange. However it is a heisenbug (of course). I cannot recreate
the bug on my system. (GNU Backgammon 1.06.000  Dec 13 2017, Arch Linux)

Here is how the same thing looks at my system:

 GNU Backgammon  Position ID: PgAAALYLBDMMAA

 Match ID   : cImmADAE
 +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
 | X  X |   |XO  X | OO  3 points
 |X |   |XO  X | OO
 |  |   | O| OO
 |  |   | O| OO
 |  |   | O| OO
v|  |BAR|  | 5 point match (Cube: 1)
 |  |   |  |
 |  |   |  |
 |  |   | X|
 |  |   | X  X  X  | Rolled 51
 |X |   | X  X  X  | 0 points
 +12-11-10--9--8--7---6--5--4--3--2--1-+ X: oystein


Cube analysis
2-ply cubeless equity -2.2349 (Money: -2.0391)
  0.0860 0. 0. - 0.9140 0.7715 0.4396
Cubeful equities:
1. No double   -2.0550
2. Double, pass+1.  (+3.0550)
3. Double, take-2.4258  (-0.3708)
Proper cube action: No double, take (10.8%)

Rolled 51 (-0.066):
*1. Cubeful 2-ply24/19 18/17  Eq.: -2.0615
   0.0892 0. 0. - 0.9108 0.7435 0.6447
2-ply cubeful prune [world class]
 2. Cubeful 2-ply13/7 Eq.: -2.1614 (-0.0999)
   0.0707 0. 0. - 0.9293 0.7800 0.6404
2-ply cubeful prune [world class]
 3. Cubeful 2-ply13/8 6/5 Eq.: -2.1766 (-0.1151)
   0.0701 0. 0. - 0.9299 0.7866 0.6634
2-ply cubeful prune [world class]
 4. Cubeful 2-ply18/13 6/5Eq.: -2.1963 (-0.1348)
   0.0603 0. 0. - 0.9397 0.7831 0.6918
2-ply cubeful prune [world class]
 5. Cubeful 2-ply18/17 18/13  Eq.: -2.2086 (-0.1470)
   0.0567 0. 0. - 0.9433 0.7815 0.7003
2-ply cubeful prune [world class]
 6. Cubeful 2-ply18/12Eq.: -2.2291 (-0.1676)
   0.0544 0. 0. - 0.9456 0.7887 0.6961
2-ply cubeful prune [world class]
 7. Cubeful 2-ply18/17 13/8   Eq.: -2.2481 (-0.1866)
   0.0524 0. 0. - 0.9476 0.7953 0.6954
2-ply cubeful prune [world class]
 8. Cubeful 2-ply18/17 7/2Eq.: -2.2952 (-0.2337)
   0.0476 0. 0. - 0.9524 0.8135 0.7098
2-ply cubeful prune [world class]
 9. Cubeful 0-ply24/19 6/5Eq.: -2.1277 (-0.0661)
   0.0653 0. 0. - 0.9347 0.7599 0.4187
0-ply cubeful prune [expert]
10. Cubeful 0-ply18/13 7/6Eq.: -2.1289 (-0.0674)
   0.0648 0. 0. - 0.9352 0.7593 0.5707
0-ply cubeful prune [expert]

I'm on this system:
[oystein@jupiter ~]$ gnubg -t < terjebug.txt
GNU Backgammon 1.06.000  Dec 13 2017

Can you supply which OS, version/build of GNU Backgammon (well that looks
like you got "GNU Backgammon 1.05.000  Nov 27 2016"). Can you also state
which match equity table you are using?

I have a theory that it get's the wrong answer because it calculates the
gammonvalue (or actually the backgammon value in this case) incorrectly.

can you append

show matchequitytable
show marketwindow
show gammonvalues

to your command file, and submit the output?

-Øystein


On Fri, Feb 16, 2018 at 5:43 PM, Terje Pedersen  wrote:

> Hi!
>
> I just ran into what looks like a gnu evaluation bug where gnu seems
> to suggest that I should try to avoid backgammon when a gammon will
> lose the match anyway. command file:
>
> set player 0 human
> new match 0
> set output rawboard off
> set xgid XGID=BBCA-AB-B--eB-:0:0:1:51:0:3:0:5:10
> move 24/19 18/17
> next
> previous
> analyze move
> show board
>
> $ ./gnubg.exe -t -c commands.txt
> GNU Backgammon 1.05.000  Nov 27 2016
> Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004 by Gary Wong.
> Copyright (C) 2015 by Gary Wong and the AUTHORS; for details type
> `show version'.
> This program comes with ABSOLUTELY NO WARRANTY; for details type `show
> warranty'.
> This is free software, and you are welcome to redistribute it under
> certain conditions; type `show copying' for details.
> Moves for gnubg must now be entered manually.
> A new session has been started.
> TTY boards will be given in ASCII.
> The dice have been set to 5 and 1.
>  GNU Backgammon  Position ID: PgAAALYLBDMMAA
>  Match ID   : cImmADAE
>  +13-14-15-16-17-18--19-20-21-22-23-24-+ O: gnubg
>  | X  X |   |XO  X | OO  3 points
>  |X |   |XO  X | OO
>  |  |   | O| OO
>  |  |   | O| OO
>  |  |   | O| OO
> v|  

Re: [Bug-gnubg] opening book?

[Øystein Schønning-Johansen]

ould be the best as when the game
> starts, at least if the book is not extra deep.)
> I don't know well how gnu works and whether storing the
> probabilities(cubeless or cubeful) would matter for how the program would
> play the next moves, do you mean to say to store the probabilities and then
> gnu uses them to make the moves? I meant that the book would have the moves
> so gnu would just make them(or maybe the gnu gui would make them). I think
> it would be nice to have the probabilities just so that one could see which
> they are out of curiosity using hint for the opening moves.
>
> 3. Or do you think it is wise to store the move (+roll) itself?
> -That's what I was thinking, if gnu can make moves from the probabilities
> of a rollout then store the probabilities.if gnu can't then store the moves
> for each opening roll
> I think you can have a book file that gnu reads so different books for
> different situations and then the user will load which one he wants... or
> maybe the user could make his own book choosing the moves for opening rolls
> if making a book that can handle all situations is difficult then you can
> make separate books
>
> 4.Another approach could be to pre-fill the evaluation hash table with
> rolled out values for some early game position, that may be a good approach.
> -I am not sure what this would do. Would it play the recommended moves
> from rollout? for all situations even?
>
> I have another suggestion:
> when gnu plays money games it assumes both players have infinite amount of
> money but this may not be the case
> an option to add how much money each player has and how much money
> corresponds to 1 point?
> obviously if I have 10 millions for the game and you have 3 millions the
> bet can't get more than 3 million. If we agree that each point corresponds
> to 1 million then after a double the bet gets to 2 millions and then the
> next double is to 3 millions so not a true double. then the cube is dead.
>
> One last suggestion I have is contempt. Maybe gnu should play/double
> differently when playing against weak opponents?
>
> I have some more questions.
> Can it handle the backgame well? I have heard that bots have trouble with
> backgame and in extreme situations may double in losing position. But is it
> still true for gnu now? Maybe strong players could beat it that way...
> what is different in the new version? is it any stronger?
>
> Anyways, thanks a lot for the reply and sorry if I am getting you tired
> with this reply...
> Looking forward to your next reply :)
> Please tell me if this text looks ok like the first I sent so if not I can
> send a separate email. Thanks again :)
>
> *Sent:* Wednesday, December 27, 2017 at 3:46 PM
> *From:* "Øystein Schønning-Johansen" 
> *To:* "Aristidis Aristarxopoulos" 
> *Subject:* Re: [Bug-gnubg] opening book?
> This is actually a good idea. I even think eXtreme Gammon uses some kind
> of opening book.
>
> There are some challenges and practical details though.
> What to store? should you store the cubeless probabilities after any
> opening move? Or do you think it is wise to store the move (+roll) itself?
> In case a book i storing the moves, the best move is actually depending on
> score, cube position, Crawford/pre-Crawford/post-Crawford etc. In that
> case we have to store the best move for each of the opening moves for each
> match score H doable...sure, but is it feasible?
>
> Another approach could be to pre-fill the evaluation hash table with
> rolled out values for some early game position, that may be a good approach.
>
> -Øystein
>
> On Tue, Dec 26, 2017 at 11:11 PM, Aristidis Aristarxopoulos <
> aristarxopou...@mail.com> wrote:
>
>> it seems that rollouts result in stronger moves.
>> Is it possible to make gnu play the opening moves and maybe the replies
>> of them(etc) from an opening book containing best moves from rollouts?
>>
>> ___
>> Bug-gnubg mailing list
>> Bug-gnubg@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>>
>
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] random dice generator? hahahaaa

[Øystein Schønning-Johansen]

I really don't think Tim is suggesting this scheme, and I think he
absolutely understands flaws of the scheme.

Now the interesting part: How can you construct a scientific test to prove
(or falsify) the postulate that a software uses such scheme?

-Øystein


On Fri, Aug 25, 2017 at 10:44 PM, Guido Flohr 
wrote:

>
> >
> > Along these lines, a friend of mine who also works in the gaming
> industry said that they often use dice that are generated in something like
> the following fashion: The computer internally creates a 36-card deck, each
> with one of the 36 possible dice rolls.  Then it deals out 18 cards from
> this deck to get 18 dice rolls.  Then it reshuffles and starts over to get
> the next 18 rolls.
>
> What you describe is a completely biased scheme. Your friend’s company
> maybe implemented it in order to avoid trolls complaining about them
> cheating?
>
> >
> > With this scheme, you never get (for example) three double 6's in a
> row.  Rarely does anyone notice anything strange about the dice, and if
> people are not told what is going on, there are typically far fewer
> complaints about the dice.
>
> A set of truly random real-world dice may produce subsequent double sixes
> until the heat death of the universe.  This is called randomness.
> Randomness has no memory, remember?
>
> >
> > I mentioned this concept on BGOnline once (a "hardcore" BG community)
> and predictably, they hated it.  So that's another piece of evidence to
> support what Rich Heimlich said.
>
> They predictably disapproved your improvements, yes.  This is called
> rationalism, also know as common sense.
>
> Others have already mentioned it: You can run gnubg with your own
> personally, manually rolled dice from your own backgammon set.  Try it out!
>
> You will continue losing!
>
> Tim, it’s 2017, and considering the state of the art of hard- and software
> it is absolutely normal that artificial intelligence beats human
> intelligence in games like backgammon or chess on a more than regular
> basis.  If you think that gnubg has to cheat for beating you, then become a
> professional backgammon player and be rich!
>
> You will be broke in no time at all!
>
> If you you are positive that gnubg cheats, why not install another
> software and troll their support forum for a change?
>
> Regards!
> —
> Oh, Lord, please let it rain brains!
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] random dice generator? hahahaaa

[Øystein Schønning-Johansen]

Yes! These threads are funny! I'm not sure if I'm feeding a troll or not.
Who knows?

Mario: How do you think it cheats? What have you done to verify and prove
that it actually does cheat?
Can you describe your scientific method for your verification?

If you have not done any scientific study of it's cheating abilities, have
you studied the source code?

Until you show me what you have found by your methods, I still believe that
it is not cheating.

best regards,
-Øystein


BTW: 19 years ago, Gary made a complaint form for these kind of issues:
http://www.bkgm.com/rgb/rgb.cgi?view+546

Please fill it out, and I promise we will look at your case.



On Fri, Aug 18, 2017 at 7:50 PM, David Bellows 
wrote:

> I want to think that comments like this in *2017* are just a troll
> repeating a very old meme, but is it? You cannot read revieww of a
> single *good* bg engine (neural net) that doesn't have these exact
> kinds of complaints even though it has been so thoroughly debunked
> over and over again. Just bizarre. I keep thinking there's some kind
> of paper to be written on the subject but given that bg is such a
> small niche community I'm guessing it won't happen.
>
> Oh well. Still fun to read these rage-quits.
>
> On Fri, Aug 18, 2017 at 10:26 AM, Michael Petch 
> wrote:
> >
> >
> > On 2017-08-18 07:53, Mario Bozeglav wrote:
> >>
> >> anyone serious BG player can see the random dice generator is a myth.
> >> anyone who plays GNU-BG with manual dice entry can see that the results
> >> are VERY different than when playing with the supposedly "random"
> generator.
> >>
> >
> > Thank for the compliment and feedback. Let us know what software you
> > settle on that gives you the dice you deserve! good luck in your games!
> >
> > ___
> > Bug-gnubg mailing list
> > Bug-gnubg@gnu.org
> > https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Edit mode change proposal

[Øystein Schønning-Johansen]

I also agree.
-Øystein

On 16 Aug 2017 10:21, "Ian Shaw"  wrote:

I agree that it makes sense to reset the dice and cube.

-- Ian

-Original Message-
From: Bug-gnubg [mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org]
On Behalf Of Philippe Michel
Sent: 14 August 2017 21:01
To: bug-gnubg@gnu.org
Subject: [Bug-gnubg] Edit mode change proposal

In edit mode, clicking on the bearoff-side tray clears the board and
clicking on the midpoint-side one resets it to the initial position. In
both case the dice and cube are left unchanged.

Wouldn't it make sense to reset the cube to 1 and centered and to clear the
dice ? If one is going to make such a radical change to the checkers setup,
it seems consistent to reset the dice and cube to a default value as well.

On the other hand, the score or match length wouldn't be reset since
studying a series of positions at some specific score is a likely use case.


___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

[Bug-gnubg] Threaded rollouts and RNGs

[Øystein Schønning-Johansen]

Hi!

It's a long time since I browsed the GNU Backgammon code now. :-)

The rollout code in GNU Backgammon is of course threaded. How is this
threaded actually? Is it threaded on each sample (aka each game). One
thread pr. game? Or one thread pr. evaluation? Or?

I just wrote a code that does a threaded MC simulation of a different
problem, and I noticed that I got significantly different results depending
on either I used threading or not. Funny thing, it didn't initially occur
to me, but of course I need one separate RNG instance for each thread.
Fixing that didn't only give me the right results of the simulation, but it
also improved the performance.

How about GNU Backgammon? Do you use one separate RNG instance for each
thread?

best regards,
-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] Bearoff database

[Øystein Schønning-Johansen]

Really strange!
I have built a one sided database using GMP with fractions with my own
piece of code. Since I use fractions from GMP there should be no rounding
error. Here are my numbers for position index 47:

Index: 47
 0: 0
 1: 0
 2: 1/18
 3: 445/648
 4: 5939/23328
 5: 73/23328

These numbers agrees to the numbers GNU Backgammon. Can it really play this
incorrectly? How does that happen?

-Øystein

On Sun, Jan 8, 2017 at 11:26 PM, Philippe Michel 
wrote:

> On Sun, 8 Jan 2017, isambard mews wrote:
>
> I tried to recreate the bearoff database and noticed some differences
>> which could be due to rounding, but already at position #47 there were some
>> significant differences. My workings for position 47 are given below. Have
>> I made a mistake in the calculation methodology?
>>
>
> Th discrepancy for position #47 is not a rounding error. The difference is
> 11/1296 more bearoffs in 2 rolls instead of 3 for gnubg.
>
> Interestingly, the average number of rolls to bear off is 2.21382 for you
> and 2.20528 for gnubg but the race4 software there :
> http://www.bkgm.com/rgb/rgb.cgi?view+788 that works recursively and plays
> perfectly claims that the average is 2.117155, so it looks like gnubg
> misplays a dice in one situation and you do in two.
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] License of training data on ftp.

[Øystein Schønning-Johansen]

Philippe wrote:
*I'm not sure how the could get something out of that in the current
format, with the key for each row being an obscure string. Would converting
this to a suitable format mean to something looking more like a backgammon
board ?*

Yes! We cannot upload just the boardIDs and the rollout result. We need to
convert the boardIDs to integers representing the number of checkers on
each point. (A simple task.) This could be uploaded as a plain csv file.
However... I'm not sure anyone will touch the dataset if that is the only
thing we do... Maybe we need to supply some other pieces of code to get the
Kagglers of the mark.

-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

[Bug-gnubg] License of training data on ftp.

[Øystein Schønning-Johansen]

Hi!

Do we consider the training data on the ftp site under any license, or do
we consider the training data public domain?

In case someone feel ownership to the data, please state your opinion.

Why I'm asking is because I guess we could try to upload the training
dataset to Kaggle, and maybe some of the experts there can take a shot at
it and maybe provide some insight. Good idea?

In case you think this is a good idea or don't mind in any way, I will
volunteer to convert the data to a standard format suitable for kagglers,
and write up an information document.

best regards,
-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] re FIBS

[Øystein Schønning-Johansen]

Really old thread, but I now found out what to do, and how to make Gibbon
working on my system. (Arch Linux). Maybe I will make a PKGBUILD file for
it later.

Gibbon is depending on gsettings-desktop-schemas. Your system probably have
a deb/rpm/pacman for that.

gibbon comes with a .xml file. bg.gibbon.gschema.xml. In my build this was
installed in /usr/local/share/glib-2.0/schemas/ (after 'make install')
Move this file to the directory containing the gsettings-desktop-schemas
.xml files. On my system they are in
/usr/share/glib-2.0/schemas/org.gnome.desktop.<...>.xml

So:
$ sudo mv /usr/local/share/glib-2.0/schemas/bg.gibbon.gschema.xml
/usr/share/glib-2.0/schemas/

then you have to "compile" these schemas.
$ sudo glib-compile-schemas --targetdir=/usr/share/glib-2.0/schemas/
/usr/share/glib-2.0/schemas/

YMMV.

After that gibbon starts up with no problem.

Good luck and thanks to Guido for his effort with this client.
-Øystein



On Mon, Jun 29, 2015 at 5:58 AM, Joseph Heled  wrote:

> I remember trying to use it unsuccessfully in the past.
>
> I got it to compile and it core dumped immediately
>
> ~/software/gibbon > src/gibbon --data-dir data
>
> (gibbon:32457): GLib-GIO-ERROR **: Settings schema 'bg.gibbon.data.recent'
> is not installed
>
> Trace/breakpoint trap
>
>
> On 29 June 2015 at 15:42, Michael Petch  wrote:
>
>>
>>
>> On 2015-06-28 9:30 PM, Joseph Heled wrote:
>> > Well, I would love it if the display engine could be bundled with a FIBS
>> > client sans the brainz.
>> >
>> > I stopped playing on FIBS for some years now due to lack of a Linux
>> client.
>> >
>>
>> One Linux client that is a work in progress is
>> http://savannah.nongnu.org/projects/gibbon/
>>
>> It is a GTK+ front end for FIBS. The primary developer is Guido Flohr.
>>
>> Guido has also developed bots for FIBS and wrote a FIBS server simulator
>> in Perl called BaldLies https://www.openhub.net/p/baldlies . The server
>> can interface with GNUbg using the external socket interface.
>>
>> Guido has also contributed to GNUbg. I've worked with him to fix some
>> problems in GNUbg that he encountered while doing development on his
>> products.
>>
>> --
>> Michael Petch
>> GNU Backgammon Maintainer / Developer
>> OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304
>>
>> ___
>> Bug-gnubg mailing list
>> Bug-gnubg@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] The little engine that could... Neural Network

[Øystein Schønning-Johansen]

Hi Robert!

I would love to see more development on the engine and the neural nets.
There are plenty of questions that could be asked when it comes to neural
net topology and training methods. However, from my point of view based on
my experience, I think the quality of a neural net evaluation actually
depends mostly on the training methods. I would of course be interesting to
see some research on deep learning (and maybe even recurrent neural net
topology) but I rather think effort is best used in the training methods.

(I would love to see it and I would love to be proved wrong!)

What about other techniques? MCTS? Or some kind of Markov decision Model?
Can we, base on today's available technology, rethink the whole idea? Huge
distributed databases or Distributed Hash Tables? Simplified evaluation
function combined with deeper search? The neural network idea is from the
1990's. Today we have much more technology that can provide us other
solutions. More memory, more storage, more distribution etc. Can we maybe
even take a step back, and consider other solutions than a neural nets
based solution?

best regards,
-Øystein


On Thu, Dec 17, 2015 at 3:08 PM, Robert Fontaine <
robert.fontain...@gmail.com> wrote:

> I scrolled back through the archives and it seems like it has been a
> while since gnubg got smarter.
>
> I have always suspected that the only thing holding gnubg back was an
> obscene amount of compute.
> A large single model should be able to outperform a bunch of essentially
> disconnected specialized ones, ala snowie.
> IFF the learning is deep enough and long enough.  Connecting backgames,
> and containment with early game
> play should/might/could happen.
>
> I've been building a little compute node in my basement,  a few xeon
> phis boards and a xeon 8 core processor and thinking
> that if the models were ported to openmp or openacc and tweaked a bit we
> might find a corporate sponsor with
> heavy metal to run them.   Intel is pushing the Xeon Phi architecture
> pretty heavily; could be they might lend us some
> cpu time.   Amazon, google, Baidu... bound to be someone with some
> cycles out there.
>
> Who is the neural networks guru in residence?  Where do I look for the
> docs,pseudo code,scribblings?
> I'm at the "Going to Take the Andrew Ng" course point in the project but
> I'm pretty good at assembling and porting things.
> Hopefully, by the time I have code familiarity I might actually have
> some current knowledge that can be applied to the real challenges.
>
> R , pynum, pymic have both been ported to run on the intel/mic libraries.
> Intels C/C++ compiler and vtune are available for students and the Phi's
> are cheap like borscht for establishing a development environment/sandbox.
>
> I've been scrounging hardware for the better part of a year at this
> point but I'm within spitting distance of booting and getting Centos
> installed.
> Would like to use this as a stepping stone to doing some Kaggle contests
> and generally getting my data analysis, machine learning chops.
>
> Thanks for any thoughts or suggestions,
> Robert
>
>
>
>
>
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

Re: [Bug-gnubg] setting output digits to more than 4.

[Øystein Schønning-Johansen]

Hehe!
You are partly right, Lucas! I do indeed adjust the number of digits
on a Windows installation of GNU Backgammon and that does, as you say
work perfectly. However on Linux is crashes! I have backtracked the
crash and it comes from function OutputEquityScale in format.c.

format.c lines 468ff:

extern char *
OutputEquityScale(const float r, const cubeinfo * pci, const cubeinfo
* pciBase, const int f)
{

static char sz[9];  /* <--- This buffer overflows! */

if (!pci->nMatchTo) {
if (f)
sprintf(sz, "%+*.*f", fOutputDigits + 4, fOutputDigits,
pci->nCube / pciBase->nCube * r);
else
sprintf(sz, "%*.*f", fOutputDigits + 4, fOutputDigits,
pci->nCube / pciBase->nCube * r);
} else {
..
.
.


So that's the problem. I guess the buffer is compiled bigger than the
9 bytes on Windows, and that it therefore works by luck. I guess the C
standards say that a such declaration should reserve at least N bytes.

Possible (naive) solution will be to increase the buffer size. Say set
it to 16 instead of 9.

Better solution: Rewrite the code such that the caller supplies the
buffer. I that way the function becomes re-entrant as well.

Best regards,
-Øystein


On Sun, May 3, 2015 at 10:33 AM, Lucas  wrote:
> I performed reveral rollouts with the digits set to 10
> and  my gnubg, also  1.05.000,   didn’t crash at all
>
> Lucas
>
> From: Øystein Schønning-Johansen
> Sent: Sunday, May 03, 2015 12:47 AM
> To: bug-gnubg@gnu.org
> Subject: [Bug-gnubg] setting output digits to more than 4.
>
> Hi,
>
> I just noticed a bug. When setting the number of outputs to 5 or more, the
> application crashes if I start a rollout. I think there is a buffer overflow
> somewhere.
>
> (No game) show version
> GNU Backgammon 1.05.000  Apr 25 2015
>
> Arch Linux from Arch/Community build!
>
> -Øystein
>
>
> 
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>
> ___
> Bug-gnubg mailing list
> Bug-gnubg@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>

___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg

[Bug-gnubg] setting output digits to more than 4.

[Øystein Schønning-Johansen]

Hi,

I just noticed a bug. When setting the number of outputs to 5 or more, the
application crashes if I start a rollout. I think there is a buffer
overflow somewhere.

(No game) show version
GNU Backgammon 1.05.000  Apr 25 2015

Arch Linux from Arch/Community build!

-Øystein
___
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg