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
functions.
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
score
rules/context - jacoby, crawford, post-crawford
result
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