[Top][All Lists]

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

Re: [Bug-gnubg] Match statistics graph

From: Jim Segrave
Subject: Re: [Bug-gnubg] Match statistics graph
Date: Fri, 29 Aug 2003 17:47:16 +0200
User-agent: Mutt/1.4i

On Fri 29 Aug 2003 (14:26 +0000), Joern Thyssen wrote:
> There exist other programs where the user can specify whatever query he
> may desire, and draw any graph he may desire. Why limit ourselves to
> whatever the programmers decide to implement?
> > I also think
> > enough serious students of the game would find it interesting to make it
> > worthwhile: 
> Yes, but each serious student want something different. We simply can't
> provide it!

I think this is the big divide between the Unix background and the
Windows background, Unix has the idea of lots of generic tools as
separate pieces which get assembled to meet requirements, Windows has
the idea (even if it's by sharing IE as the basic rendering platform),
of monolithic do-all tools.

There are some good tools out there for handling databases, extracting
data, presenting that data in graphical or other forms, etc. There are
a lot of very sharp developers working on those things - mySql and
postgres for example are open-source database engines of enormous
power. There are, I believe, several presenation systems, of which
gnuplot is only one, again with a lot of expertise. I don't think the
developers of gnubg can compete with those teams in those areas, even
if there were the desire to do so.

Building libraries of (user-contributed) python mini-scripts to
extract specialised information is a reasonable prospect for the
future, much as emacs benefits from the huge elisp library of

But most of what Albert mentions are actually derivations from simple
game data. Assume that gnubg can output a CSV file for every game
played containing:

date & time (I'd also suggest putting in the Unix time() value, as
             it's much easier to process)
player names
type - match/money game
rules/context - jacoby, crawford, post-crawford
luck total/average
chequer/cube/overall total and average errors
moves forced/total

This can be imported into almost every existing database or
spreadsheet, from which all of the data mentioned here can be
reasonably easily extracted and displayed in bar/line/point graphs,
pie charts, 3d surfaces, etc. Users can either let the CSV file
accumulate or periodically import it into a more flexible database and
delete the current one. Then they can use real data manipulation tools
rather than ad-hoc add-ons to gnubg.
> If the players' records are stored in a relation database it would be
> relatively simple to do such a query.

I don't think we should be hooking directly to a relational
database. We're much better off using a lowest-common-denominator
export of raw data, e.g. CSV files

Jim Segrave           address@hidden

reply via email to

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