Re: Alphazero / Deepmind backgammon project

[Joseph Heled]

Sounds good, Wayne!!

Personal opinion: Mochy will be lucky to win one match, ah-la Lee Sedol, if
matches are long enough :)

-Joseph


On Thu, 5 Dec 2019 at 19:35, Wayne Joseph  wrote:

> Hi Tim / Hi all,
>
> It might be worth reaching out to Jens Averkamp who I believe was in
> contact with a Dev team working this avenue.
>
> I also tried to get in touch with Demis, CEO of Deepmind (who almost
> certainly can play bg) a while ago, but I don't think my message completed
> its intended journey to him (via his P.A).
>
> After seeing what Deepmind has done to publicize Go and StarCraft, I was
> hoping the same might be possible for backgammon. Does anybody else fancy
> seeing Mochy beat Deepmind? ;)
>
> Good luck!
>
> -- Sent from my Android phone
>

Re: Alphazero / Deepmind backgammon project

[Wayne Joseph]

Hi Tim / Hi all,

It might be worth reaching out to Jens Averkamp who I believe was in
contact with a Dev team working this avenue.

I also tried to get in touch with Demis, CEO of Deepmind (who almost
certainly can play bg) a while ago, but I don't think my message completed
its intended journey to him (via his P.A).

After seeing what Deepmind has done to publicize Go and StarCraft, I was
hoping the same might be possible for backgammon. Does anybody else fancy
seeing Mochy beat Deepmind? ;)

Good luck!

-- Sent from my Android phone

Re: current development

[Joseph Heled]

I googled and found this:

   https://hal.inria.fr/hal-01521393/document

Seems very much like GNUBG, only a smaller net. No way to tell how it
compares to (say) GNUBG.

-Joseph

On Thu, 5 Dec 2019 at 11:12, 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

[Joseph Heled]

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

[Philippe Michel]

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

[Joseph Heled]

On Wed, 4 Dec 2019 at 20:59, Joseph Heled  wrote:

> An 8 "core" machine, i.e. fake intel count number
>
> $ grep -m1 '^model name' /proc/cpuinfo
> model name  : Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
>
> in debian rules file:
> SSE = --enable-simd=avx --enable-simd=sse2 --enable-threads -with-gtk
> --with-board3d --with-python
> compiled with gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0  -O3
>
> position id: 4NvBGECYr8ELAA:MBngIAAE
>
> rollout cube action:
>
>
So make this sse2.


> 8 threads: 93 seconds
> 4 threads: 100 secondsOn stock debian: 111 seconds
> 2 threads: 172 seconds
> 1 thread:   312
>

with avx,  8 threads: 81 seconds and 99 seconds with 4 threads, so maybe a
small improvement, maybe not.


> -Joseph
>
>
> On Wed, 4 Dec 2019 at 20:29, Ralph Corderoy  wrote:
> >
> > Hi Joseph,
> >
> > > What we really need is someone with access to some computing power
> > > (aka grid) to run a set of reference positions - 0-ply cube decisions
> > > vs 2-ply, and see what the difference is. That would give a hint as to
> > > what to do.
> >
> > How about reporting your
> >
> > grep -m1 '^model name' /proc/cpuinfo
> >
> > along with the stock Ubuntu package version's time on a reference
> > position when given 1, 2, ... threads.  And then you're self-compiled
> > version for comparison, noting what you changed in debian/rules.
> >
> > It would be a start, and also offer some precision so if something is
> > awry then others on the list may have data to judge by.
> >
> > --
> > Cheers, Ralph.
> >
>

Re: current development

[Russ Allbery]

Joseph Heled  writes:

> Thanks. will recompile. Also the other non-sse options should go
> somewhere else, but I don't know where they should go in the debian
> build process.

The override_dh_auto_configure target includes the invocation of
./configure.

-- 
Russ Allbery (ea...@eyrie.org) 

Re: current development

[Joseph Heled]

Thanks. will recompile. Also the other non-sse options should go somewhere
else, but I don't know where they should go in the debian build process.

On Thu, 5 Dec 2019 at 10:28, Philippe Michel 
wrote:

> On Wed, Dec 04, 2019 at 01:21:06PM +1300, Joseph Heled wrote:
>
> > Is that the right way to specify both?
> >
> > ./configure --enable-simd=avx --enable-simd=sse2
>
> It wasn't expected to specify both :-).
>
> I just checked what it does: the second option overrides the first one,
> so your example doesn't do what you hoped.
>
> Just use --enable-simd=yes, it will use avx if your computer supports it
> (plus some sse in places where there is no avx implementation), else
> sse2.
>

Re: current development

[Philippe Michel]

On Wed, Dec 04, 2019 at 01:21:06PM +1300, Joseph Heled wrote:

> Is that the right way to specify both?
> 
> ./configure --enable-simd=avx --enable-simd=sse2

It wasn't expected to specify both :-).

I just checked what it does: the second option overrides the first one, 
so your example doesn't do what you hoped.

Just use --enable-simd=yes, it will use avx if your computer supports it 
(plus some sse in places where there is no avx implementation), else 
sse2.

Re: current development

[Philippe Michel]

On Tue, Dec 03, 2019 at 03:51:12PM -0800, Russ Allbery wrote:
>
> Philippe Michel  writes:
> 
> > Reasonably recent versions of gcc and clang have a feature (ifuncs) that
> > should allow to to this in one single binary. I don't know how onerous
> > it would be at package building stage, but I think a few parts of Linux,
> > for instance glibc, use that feature, so at least it wouldn't be unknown
> > territory.
> 
> Oh, interesting.  Is this something that I can just enable with a compiler
> flag, or does it need code support in gnubg?

This would be mostly in gnubg's code. Maybe something would be needed at 
configure stage as well.

The post below shows a minimal example of how this is used:
https://gcc.gnu.org/ml/gcc-help/2012-03/msg00209.html

Re: current development

[Joseph Heled]

Ralph was not cc'ed

Subject: Re: current development
From: Joseph Heled 
To: Ingo Macherius 
Cc: "bug-gnubg@gnu.org" 
Content-Type: multipart/alternative; boundary="e96d5e0598e6d365"

On Thu, 5 Dec 2019 at 09:44, Ralph Corderoy  wrote:

> Joseph, please desist from CC-ing me.
>
> --
> Cheers, Ralph.
>

Re: current development

[Joseph Heled]

What is the matter with you people? bug-gnubg is synonym with dev-gnubg.

Perhaps it is time for me to stop being involved with GNUBG. Does not seem
people here are interested in doing anything constructive. If this is not
the case, prove me wrong.

-Joseph

On Thu, 5 Dec 2019 at 08:57, Ingo Macherius  wrote:

> This is not a bug. While individual members of the gnubg team always had
> setups for dependency management under various IDEs and OSes, there
> never was a satisfying solution in the repository. There was a Linux
> package management HOWTO, but it's went away with the rest of the web
> pages. And no, automake and it's cryptic error message not really
> qualifies as a dependency management system. I'm a Java guy and used to
> tool based solutions such as maven or gradle. Picking and adding
> something similar suiteable for C, ideally something which works on all
> major OSes, would greatly improve the confusion you and everybody else
> starting to work with the code has to go through.
>
> Ingo
>
> Am 04.12.19 um 19:00 schrieb Joseph Heled:
> > And good riddance. This list is called bug-gnubg.
> >
> > -Joseph
> >
> > On Thu, 5 Dec 2019 at 06:59, Ralph Corderoy 
> wrote:
> >> Hi Joseph,
> >>
> >>> I was intentionally rude because I thought his original post was
> >>> inappropriate.
> >> How childish.  We put up with your many posts detailing your failure to
> >> compile from source when a quick Google would have led to the method of
> >> using the package manager to install the build dependencies.  No one was
> >> rude.  You got civil help.
> >>
> >> I've no time for such antics.  This list has always been polite in my
> >> experience.  I'm unsubscribing.
> >>
> >> --
> >> Cheers, Ralph.
> >>
>
>

Re: current development

[Myshkin LeVine]

Hi Jon,
   Perhaps you could also include build instructions for the Mac in 
addition to Linux and Windows. I figured out how to fulfill the cglm 
dependency, but I think many Mac users could not. I do not see cglm in 
MacPorts, but it does have a formula for those Mac users who like Homebrew. The 
3D board seems to be working fine for me, with the exception that clicking on 
the dice to end my turn has no effect, and I must instead use use Control-F.

Myshkin LeVine


On Dec 4, 2019, at 1:56 PM, Superfly Jon wrote:

> My changes are still under development, the dependency with cglm will be 
> resolved in due course.  I'll update the "INSTALL" file with more detailed 
> how-to build instructions for linux and windows shortly.
> 
> Jon
> 

Re: current development

[Joseph Heled]

The main difference, if I understand correctly (and I know very little
here) is to bootstrap from the ground. That is, no pre-computed inputs. and
let the network figure it out by self play.

We have a great test case in that we can start with just racing.

That said, I think we will need a net for each match score, since cubeless
-> cubeful is where things get messy.

Also, given that 0-ply rollouts are relatively fast, when playing against a
human - if you can wait a second or two, you can play using cubeful 0-ply.
Testing how good this is will be problematic.

-Joseph


On Thu, 5 Dec 2019 at 09:23, Øystein Schønning-Johansen 
wrote:

> 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]

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

[Timothy Y. Chow]

On Thu, 5 Dec 2019, Joseph Heled wrote:
To do a "AlphaGammon" would require, at a minimum, one or more googlers 
who have worked on AlphaGo or AlphaChess and are willing to contribute 
time and resources.


The situation is rosier than that, in my opinion.  In chess, for example, 
Leela Chess Zero and Fat Fritz are approaching AlphaZero in chess 
strength, if they have not already attained it.  This demonstrates that 
the ideas behind AlphaZero have percolated into the wider machine learning 
community and are not locked behind Google's proprietary closed doors. 
If we're not already at the point where AlphaGammon could be someone's 
graduate thesis, then we're very close to it.


Tim

Re: current development

[Ingo Macherius]

This is not a bug. While individual members of the gnubg team always had 
setups for dependency management under various IDEs and OSes, there 
never was a satisfying solution in the repository. There was a Linux 
package management HOWTO, but it's went away with the rest of the web 
pages. And no, automake and it's cryptic error message not really 
qualifies as a dependency management system. I'm a Java guy and used to 
tool based solutions such as maven or gradle. Picking and adding 
something similar suiteable for C, ideally something which works on all 
major OSes, would greatly improve the confusion you and everybody else 
starting to work with the code has to go through.


Ingo

Am 04.12.19 um 19:00 schrieb Joseph Heled:

And good riddance. This list is called bug-gnubg.

-Joseph

On Thu, 5 Dec 2019 at 06:59, Ralph Corderoy  wrote:

Hi Joseph,


I was intentionally rude because I thought his original post was
inappropriate.

How childish.  We put up with your many posts detailing your failure to
compile from source when a quick Google would have led to the method of
using the package manager to install the build dependencies.  No one was
rude.  You got civil help.

I've no time for such antics.  This list has always been polite in my
experience.  I'm unsubscribing.

--
Cheers, Ralph.

Re: current development

[Myshkin LeVine]

Joseph,
  What you are seeing is not a deterioration, but rather a new 
dependency that was recently added by Jon Kinsey. I ran into the same error you 
did when I was compiling a new version of GnuBG for myself. I searched for the 
cglm library, and I found it here:
   
https://github.com/recp/cglm

It is described as the "Highly Optimized Graphics Math (glm) for C." Its 
documentation is located at:

https://cglm.readthedocs.io/en/latest/

After compiling and installing cglm, the error will go away, and the build 
should complete without further issue.

-Myshkin LeVine


On Wed, 3 Dec 2019 at 19:43, Joseph Heled  wrote:

> Now stuck with this unknown library:
> 
> ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
> #include 
> ^~~
> compilation terminated.
> 
> 
> I did not expect gnubg to deteriorate that much. Pretty sad.
> 
> -Joseph

Re: current development

[Joseph Heled]

I think that the idea that backgammon is "solved in any way or form" is
ridiculous, and part of the Dunning Kruger effect.
Even racing is not "solved" in any meaningful way when you have cube
actions to consider.

Right now I am writing a book that I hope will help to dispel this notion.
It is not about BG but much simpler race games, ones that can actually be
solved.

To do a "AlphaGammon" would require, at a minimum, one or more googlers who
have worked on AlphaGo or AlphaChess and are willing to contribute time and
resources.
That is my personal opinion, that is, I would not go into such an endeavor
without it.

-Joseph


On Thu, 5 Dec 2019 at 08:08, Timothy Y. Chow 
wrote:

> On Thu, 5 Dec 2019, Joseph Heled wrote:
> > 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.
>
> Well, other people may have other books.
>
> 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.
>
> Some years ago, Paul Weaver created a "backgame quiz" with some
> interesting backgame problems.  Most were not what I would call
> superbackgames, though a couple were getting close.  The only rollouts I
> ever saw anyone else do were with standard rollout settings.  I have been
> running (eXtreme Gammon) rollouts with much stronger settings, and in at
> least one case I've gotten some noticeably different results.  I think
> this is interesting.  I also don't fully trust even the strong rollout
> settings that I'm currently using, and would welcome a bot that I would be
> more willing to trust.
>
> This thread was asking about whether there is any current development of
> GNU.  If someone poses that question, and nobody even mentions that
> "AlphaGammon" would be of interest, then the impression can be created
> that nobody cares about that.  I want to combat that impression.  So just
> because I'm not prepared to invest in the supply side of the equation
> doesn't mean that it's of no value to exhibit the existence of the demand
> side of the equation.  In my book, at least.
>
> Tim
>
>

Re: current development

[Joseph Heled]

That would certainly help. Thanks, Jon.

On Thu, 5 Dec 2019 at 07:56, Superfly Jon  wrote:

> My changes are still under development, the dependency with cglm will be
> resolved in due course.  I'll update the "INSTALL" file with more detailed
> how-to build instructions for linux and windows shortly.
>
> Jon
>
> On Wed, 4 Dec 2019 at 17:40, Joseph Heled  wrote:
>
>> It is a horrible, terrible dependency, since it can't be installed
>> with a 'apt-get install'. I would eliminate it if I had the time.
>>
>> -Joseph
>>
>> On Thu, 5 Dec 2019 at 05:02, Myshkin LeVine  wrote:
>> >
>> > Joseph,
>> >   What you are seeing is not a deterioration, but rather a new
>> dependency that was recently added by Jon Kinsey. I ran into the same error
>> you did when I was compiling a new version of GnuBG for myself. I searched
>> for the cglm library, and I found it here:
>> >
>> > https://github.com/recp/cglm
>> >
>> > It is described as the "Highly Optimized Graphics Math (glm) for C."
>> Its documentation is located at:
>> >
>> > https://cglm.readthedocs.io/en/latest/
>> >
>> > After compiling and installing cglm, the error will go away, and the
>> build should complete without further issue.
>> >
>> > -Myshkin LeVine
>> >
>> >
>> > On Wed, 3 Dec 2019 at 19:43, Joseph Heled  wrote:
>> >
>> > > Now stuck with this unknown library:
>> > >
>> > > ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
>> > > #include 
>> > > ^~~
>> > > compilation terminated.
>> > >
>> > >
>> > > I did not expect gnubg to deteriorate that much. Pretty sad.
>> > >
>> > > -Joseph
>>
>>

Re: current development

[Timothy Y. Chow]

On Thu, 5 Dec 2019, Joseph Heled wrote:
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.


Well, other people may have other books.

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.


Some years ago, Paul Weaver created a "backgame quiz" with some 
interesting backgame problems.  Most were not what I would call 
superbackgames, though a couple were getting close.  The only rollouts I 
ever saw anyone else do were with standard rollout settings.  I have been 
running (eXtreme Gammon) rollouts with much stronger settings, and in at 
least one case I've gotten some noticeably different results.  I think 
this is interesting.  I also don't fully trust even the strong rollout 
settings that I'm currently using, and would welcome a bot that I would be 
more willing to trust.


This thread was asking about whether there is any current development of 
GNU.  If someone poses that question, and nobody even mentions that 
"AlphaGammon" would be of interest, then the impression can be created 
that nobody cares about that.  I want to combat that impression.  So just 
because I'm not prepared to invest in the supply side of the equation 
doesn't mean that it's of no value to exhibit the existence of the demand 
side of the equation.  In my book, at least.


Tim

Re: current development

[Superfly Jon]

My changes are still under development, the dependency with cglm will be
resolved in due course.  I'll update the "INSTALL" file with more detailed
how-to build instructions for linux and windows shortly.

Jon

On Wed, 4 Dec 2019 at 17:40, Joseph Heled  wrote:

> It is a horrible, terrible dependency, since it can't be installed
> with a 'apt-get install'. I would eliminate it if I had the time.
>
> -Joseph
>
> On Thu, 5 Dec 2019 at 05:02, Myshkin LeVine  wrote:
> >
> > Joseph,
> >   What you are seeing is not a deterioration, but rather a new
> dependency that was recently added by Jon Kinsey. I ran into the same error
> you did when I was compiling a new version of GnuBG for myself. I searched
> for the cglm library, and I found it here:
> >
> > https://github.com/recp/cglm
> >
> > It is described as the "Highly Optimized Graphics Math (glm) for C." Its
> documentation is located at:
> >
> > https://cglm.readthedocs.io/en/latest/
> >
> > After compiling and installing cglm, the error will go away, and the
> build should complete without further issue.
> >
> > -Myshkin LeVine
> >
> >
> > On Wed, 3 Dec 2019 at 19:43, Joseph Heled  wrote:
> >
> > > Now stuck with this unknown library:
> > >
> > > ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
> > > #include 
> > > ^~~
> > > compilation terminated.
> > >
> > >
> > > I did not expect gnubg to deteriorate that much. Pretty sad.
> > >
> > > -Joseph
>
>

Re: current development

[Joseph Heled]

Thanks, Victor.   We would probably need way more to be effective :)

-Joseph


On Thu, 5 Dec 2019 at 07:45, Victor Fernandes  wrote:

> Sorry... i have nothing of this... i would like to help with a VPS.. but
> is a 4 gb ram i7 cpu
>
> TYVM
>
> Em qua., 4 de dez. de 2019 às 15:43, Joseph Heled 
> escreveu:
>
>>
>>
>> On Thu, 5 Dec 2019 at 07:38, Victor Fernandes  wrote:
>>
>>> Hi How r u???
>>>
>>> What kind of computing power do we need? SOmething like a VPS works?
>>>
>>
>> Anything with a unixy shell (bash etc) and ability to compile C++ code
>> and run python 3 would do. As long as it has enough cpu power of course.
>>
>> Can you provide more details?
>>
>> Thanks, Joseph
>>
>>
>>>
>>> TYVM
>>>
>>> Em qua., 4 de dez. de 2019 às 15:34, Joseph Heled 
>>> escreveu:
>>>
 Back to topic.

 I have been out of the loop for many years. I might be able to do a
 little more now, but only if there are someone(s) who would like to
 collaborate, specifically someone(s) with access to the computing power
 needed.

 So, if you are willing to actively participate in improving the
 rollouts situations, and have the juice, get back to me on this list.

 -Joseph


 On Thu, 5 Dec 2019 at 02:18, Superfly Jon  wrote:

> Sorry Joseph, the current slightly dodgy code is my fault.  I've been
> changing the 3d drawing code to support modern openGL, which is all GTK3
> supports.  If we were using something like git rather than cvs, I'd
> definitely be doing the changes in a branch.
>
> So the code is currently changing, although I'm not adding anything
> new at the moment.  it's been about 10 years since I looked at it as well!
>
> Jon
>
> On Wed, 4 Dec 2019 at 00:52, Joseph Heled  wrote:
>
>> So, there is a shapes.inc in the directory. Unacceptable!! case is
>> unimportant only in Bill's world
>>
>> Now stuck with this unknown library:
>>
>> ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
>> #include 
>>  ^~~
>> compilation terminated.
>>
>>
>> I did not expect gnubg to deteriorate that much. Pretty sad.
>>
>> -Joseph
>>
>> On Wed, 4 Dec 2019 at 13:24, Joseph Heled  wrote:
>> >
>> > It is the usual hell of installing all missing dev packages and
>> > getting configure to complete.
>> >
>> > But this is unexpected:  DrawOGL.c:25:10: fatal error: Shapes.inc:
>> No
>> > such file or directory
>> >
>> > make[2]: Entering directory
>> '/home/joseph/Projects/gnubg/gnubg/board3d'
>> > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
>> > -I. -I..  -I./.. -I./../lib -DLOCALEDIR=\"/usr/local/share/local
>> > e\" -DAC_DATADIR='"/usr/local/share"'
>> > -DAC_PKGDATADIR=='"/usr/local/share/gnubg"' -I/usr/include/freetype2
>> > -I/usr/include/libpng16 -
>> > pthread -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
>> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/i
>> > nclude/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
>> > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
>> > -I/usr/include/li
>> > bmount -I/usr/include/blkid -I/usr/include/pango-1.0
>> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
>> > -I/usr/include/fribidi -I/usr/
>> > include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>> > -I/usr/include/uuid -I/usr/include/freetype2
>> -I/usr/include/libpng16 -
>> > pthread -I/usr/include/gtkglext-1.0
>> > -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
>> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-
>> > gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-u
>> > nix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0
>> > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
>> > -I/usr/inc
>> > lude/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid
>> > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pan
>> > go-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0
>> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
>> > -I/usr/includ
>> > e/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm
>> -ffast-math
>> > -O3 -g -O2 -DG_DISABLE_ASSERT  -MT libboard3d_la-DrawOGL.lo -
>> > MD -MP -MF .deps/libboard3d_la-DrawOGL.Tpo -c -o
>> > libboard3d_la-DrawOGL.lo `test -f 'DrawOGL.c' || echo './'`DrawOGL.c
>> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../lib
>> > -DLOCALEDIR=\"/usr/local/share/locale\" -DAC_DATADIR=\"/usr/local/
>> > share\" -DAC_PKGDATADIR==\"/usr/local/share/gnubg\"
>> > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
>> > -I/usr/include/gtk-2.0
>> >

Re: current development

[Joseph Heled]

On Thu, 5 Dec 2019 at 07:38, Victor Fernandes  wrote:

> Hi How r u???
>
> What kind of computing power do we need? SOmething like a VPS works?
>

Anything with a unixy shell (bash etc) and ability to compile C++ code and
run python 3 would do. As long as it has enough cpu power of course.

Can you provide more details?

Thanks, Joseph


>
> TYVM
>
> Em qua., 4 de dez. de 2019 às 15:34, Joseph Heled 
> escreveu:
>
>> Back to topic.
>>
>> I have been out of the loop for many years. I might be able to do a
>> little more now, but only if there are someone(s) who would like to
>> collaborate, specifically someone(s) with access to the computing power
>> needed.
>>
>> So, if you are willing to actively participate in improving the rollouts
>> situations, and have the juice, get back to me on this list.
>>
>> -Joseph
>>
>>
>> On Thu, 5 Dec 2019 at 02:18, Superfly Jon  wrote:
>>
>>> Sorry Joseph, the current slightly dodgy code is my fault.  I've been
>>> changing the 3d drawing code to support modern openGL, which is all GTK3
>>> supports.  If we were using something like git rather than cvs, I'd
>>> definitely be doing the changes in a branch.
>>>
>>> So the code is currently changing, although I'm not adding anything new
>>> at the moment.  it's been about 10 years since I looked at it as well!
>>>
>>> Jon
>>>
>>> On Wed, 4 Dec 2019 at 00:52, Joseph Heled  wrote:
>>>
 So, there is a shapes.inc in the directory. Unacceptable!! case is
 unimportant only in Bill's world

 Now stuck with this unknown library:

 ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
 #include 
  ^~~
 compilation terminated.


 I did not expect gnubg to deteriorate that much. Pretty sad.

 -Joseph

 On Wed, 4 Dec 2019 at 13:24, Joseph Heled  wrote:
 >
 > It is the usual hell of installing all missing dev packages and
 > getting configure to complete.
 >
 > But this is unexpected:  DrawOGL.c:25:10: fatal error: Shapes.inc: No
 > such file or directory
 >
 > make[2]: Entering directory
 '/home/joseph/Projects/gnubg/gnubg/board3d'
 > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
 > -I. -I..  -I./.. -I./../lib -DLOCALEDIR=\"/usr/local/share/local
 > e\" -DAC_DATADIR='"/usr/local/share"'
 > -DAC_PKGDATADIR=='"/usr/local/share/gnubg"' -I/usr/include/freetype2
 > -I/usr/include/libpng16 -
 > pthread -I/usr/include/gtk-2.0
 > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
 > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/i
 > nclude/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
 > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
 > -I/usr/include/li
 > bmount -I/usr/include/blkid -I/usr/include/pango-1.0
 > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
 > -I/usr/include/fribidi -I/usr/
 > include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
 > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -
 > pthread -I/usr/include/gtkglext-1.0
 > -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
 > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-
 > gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0
 > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-u
 > nix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0
 > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
 > -I/usr/inc
 > lude/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid
 > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pan
 > go-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0
 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
 > -I/usr/includ
 > e/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm  -ffast-math
 > -O3 -g -O2 -DG_DISABLE_ASSERT  -MT libboard3d_la-DrawOGL.lo -
 > MD -MP -MF .deps/libboard3d_la-DrawOGL.Tpo -c -o
 > libboard3d_la-DrawOGL.lo `test -f 'DrawOGL.c' || echo './'`DrawOGL.c
 > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../lib
 > -DLOCALEDIR=\"/usr/local/share/locale\" -DAC_DATADIR=\"/usr/local/
 > share\" -DAC_PKGDATADIR==\"/usr/local/share/gnubg\"
 > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
 > -I/usr/include/gtk-2.0
 > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
 > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo
 > -I/usr/include/pango-1.0 -I/usr/includ
 > e/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
 > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount
 > -I/usr/include/blkid -I
 > /usr/include/pango-1.0 -I/usr/include/harfbuzz
 > -I/usr/include/pango-1.0 -I/usr/include/fribidi
 > -I/usr/include/glib-2.0 -I/usr/lib/x8
 > 6_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
 > -I/usr/include/freetype2 -I/usr/include/libpng16 

Re: current development

[Joseph Heled]

Back to topic.

I have been out of the loop for many years. I might be able to do a little
more now, but only if there are someone(s) who would like to collaborate,
specifically someone(s) with access to the computing power needed.

So, if you are willing to actively participate in improving the rollouts
situations, and have the juice, get back to me on this list.

-Joseph


On Thu, 5 Dec 2019 at 02:18, Superfly Jon  wrote:

> Sorry Joseph, the current slightly dodgy code is my fault.  I've been
> changing the 3d drawing code to support modern openGL, which is all GTK3
> supports.  If we were using something like git rather than cvs, I'd
> definitely be doing the changes in a branch.
>
> So the code is currently changing, although I'm not adding anything new at
> the moment.  it's been about 10 years since I looked at it as well!
>
> Jon
>
> On Wed, 4 Dec 2019 at 00:52, Joseph Heled  wrote:
>
>> So, there is a shapes.inc in the directory. Unacceptable!! case is
>> unimportant only in Bill's world
>>
>> Now stuck with this unknown library:
>>
>> ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
>> #include 
>>  ^~~
>> compilation terminated.
>>
>>
>> I did not expect gnubg to deteriorate that much. Pretty sad.
>>
>> -Joseph
>>
>> On Wed, 4 Dec 2019 at 13:24, Joseph Heled  wrote:
>> >
>> > It is the usual hell of installing all missing dev packages and
>> > getting configure to complete.
>> >
>> > But this is unexpected:  DrawOGL.c:25:10: fatal error: Shapes.inc: No
>> > such file or directory
>> >
>> > make[2]: Entering directory '/home/joseph/Projects/gnubg/gnubg/board3d'
>> > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
>> > -I. -I..  -I./.. -I./../lib -DLOCALEDIR=\"/usr/local/share/local
>> > e\" -DAC_DATADIR='"/usr/local/share"'
>> > -DAC_PKGDATADIR=='"/usr/local/share/gnubg"' -I/usr/include/freetype2
>> > -I/usr/include/libpng16 -
>> > pthread -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
>> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/i
>> > nclude/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
>> > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
>> > -I/usr/include/li
>> > bmount -I/usr/include/blkid -I/usr/include/pango-1.0
>> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
>> > -I/usr/include/fribidi -I/usr/
>> > include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
>> > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -
>> > pthread -I/usr/include/gtkglext-1.0
>> > -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
>> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-
>> > gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-u
>> > nix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0
>> > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
>> > -I/usr/inc
>> > lude/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid
>> > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pan
>> > go-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0
>> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
>> > -I/usr/includ
>> > e/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm  -ffast-math
>> > -O3 -g -O2 -DG_DISABLE_ASSERT  -MT libboard3d_la-DrawOGL.lo -
>> > MD -MP -MF .deps/libboard3d_la-DrawOGL.Tpo -c -o
>> > libboard3d_la-DrawOGL.lo `test -f 'DrawOGL.c' || echo './'`DrawOGL.c
>> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../lib
>> > -DLOCALEDIR=\"/usr/local/share/locale\" -DAC_DATADIR=\"/usr/local/
>> > share\" -DAC_PKGDATADIR==\"/usr/local/share/gnubg\"
>> > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
>> > -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
>> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo
>> > -I/usr/include/pango-1.0 -I/usr/includ
>> > e/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
>> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount
>> > -I/usr/include/blkid -I
>> > /usr/include/pango-1.0 -I/usr/include/harfbuzz
>> > -I/usr/include/pango-1.0 -I/usr/include/fribidi
>> > -I/usr/include/glib-2.0 -I/usr/lib/x8
>> > 6_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
>> > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
>> > -I/usr/include/gtkglex
>> > t-1.0 -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
>> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
>> > -I/usr/inc
>> > lude/pango-1.0 -I/usr/include/gtk-2.0
>> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
>> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -
>> > I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
>> > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/inc
>> > lude/libmount -I/usr/include/blkid -I/usr/include/pango-1.0
>> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
>> > -I/usr/include/fribidi
>> > -I/usr/i

Re: current development

[Joseph Heled]

And good riddance. This list is called bug-gnubg.

-Joseph

On Thu, 5 Dec 2019 at 06:59, Ralph Corderoy  wrote:
>
> Hi Joseph,
>
> > I was intentionally rude because I thought his original post was
> > inappropriate.
>
> How childish.  We put up with your many posts detailing your failure to
> compile from source when a quick Google would have led to the method of
> using the package manager to install the build dependencies.  No one was
> rude.  You got civil help.
>
> I've no time for such antics.  This list has always been polite in my
> experience.  I'm unsubscribing.
>
> --
> Cheers, Ralph.
>

Re: current development

[Ralph Corderoy]

Hi Joseph,

> I was intentionally rude because I thought his original post was
> inappropriate.

How childish.  We put up with your many posts detailing your failure to
compile from source when a quick Google would have led to the method of
using the package manager to install the build dependencies.  No one was
rude.  You got civil help.

I've no time for such antics.  This list has always been polite in my
experience.  I'm unsubscribing.

-- 
Cheers, Ralph.

Re: current development

[Joseph Heled]

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

[Ralph Corderoy]

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

[Joseph Heled]

It is a horrible, terrible dependency, since it can't be installed
with a 'apt-get install'. I would eliminate it if I had the time.

-Joseph

On Thu, 5 Dec 2019 at 05:02, Myshkin LeVine  wrote:
>
> Joseph,
>   What you are seeing is not a deterioration, but rather a new 
> dependency that was recently added by Jon Kinsey. I ran into the same error 
> you did when I was compiling a new version of GnuBG for myself. I searched 
> for the cglm library, and I found it here:
>
> https://github.com/recp/cglm
>
> It is described as the "Highly Optimized Graphics Math (glm) for C." Its 
> documentation is located at:
>
> https://cglm.readthedocs.io/en/latest/
>
> After compiling and installing cglm, the error will go away, and the build 
> should complete without further issue.
>
> -Myshkin LeVine
>
>
> On Wed, 3 Dec 2019 at 19:43, Joseph Heled  wrote:
>
> > Now stuck with this unknown library:
> >
> > ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
> > #include 
> > ^~~
> > compilation terminated.
> >
> >
> > I did not expect gnubg to deteriorate that much. Pretty sad.
> >
> > -Joseph

Re: current development

[Joseph Heled]

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.

-Joseph

On Thu, 5 Dec 2019 at 05:32, Timothy Y. Chow  wrote:
>
> > On Wed, 4 Dec 2019 at 16:19, I wrote:
> >> It's surely occurred to some people that it would be interesting to see
> >> what would happen if one were to apply "AlphaZero methods" to
> >> backgammon.
>
> On Wed, 4 Dec 2019, Joseph Heled wrote:
> > Well, are you?
>
> Not any time soon.
>
> Tim
>

Re: current development

[Timothy Y. Chow]

On Wed, 4 Dec 2019 at 16:19, I wrote:
It's surely occurred to some people that it would be interesting to see 
what would happen if one were to apply "AlphaZero methods" to 
backgammon.


On Wed, 4 Dec 2019, Joseph Heled wrote:

Well, are you?


Not any time soon.

Tim

Re: current development

[Superfly Jon]

Sorry Joseph, the current slightly dodgy code is my fault.  I've been
changing the 3d drawing code to support modern openGL, which is all GTK3
supports.  If we were using something like git rather than cvs, I'd
definitely be doing the changes in a branch.

So the code is currently changing, although I'm not adding anything new at
the moment.  it's been about 10 years since I looked at it as well!

Jon

On Wed, 4 Dec 2019 at 00:52, Joseph Heled  wrote:

> So, there is a shapes.inc in the directory. Unacceptable!! case is
> unimportant only in Bill's world
>
> Now stuck with this unknown library:
>
> ShimOGL.c:5:10: fatal error: cglm\affine.h: No such file or directory
> #include 
>  ^~~
> compilation terminated.
>
>
> I did not expect gnubg to deteriorate that much. Pretty sad.
>
> -Joseph
>
> On Wed, 4 Dec 2019 at 13:24, Joseph Heled  wrote:
> >
> > It is the usual hell of installing all missing dev packages and
> > getting configure to complete.
> >
> > But this is unexpected:  DrawOGL.c:25:10: fatal error: Shapes.inc: No
> > such file or directory
> >
> > make[2]: Entering directory '/home/joseph/Projects/gnubg/gnubg/board3d'
> > /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
> > -I. -I..  -I./.. -I./../lib -DLOCALEDIR=\"/usr/local/share/local
> > e\" -DAC_DATADIR='"/usr/local/share"'
> > -DAC_PKGDATADIR=='"/usr/local/share/gnubg"' -I/usr/include/freetype2
> > -I/usr/include/libpng16 -
> > pthread -I/usr/include/gtk-2.0
> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/i
> > nclude/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
> > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
> > -I/usr/include/li
> > bmount -I/usr/include/blkid -I/usr/include/pango-1.0
> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
> > -I/usr/include/fribidi -I/usr/
> > include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -
> > pthread -I/usr/include/gtkglext-1.0
> > -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-
> > gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0
> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-u
> > nix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0
> > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
> > -I/usr/inc
> > lude/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid
> > -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pan
> > go-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
> > -I/usr/includ
> > e/freetype2 -I/usr/include/libpng16 -I/usr/include/libdrm  -ffast-math
> > -O3 -g -O2 -DG_DISABLE_ASSERT  -MT libboard3d_la-DrawOGL.lo -
> > MD -MP -MF .deps/libboard3d_la-DrawOGL.Tpo -c -o
> > libboard3d_la-DrawOGL.lo `test -f 'DrawOGL.c' || echo './'`DrawOGL.c
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -I./../lib
> > -DLOCALEDIR=\"/usr/local/share/locale\" -DAC_DATADIR=\"/usr/local/
> > share\" -DAC_PKGDATADIR==\"/usr/local/share/gnubg\"
> > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
> > -I/usr/include/gtk-2.0
> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo
> > -I/usr/include/pango-1.0 -I/usr/includ
> > e/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount
> > -I/usr/include/blkid -I
> > /usr/include/pango-1.0 -I/usr/include/harfbuzz
> > -I/usr/include/pango-1.0 -I/usr/include/fribidi
> > -I/usr/include/glib-2.0 -I/usr/lib/x8
> > 6_64-linux-gnu/glib-2.0/include -I/usr/include/uuid
> > -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread
> > -I/usr/include/gtkglex
> > t-1.0 -I/usr/lib/x86_64-linux-gnu/gtkglext-1.0/include
> > -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
> > -I/usr/inc
> > lude/pango-1.0 -I/usr/include/gtk-2.0
> > -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
> > -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -
> > I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
> > -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/inc
> > lude/libmount -I/usr/include/blkid -I/usr/include/pango-1.0
> > -I/usr/include/harfbuzz -I/usr/include/pango-1.0
> > -I/usr/include/fribidi
> > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
> > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/lib
> > png16 -I/usr/include/libdrm -ffast-math -O3 -g -O2 -DG_DISABLE_ASSERT
> > -MT libboard3d_la-DrawOGL.lo -MD -MP -MF .deps/libboard3d_la-D
> > rawOGL.Tpo -c DrawOGL.c -o libboard3d_la-DrawOGL.o
> > DrawOGL.c:25:10: fatal error: Shapes.inc: No such file or directory
> > #include "Shapes.inc"
> >  ^~~~
> >
> > On Wed, 4 Dec 2019 at 13:21, Joseph Heled  wrote:
> > >
> > > Is that the righ

Re: current development

[Ralph Corderoy]

Joseph replied off-list...

> An 8 "core" machine, i.e. fake intel count number
>
> $ grep -m1 '^model name' /proc/cpuinfo
> model name  : Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
>
> in debian rules file:
> SSE = --enable-simd=avx --enable-simd=sse2 --enable-threads -with-gtk
> --with-board3d --with-python
> compiled with gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0  -O3
>
> position id: 4NvBGECYr8ELAA:MBngIAAE
>
> rollout cube action:
>
> 8 threads: 93 seconds
> 4 threads: 100 secondsOn stock debian: 111 seconds
> 2 threads: 172 seconds
> 1 thread:   312

-- 
Cheers, Ralph.