Re: [Bug-gnubg] Match statistics graph

[Joern Thyssen]

On Fri, Aug 29, 2003 at 10:36:51AM -0300, Albert Silver wrote
> I've been following this and agree about the danger of a bloated
> program. And just so you guys can get a good laugh, that program I
> worked on, Chess Assistant, gained some useless e-mail client in it (as
> spartan as could be) to send and receive bases and games. 

*ROFL*

This is fun! 

> The usefulness isn't only a matter of the user using it, but also
> applies to the suggested 'let the user do it'. Would enough users who
> would find this useful know how to do it? If not, the argument is
> pointless since by choosing this, we know in practice it will simply
> never be taken advantage of. This is similar to, but not as bad as,
> suggesting that if a user wants something they can 'simply' use the
> internal Python to script their desires. My only reaction would be that
> you might as well say that apart from the developers, maybe a small
> handful of people (at most) will even be capable of doing this.

[5 minutes later, when I had finished laughing]

Python is actually quite easy to learn, anyway, I'm not talking about
telling users to learn python and extract the information themselves
(see below).

> This last one is key here. How many graphs are useful enough to be
> included as a courtesy of usefulness and ease-of-use (sure beats
> exporting and building). I think some graphs would be useful enough to
> deserve implementing directly here, but that many would not.  The
> question would be more which ones, which would be a combination of
> group decision and of course the person implementing them.

We'll have 10 users
requesting 10 different graphs. Next month we'll 10 other users
requesting 10 other graphs. This wil go on for ever. If you give them 5
graphs they want 20. If you give then 20 they want 50, and so on.

I find it much better to provide some simply overviews, and allow the
user to export the data and do whatever he wants to do with it. Note
that gnubg wil supply the exporting routine, so the user only has to
know how to handle a spreadsheeet. 

> Snowie has a number of graphs, and still not enough IMHO. 

You see: Snowie has 20 graphs, the users want 50 graphs :-)

> It has
> breakdowns of the equity per match (in its Player Records) and per game,
> of the cube decisions, the checker play, as well as the luck. If one
> really keeps a good record of results, so that enough information is so
> recorded, then it would be possible to get a greater breakdown of
> results, and yes, I think this would be very interesting. 

Yes, but I'm not sure it belongs in the backgammon program.

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!

> The error rate at different scores (only for 5-point match
> scores which are the most crucial), and the error rates in games at
> those scores. This would not need a graph since the graph wouldn't be of
> much help, but the information is interesting. If I saw that my error
> rate for DMP games, or 1-point games, was higher than it should, I'll
> know I have a weakness there. A beginner might not care or understand,
> but a more advanced student most certainly will. Some other critical
> scores such as 2-away 4-away, the ultimate Gammon-Seek and Gammon-Avoid
> score are also interesting. I have found that a common score where
> strong (1800+) opponents consistently make doubling blunders(!) is
> 4-away 3-away. The break down would be fairly simple once the
> information was available, and would probably look something like:

Again, I'd rather supply the data for you to do these queries rather
than supplying the tool. Next month you request a graph of your chequer
play errors rates as a function of the gammon price.

If the players' records are stored in a relation database it would be
relatively simple to do such a query.

If enough users find a particular query interesting they can share
it rather than us having to implment graph or report number 1,745: 

"hi fellow users,

The attached ACCESS query will break down your error rates on gammon
price"

or

"hi developers,

I would like to see my error rates as a function of gammon rates. Can
you help me construct a query for ACCESS, please?"

instead of

"hi developers,

I think this particular feature could be of interest to millions of
backgammon players. Please implement!"

to which we'll reply "no, we won't implement" or "ok, later (read: next
millenium)". Each new graph may require many hours of work, but each new
query can be constructed in minutes.

Jørn

pgprLG_NGY2Ke.pgp
Description: PGP signature