bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Match statistics graph


From: Holger
Subject: Re: [Bug-gnubg] Match statistics graph
Date: Fri, 29 Aug 2003 23:23:58 +0200

At 14:26 29.08.2003 +0000, Joern Thyssen wrote:
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!

Indeed.

> 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.

Who says that we'll have to comply? I agree with Albert. As I wrote in another post I think especially graphics of stats add a big deal of convenience. Of course we should not lose the focus on that gnubg is a backgammon programme. I think that when the time and the requests come we should compile them and eventually decide for a few of them, or simply none.

Recently, I've come across a page where they described how decisions are made for Mozilla. Ah, here it is:
http://www.mozilla.org/roadmap.html   scroll down to "about ownership..."
Don't overlook:  " we expect such czars to communicate, cooperate "

gnubg of course doesn't need this (yet). What I want to point out is, while users may express wishes, they remain exactly these until one or some of the developers decide to do it.

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 :-)

Let them want 100. :-)

> 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.

This is the crucial question. But I don't see anything of this implemented soon, anyway.

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?

The python accessibility should come first, imho. Probably it's even less work than a few graphs. (But I may be wrong.)

> 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.

You do have a strong point here. However, bear in mind that the majority of the users wouldn't be able to even set up the necessary programmes for this. I know quite some who can't even install Oystein's package. So for those some basic set of graphics is in place, imho. The question will only be how many and which and when (maybe not so soon).

Regards,

Holger




reply via email to

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