[Bug-gnubg] Re: Removing Player Records??

[Jim Segrave]

On Fri 29 Aug 2003 (14:56 -0300), Albert Silver wrote:
> 
> > Or freeze it at
> > about the functionality it now has (I suppose we could save a bit more
> > of the stats and display them), but really we should simply not make
> > any effort to duplicate other and better tools in what is really a
> > backgammon program. 
> 
> Yes, exactly, and what is the purpose here? If it is *only* to play
> against, you can also remove tons of other features such as the analysis
> features, the rollouts features, the market windows, the end of game
> statistics, including FIBS rating calculation, error rates, etc.
> Afterall, they are all guilty of manipulating data.

There are no standalone tools to analyse backgammon play, do rollouts,
display market windows, etc. But there are tools, and better ones than
the developers of gnubg are ever likely to write (at least as part of
the gnubg project) for storing, retrieving and displaying data. 

> The Player Records is one of its most useful features, and I can't begin
> to understand why anyone wouldn't want it. I use it to keep track of how
> I play, and my progress (or lack of) over time, as well as my opponents.
> Every single user I know uses it, and the only complaints have been on
> the limitations. 

Simple tracking of results, not far from what's currently present is
fine. But you just recently named a set of things you'd like to do -
see how you played DMP games for example or play at certain stages of
5 pointers. That's the sort of query that databases are good at. You
can refine it to see how you played DMP against a particular opponent
or every opponent except gnubg - these are easy queries to make to a
database. This is non-trivial to add to gnubg itself.

I didn't say I didn't want player records, I don't want gnubg to
become a huge collection of specialsed sub-sub-sub-menus which are
basic data base queries added to meet the request of one small subset
of users or another. And, while Python is not a bad scripting
language, SQL is a better data extraction language than Python will
ever be and most databases have reporting and display tools (or supply
connections to or data files meant to be used by external reporting
and display tools).

We can improve the player records to a small extent, but after that,
we really should be exporting the data to systems meant to handle it,
instead of trying to replicate functionality which is better done
elsewhere. 

-- 
Jim Segrave           address@hidden