bug-gnubg
[Top][All Lists]
Advanced

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

Re: Re[2]: [Bug-gnubg] Data collection


From: Achim Mueller
Subject: Re: Re[2]: [Bug-gnubg] Data collection
Date: Fri, 15 Jun 2007 12:07:13 +0200
User-agent: Mutt/1.5.9i

* Chris W. <address@hidden> [070615 11:53]:

> First of all, I apologize for the tone of my previous email. It was a 
> frustrating
> day.

np ... we all have that from time to time.
 
> I honestly cannot see how this can be called a feature. If we were talking 
> about
> files on different disk systems, then this would make perfect sense. Would you
> reject a piece of mail, email or otherwise, simply because someone spelled 
> your
> name ChristiaN aNthon? Shouldn't data be Normalized rather than UnNormalized? 
> I
> can think of very few instances when key data should not be normalized.

Pretty simple. An "A" is different from an "a". This is good old Unix
style since 1970 (and probably before). Why do we have ANSI and ASCII?
 
> > How difficult would it be to create an "export statistics" command so 
> > individuals can
> 
> CA> You would have to decide on a universally accepted export format
> CA> first. I know no such thing.
> 
> Well, CSV files have been around for decades. You could even go with the much
> heralded XML format. ;-)

Take a look at the different backgammon servers. There aren't any two
with the same game format. Regarding the stats, take a look at the links
below.

BTW, there is http://sqlitebrowser.sourceforge.net/
 
> > Perhaps the best way to address the issue of which database to use, is to 
> > use
> > none at all.  This low-tech method would reduce the complexity of the code 
> > base,
> 
> CA> This seems plain wrong to me.
> 
> It's not SQL that I was taking issue with, it's the use of SQLite. There are
> virtually no tools available for working with this product. SQLite Admin. is
> decent but you'd have to spend $100 for the best app available. (SQLite 
> Maestro)
> What I was hoping for was an SQL database that can be connected to via ODBC.
> SQLite doesn't provide that level of connectivity. As tightly controlled as
> Snowie is, I can still read its Paradox tables by linking them to an Access
> database via ODBC.

Well, sqlite can be connected via odbc.
http://www.ch-werner.de/sqliteodbc/
 
> Snowie and GNUBG do a great job at helping a player improve his skills but,
> both are woefully lacking when it comes to presenting data that shows the rate
> of progress the player is making. By graphing the data over a period of time, 
> it
> would become clearly evident if a playing slump is due to errors made or 
> simply

You are heartly invited to provide some code.

Ciao

Achim




reply via email to

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