RE: [Bug-gnubg] Python Support

[Misja Alma]

Hi Jim,

I read about your idea to let gnubg add all errors to a database and to
provide the user with a possibility to comment those errors.
I have written an application in Java a while ago which did the same thing.
I accomplished this by letting Snowie evaluate my matches, export them to a
.txt file and import and interpret them in my application (and store the
errors in a database). I found this to be very useful and interesting for a
couple of months.
But after a while I started to miss the possibility to let my application
automatically classify the positions. You see it would be handy to store all
positions in a database, errors or no errors, together with a classification
like 'holdinggame', 'race', etc. Then you could get a much better idea which
kind of positions you didn't understand well enough: you could query the
percentage of all holdinggame positions where you made a mistake, the
average mistake you made etc.
To classify every position in a match by hand is way too much work (for me
at least). But I found it very hard to think of a way to automatically
classify a position. I wouldn't even know which categories to use!
One example would be for instance the categories which Robertie uses in his
books, but many of his categories are not well defined. Especially the
category 'middle game' can be applied to way too many positions to make it
useful.
Does anybody perhaps have an idea what a good categorisation of backgammon
positions would be ?

Misja

-----Oorspronkelijk bericht-----
Van: address@hidden
[mailto:address@hidden Jim Segrave
Verzonden: Friday, August 06, 2004 12:52 PM
Aan: amarganth
CC: address@hidden
Onderwerp: Re: [Bug-gnubg] Python Support


On Thu 05 Aug 2004 (23:46 +0200), amarganth wrote:
> Hi Jim
>
> Thanks for the answer. I don't know how to answer into the mailing list of
> gnubg with the same subject "Python Support". So I answer directly to you.
> Sorry 'bout.

Just hit reply to all (or that works for me). The other way is to change the
reply address to address@hidden

> Yes, the redirection of the output doesn't work.

> Sorry, but I don't program in C. So I cannot implement the desired
function.
>
> The gnubg.hint() in Python would be absolutely perfect! Not only for my
> planned bot. But who is willing to program that?

I've started learning Python, because I have a lot of ideas on using
the scripting and want to add things to the database. I've been short
on spare time for the last long time (and have been using a lot of
whatever spare time I have playing on-line, which is what got me
involved in gnubg in the first place), but if no-one else picks this
up, I am likely to have a go at it. I want a generic Python interface
to evaluations because I'd like to extend the database with the option
of keeping game records and moves (allow the user to keep moves within
games which meet some criterion, usually because they were flagged as
errors). I think some people would be very happy if they could, along
with commiting a match to a database, could also record all their (and
optionally their opponent's) moves where the EMG equity loss was
greater than some threshold or where the MWC loss was greater than
some threshold, to allow later study. In particular, if the database
had some fixed types which the user could easily assign and provision
for a comment field, then you could take an analysed match, mark some
of your blunders as to type - 'holding game', 'breaking anchor'
whatever is meaningful to the user. Then you'd be able to pull all the
mistakes of a particular type which you've made and get gnubg to bring
up the situation where it happened for further study.


> The easiest way for all the output of the gnubg.command() is to store it
in
> a simple variable (s = gnubg.command("something")). A parsing after
getting
> the output isn't as nice as this gnubg.hint(). But it would be a solution
> for all the possible commands. But I think I understand, that it's not as
> easy as it looks like.

I'm not opposed to this, but there are some considerations:

This is doable for non-GUI, but becomes very difficult if you invoke
Python functions on a GUI version, since there's no concept of stdout
and information is presented to the user in lots of different ways -
entries in text widgets for example.

It also makes automatic parsing difficult for the Python programmer,
since the parser has to account for changes in output text either as a
reult of gnubg evolving or simply dealing with the problem of text
being in different languages. I think keeping Python scripts tracking
the current language files would be unlikely to be manageable.


--
Jim Segrave           address@hidden



_______________________________________________
Bug-gnubg mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-gnubg