[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] gnubg.sql - stats from my database

From: Jim Segrave
Subject: Re: [Bug-gnubg] gnubg.sql - stats from my database
Date: Mon, 15 Nov 2010 13:45:30 +0100
User-agent: Mutt/1.5.16 (2007-06-09)

On Mon 15 Nov 2010 (11:48 +0000), address@hidden wrote:
> Hallo Michael,
> Thanks for your input - I too agree with Ian Shaw's 
> good advice. My head tells me that the program does not 'cheat' and I 
> do try to study my mistakes and become a better player almost every 
> day.
> But I am also intrigued by the valid question of whether I am a 
> poor player with bad luck, or a poor player with normal (or good) luck. 
> And the same question with respect to the CPUs dice rolls.
> I find the 
> 'luck' calculator built into gnubg to be a little obtuse in how it 
> comes to it's conclusions - a more transparent and understandable 
> method would be to perhaps display the statistics I suggested.
> Another 
> clarifying feature would be, after I lose to gnubg (again), to be able 
> to play the game again.
> But we would swap the CPU's dice rolls with my 
> own.
> This would clearly show if gnubg would still win when you have his 
> now predetermined 'lucky rolls'.
> I did check out your link of 
> statistics: 
> >http://www.capp-sysware.com/analysis/octnov2010-dc-dicestudy.txt
> it 
> is excellent and very close to what I was trying to describe. Did your 
> generate those statistics using your scripts and sqlite? Or were they 
> extracted from another source / program?
> It would be a great tool if 
> something like this was built into gnubg, where you could compare your 
> rolls against the CPUs for these categories - and I suspect a lot of 
> players would love to be able to see their own personal stats for these 
> queries.
> >Unfortunately the data you seek for doing a dice study does 
> not reside 
> >in the database (There is no accounting of every roll, and 
> the data is 
> >pretty much on a general match level)
> But the above 
> sounds like a showstopper for what I had in mind?
> I am not really a 
> programmer so I doubt that I will get much further than this on my own, 
> but I would like to see the scripts if you have any time to send them.

I haven't checked the latest builds of gnubg, earlier ones kept all
the data per game/match that you see on the show match/game

If you analyse your matches and save the results as .sgf files, then
it is possible to extract all sorts of per-move information from an
analysed match. I have (when trying to settle an argument with someone
about "usable" doubles) written scripts which can extract almost any
information you want - doubles, doubles from the bar, pip-count loss
from hits, time spent dancing on the bar, you name it. 

Specifically, your requests:

1) Given a collecton of sgf files, I can easily generate the number of
doubles for each player (including if the player was able move at
least one piece one time - a usable double)

2) I have a script which calculates pip loss from being hit, 167 - the
loss = total pip count

3) would be fairly easy to modify an existing script to do

4) would be more work, but certainly do-able. My script for counting
dancing reconstructs the board for each dice roll so it would know if
there are pieces on the bar

5) The most useful (which I will do one of these days when my round
tuit supply is replenished) would be to create a database of mistakes
- cube and checker play with an EMG loss amount (so you can choose
what level of mistake you want to analyse), the gnubg board and match
ID (so you can put the mistake back into gnubg), and an easy way for
an external script to input the board and match ID, allow you to play
one move, then stop and analyse the move afterward, reporting the
results back to the script. It could then tell you what you played
before, what you just played and what gnubg believes the best
move/cube action is for that position and match state.

Jim Segrave           address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]