European Go Database / Wishlist

Wishes, requests, FAQ... and similar for the European Go Database.

Table of contents Winning probabilities Ratings calculator International tournaments International tournaments, revisited Relation between EGD and EGF Changing personal info Tournament classes rationale Rank resets Tournament waiting list Showing only EGF ranked players Rating calculation with old events Link to player Being able to put in the names, as they are eta parameter GoR vs. Rank Progression Chart Pictures and .sgf policy Data access Comparing populations Get data via AJAX Four letter club abbreviations break functionality Class Z tournaments Ranks 21-30k Question about Very Large Handicaps AGA - GoR comparison Advanced tournament tables More GET requests Automatically split events Declared rank updates between tournaments Online Tournaments Anonymity, data security, feasability sorting European Go Calendar Theoretical Question Unified Rating List Club graphing wrinkle

Winning probabilities

gaius: I looove this feature. But it's extremely slow when you request the winning probabilities from 1995 up to 2010 (basically, the whole period). I can also imagine that processing such a request puts a fairly big strain on the server... Maybe it's an idea to save the winning statistics of the *entire* database in a text file which is periodically updated, so that it can be retrieved quickly?

• Flatline: Sure. My idea was to let people play around with the new toy for a while, then analyze the queries frequency from the logs and - according to the results - give a menu of possible choices (e.g.: "last year", "last month", "the whole database", "choose your own range", etc.). I'll do it, soon or later. For the time being, I'm happy that you looove the feature :-)

Ratings calculator

• IanDavis: I would like to request a ratings calculator for those of us who can't wait to find out what our rating will be next month.
  • DJ: Hi Ian, I've forwarded your wish to Paolo and Aldo... I'll keep you posted on the development.
  • Flatline: Hi Ian. As you know, EGD has changed its nature a couple of weeks ago (today is April 19th, 2009). Now tournaments results are uploaded directly by organizers, and all ratings are immediately updated. I hope this answers to your question.
    However, I'm also thinking about a GoR calculator to add to EGD for on-the-fly simulations. I'll release it soon.
    • IanDavis I am extremely impressed by what I have seen so far. Real Time updates, GoR changes per player, head to head information, EGD appears to have everything you could want.
      • Flatline: Thank you Ian, I'm touched :-)
  • Flatline: At last I did it: the GoR calculator is online. It is possible to simulate up to 10 games, declaring GoRs of opponents or leaving EGD to retrieve it via AJAX by typing PINs or last names.
• geoff: The ratings calculator is excellent - thank you very much Aldo. Just one small improvement could be made. After getting the final GoR, if you change to some other page and then return, the results have been cleared. It would be better if you had a 'Clear results' button. Then clearing of results is under user control.

International tournaments

• tapir: What is the point in adding data from e.g. the KPMC to the EGD?
  • Phelan: It was added to the European official ratings, and imported from there. Perhaps Ales Cieply can better answer that.
  • Herman: I assume that the point is that European players participate in the KPMC, thus adding those results improves the accurracy of their ratings.
  • tapir: Doesn't it add dozens of players from everywhere (that is without much games in the database = inaccurate rating) to the database? I thought the EGD is somehow an official outlet of the European official ratings... Am I wrong?
    • IanDavis It is useful to store such information, some federations may use this when choosing whether to promote a player based on their WAGC performance.
      • tapir: I won't argue against storing such information, but I don't see the point in keeping pro-ratings, worldwide amateur ratings according to WMSG, WAGC results only.

International tournaments, revisited

• tapir: I want to restate my case about the inclusion of international tournaments and all players there with an example. Just look at this - Han Sang-hun is 13th in the korean pro rating:

 15213374	Oh	Chimin	 DE	Ber	7d	2785	11	3
 14237795	Han	Sang-hun KR	xxx	3p	2782	2

• • Herman: I think that the inclusion of such results can be useful. At events like the WMSG or WAGC, half the players there are European, so they will play many matches against each other. Korean players like Han Sang-hun are not actually ever put in the official EGF rating list (which only lists players from EGF member countries), and are thus more of an artefact. I do think that it would be good if the Find Player page filtered to something like "Players from EGF member countries only" by default to avoid listing only player like Han Sang-hun. (Also, I think the EGF assumption of 1p = 7d = 2700 is flawed, especially for Korean and Chinese professionals, but that is another matter).
    • tapir: Of course performance in worldwide events is important. But EGD becomes instantly a worldwide rank/rating database - despite lack in data for them. Aligning two rating systems (1p = 7d) can only work if there is some exchange between them.
      • Herman: GoGoD includes the ProGoR ratings that Ales Cieply once calculated, applying the EGF rating formula to the professional games in the GoGoD database. It would be interesting to see how they match up with the EGF ratinsgs, but as you said, that requires some exchange between them. The WMSG provides some exchange between amateurs and professional, as do a few other tournaments (eg: Ing Cup), but such games are rather limited.

Relation between EGD and EGF

• tapir: Ales Cieply or Marco Silles according to him ( http://gocafe.blogspot.com/2008/08/ales-cieply-gibt-egf-rating-ab.html), he'll maintain the GoR in future? I don't understand the relation between GoR and EGD at all...
  • Ian?: The EGD is an accessible frontend to the tournaments used to calculate GoR
  • Phelan: It seems that the European Go Ratings will be maintained at the EGD starting from April. Note on http://gemma.ujf.cas.cz/~cieply/GO/gor.html "The EGF ratings are moving to the European Go Database. We intend to complete the move by the next (April) update. A new system for results submission is already functional."
  • tapir: Deshis knowing German might be interested in this: http://gocafe.blogspot.com/2009/03/egf-rating-verschmilzt-mit-egd.html - merging of GoR and EGD - with an online access and semi.automatized result processing + the old issue FIGG/AGI, with the AGI maintaining the EGD while not officially EGF member.
  • Phelan: Deshis not knowing German might also be interested in it, and use babelfish to get the gist of the article. ;) Thanks for posting it here.
  • Flatline: I have to give an answer to this question:
    > I don't understand the relation between GoR and EGD at all....
    Starting from April 3rd, 2009, EGD has become the official repository of european tournaments, and every time a tournament is added, the GoR is automatically recalculated at once. No human intervention is needed any more.
    Of course there is a human supervisor, let's call him the "Ratings Manager".
    Today, this person is Aleš Cieply.
    • Flatline: I forgot to update this piece of information: as of August 2009, this person is me (Aldo Podavini)

Changing personal info

• tapir: I moved. How can I change city and country entry in EGD?
  • Phelan: I used to ask the person in charge of updating our country's results to send an email to Ales. I don't know if there is a better way to do this in the current system, though.
  • tapir: I thought the whole point of the update was not to depend on Ales for everything... so this is a feature request :)
  • Flatline: Well, the whole point of the update concerns several aspects. One of them is definetly not to depend on the Ratings Manager for everything, another one (not less important) is to have a real-time update of results and ratings.
    Anyways: club and country are updated every time a player takes part in a tournament, with the new data declared by the tournament organizers. Of course, when a change occurs, it would be nice not to wait for the next tournament and submit the change at once. The new backend features allow this, but at the moment this function is restricted to the Ratings Manager. Maybe it will be opened to all people allowed to submit results, when we are sure that everything works fine. At the moment, we are still testing the new functionalities: they have been released a couple of weeks ago :-)
  • tapir: Oh, my tournament organizer just forgot about it, it seems. Now, what should I do? Email to secretary@agi.go.it (that is you, flatline?) with player id and current location?
    • Flatline: Yes, it's me behind that address :-)
      The right person for these issues is the Ratings Manager, who at the moment is still Aleš Cieply. Anyways, writing to me will work fine as well :-)
      • tapir: Adding Ales' email address to the page here or to the egd page may be helpful. The SL page doesn't reflect the current situation anyway.
        • Flatline: Consider that going to EGD everything is well documented. But you are right, we have to change the SL page.
          • Flatline: I did it.

Tournament classes rationale

• tapir: Is someone who gets no sleep / drink too much on Go Congresses really a worse player? Or: What is the rationale behind weight differences in A, B, C class tournaments?
  • Classes differ by time controls. A are serious; long time limits, C quick, dirty :)
    • tapir: We should add this somewhere...
      • Flatline: I think it is stated clearly enough here

Rank resets

• tapir: The EGD policy to cope with fast-improving players is to reset the rating if a players declares a rank two stones above his old one. Incidently some associations (e.g. Switzerland) try to prevent players declaring a rank two stones stronger then last time, thus effectively disabling the policy. Any thoughts about this? Doesn't this lead to overall rank deflation?
  • IanDavis: I strongly suspect that this may be the case. Especially in the cases where a large group of new or young players join the organisation. In fact I have produced graphs which I believe show this effect.
    • tapir: Will you share this graphs?
      • IanDavis: They are available on GoDiscussions forum actually. What I did was to make a histogram for active go players each year. I took bins 50 rating points wide, and mapped the change in the number of players in these bins per year per country. My impression is that the promotion system used in a paticular country appears to influence the form or shape of the histogram. However there is less data than you would want to be able to make firm conclusions over this. The EGD actually has a similiar statistics function, but its bins are far too wide (500 rating points) to show anything interesting.
        • tapir: I opened an account there to use the search function and finally found the graphs ( http://www.godiscussions.com/forum/showthread.php?t=4075). Imho these graphs (normalized rating distribution etc.) show more about the population and the influx of new players than about deflation.
          • IanDavis: Possibly, but I believe that since influx of new players happened at the same time (Hikaru No Go) the differences between countries are interesting.
  • mgoetze: Yes. Another interesting statistic to consider is the GoR gains/losses of players from one country attending a tournament in another country. For instance, Finnish players at the LOGC 2003 gained 86 GoR points on average. I wrote about this problem in more Detail back in 2004 on the German Go Federation Forum ( http://www.dgob.de/yabbse/index.php?topic=1054.msg117798#msg117798 ).
    • tapir: Any further study of this effect? In recent years for different countries?

Tournament waiting list

• LovroF : Would it be possible to put something on the front page of EGD like tournament waiting list. List of tournaments wich were sent to EGD but not yet approved by supervisers.
  • Flatline : That's not useful, IMHO, since usually tournaments stay in waiting list for not more than some hours. Furthermore, the RM can have his good reasons to leave them in stand-by, so I'd prefer not to put pressure on him.

Showing only EGF ranked players

• tapir: I'd like to have an option to not display a) the inactive players b) the players with "0" EGF rank. Instead of b) it would be possible to just change the sorting - starting with 1, with the 0 added at the end.
  • Herman: This is the option "EGF Ranked" in "Players filter" at the Find player page. The same list can also be found through http://www.europeangodatabase.eu/EGD/EGF_rating_system.php (the official rating lists).
    • tapir: Asking silly questions has the merit that step by step this becomes a genuine FAQ. I missed the option though :)

Rating calculation with old events

• Herman: I recently noticed that ratings are not always recalculated correctly when older events are added. For example, recently the Dutch Go Competition was added, which dates to march 9 of this year. I noticed that despite a very good result, the rating for Frederik Spanhoff did not actually seem to change. Now when I look at his GoR evolution, I can see that both this event, and the next one he played (Nijmegen, played march 21) are given as being calculated from a start rating of 2328.688. So apparently, the earlier event (which was entered later) is not taken into account when calculating the rating after the later event. Perhaps this is normal and there is a periodic recalculation, but I was curious about it.
  • Flatline: Good question. As a general rule, EGD recalculates the ratings at once when a tournament is submitted. But for old tournaments, in order to avoid massive waste of time when multiple submissions are made (a recalculation requires about ten seconds per month), EGD keeps track of the submitted tournament, but leaves to the Rating Manager to choose when launch a massive recalculation. Now you have spotted a case when this recalculation has not been launched; you got a point :-) Have a look at Frederik Spanhoff's card now: everything is ok.
    • Herman: Ok, thanks! Maybe massive recalculation could be automatically triggered late at night under certain conditions?
      • Flatline: Of course it can. But I don't want to spread the idea that EGD is adjourned once a day: EGD is adjourned as soon as the RM completes the confirmation process. The fault you have spotted must be regarded as a little lapse.
      • Flatline: Today (July 9th,2009) I've changed the confirmation workflow, so that now GoR is recalculated at once when a tournament is submitted, even when it is an old one.

Link to player

• Uberdude First of all well done on making a great site. However with all the recent changes it seems there has been a regression. There is no longer a link from the tournament page to the player page. Both the PIN and Name link go to that player's detail for that tournament rather than the player page. There used to be a link to do this and I found it really useful and I miss it now. In detail: I go to my player page and click link to my most recent tournament http://www.europeangodatabase.eu/EGD/Tournament_Card.php?&key=T090502B&pin=14337147 which lists my opponents. Both the "12801932" and "Kiyohiko Tanaka" links go to his results for the same tournament. I think the "12801932" link should go to his player page, i.e http://www.europeangodatabase.eu/EGD/Player_Card.php?&key=12801932. Currently I can find no way to do this other than copying the PIN and typing it into the URL directly.
  • Flatline Hi Uberdude, thanks for your appreciation. Fortunately there is a much faster way to reach "Kiyohiko Tanaka"'s card : you can click on the player's photo displayed at the left of the players list and - as happens in every social network when you click on a member's photo, as far as I know - you go to that player's card. So, the card of "Kiyohiko Tanaka" is only 2-clicks away from you :-)
    • Tapir: I admit that I missed the link as well.
    • Uberdude Ah, I missed that, and seems other people did too. Still, having both the player name and ID going to the same place is redundant, and 1 is better than 2 =)
    • tapir: I guess the reason people miss this option is that most people don't have a photo.

Being able to put in the names, as they are

• Zarlan: Apparently the EGD doesn't accept some letters, such as å,ä,ö,ü...
  

It also doesn't accept spaces. This does not reflect reality. There are many names with characters and/or spaces. Such flaws leads to an inability of accurate input of many names. I see no reasonable reason for this, nor do I see how this isn't something that shouldn't be fixed.

• çÇ ğĞ ı İ ...

• Flatline: Actually EGD does accept only letters belonging to the Latin alphabet. There are several good reasons to have such limitation, the first one being that Latin characterset is the only one fully ASCII. So, unless we use this limitation, it would be quite difficult to make sure that a) incoming data are always correctly typed and b) data from the database are always correctly rendered by every user's browser. Fortunately, for every non-latin alphabets (including Asian languages, Hebrew, Cyrillic, etc...) there are transliteration systems widely accepted. The reason for not accepting spaces is different. The fact is that EGD is feeded by results tables exported by pairing programs, and in these tables fields are always spaces-delimited. So the space cannot be accepted within a name. When it occurs in real names, it is easily replaced by an underscore "_", and everything is fine :-)

• Zarlan: Interesting reasons. Now lets see...
  

"So, unless we use this limitation, it would be quite difficult to make sure that a) incoming data are always correctly typed"

Using the ASCII-only restriction, means that names may be entered in different ways, depending on how they are transliterated or transcribed (this has happened, and is happening, in the EGD), so the ASCII-only limitation only makes the situation worse.

"b) data from the database are always correctly rendered by every user's browser."

While not every computer correctly renders Asian, Hebrew or Cyrillic characters, that isn't relevant. Those characters should be transliterated anyway (they should, after all, be readable by Europeans). Latin letters, however, don't cause any problems, as far as I know. As the wikipedia page you mention says, Latin letters are not restricted to ASCII. Å,ä,ö,ü,ç,ğ,ı,İ,æ,ñ, ø.... Those are all Latin letter.

"The fact is that EGD is feeded by results tables exported by pairing programs', and in these tables fields are always spaces-delimited."

While I understand how that would mean that the data received would generally have that restriction, why does the EGD have to have it as well? Also, as I mentioned above, when a name cannot be correctly written, the transliterations/transcriptions, generally won't be consistent. There are at least three different methods: The space might be skipped or replaced with a - or a _. Different names may be transliterated or transcribed in different ways (even in the same tournament) ...and at a different time, the same name may be written in a different manner.

• Flatline:
  

"Using the ASCII-only restriction, means that names may be entered in different ways, depending on how they are transliterated or transcribed"

Yes, that may be true. But I don't think that this makes the situation worse. Also, consider that names corrections in EGD are quite easy.

"Latin letters, however, don't cause any problems, as far as I know. As the wikipedia page you mention says, Latin letters are not restricted to ASCII. Å,ä,ö,ü,ç,ğ,ı,İ,æ,ñ, ø.... Those are all Latin letter."

I do not agree: they are not Latin letters (we can discuss about "æ", but all the others definetely aren't). I cannot find where wikipedia says differently...

"While I understand how that would mean that the data received would generally have that restriction, why does the EGD have to have it as well?"

Yes, it would be easy to replace underscores by spaces when displaying data; still I think that this would be even worse, because people who prepare results tables, seeing spaces which they cannot use, would possibly adopt different alternatives (dashes, commas, etc...).

"Also, as I mentioned above, when a name cannot be correctly written, the transliterations/transcriptions, generally won't be consistent."

As you probably know, data which are sent to EGD have been written by many different people, with many different programs, keyboards and linguistic skills. For instance: I live in Italy, I have an Italian keyboard (with letters such as "à,è,ì,ò,ù..."). If I'm organising a tournament where is playing a player from Russia, let's say Богданов Виктор (Viktor Bogdanov), I would have great trouble if I had to type his name as it is, because: a) my keyboard hasn't those characters, b) the pairing program I'm using probably doesn't accept them, c) I cannot understand them.

• Zarlan:
  

"Yes, that may be true. But I don't think that this makes the situation worse."

It creates many more ways of writing the name, so the said problem (I.e making sure "incoming data are always correctly typed"), is further complicated. How doesn't that qualify as making the situation worse?

"they are not Latin letters (we can discuss about "æ", but all the others definetely aren't). I cannot find where wikipedia says differently..."

Aside from my utter surprise, that you would consider æ, more of a latin letter than the others... Here are some Wikipedia pages:

http://en.wikipedia.org/wiki/Latin_alphabet#Extensions The very one you linked to. If that's not enough...
http://en.wikipedia.org/wiki/List_of_Latin_letters http://en.wikipedia.org/wiki/English_alphabet#Old_English If that's still not enough...
http://en.wikipedia.org/wiki/Latin_characters_in_Unicode http://en.wikipedia.org/wiki/Latin-1_Supplement_unicode_block http://en.wikipedia.org/wiki/Latin_Extended-A_unicode_block http://en.wikipedia.org/wiki/Latin_Extended-B_unicode_block http://en.wikipedia.org/wiki/ISO-8859-15

"Yes, it would be easy to replace underscores by spaces when displaying data; still I think that this would be even worse, because people who prepare results tables, seeing spaces which they cannot use, would possibly adopt different alternatives (dashes, commas, etc...)."

What? Why would they make results tables from the EGD? If I understand correctly, the tournament has pairing software, the software exports data that makes a results table, which is then input into the EGD. Why would people then create a results table, something that they already have, from the EGD? ...and why on earth would they have to limit themselves to not being able to use spaces, when they are obviously not creating the table from software that has such a limitation? (also, why should the EGD adapt to the software, and not the other way around?)

"As you probably know, data which are sent to EGD have been written by many different people, with many different programs, keyboards and linguistic skills."

My point exactly.

"For instance: I live in Italy, I have an Italian keyboard (with letters such as "à,è,ì,ò,ù..."). If I'm organising a tournament where is playing a player from Russia, let's say Богданов Виктор (Viktor Bogdanov), I would have great trouble if I had to type his name as it is"

WTF? As I already said:

"While not every computer correctly renders Asian, Hebrew or Cyrillic characters, that isn't relevant. Those characters should be transliterated anyway (they should, after all, be readable by Europeans)."

Now why are you arguing against a position I obviously don't hold (and have indeed clearly gone against)? That is rather rude. Did you not pay attention to what I said?

"because: a) my keyboard hasn't those characters, b) the pairing program I'm using probably doesn't accept them"

Point 'a' does have some merit, although there are easy ways of going around that. Point 'b' even more so, although I would say the same thing I do about the spaces, for that.

...oh, and BTW, about à,è,ì,ò,ù: Any, not too unusual, keyboard can produce those, with the `-key (the same goes for letter with ¨,~,^ or ´)

• Flatline: Okay Zarlan, it's quite clear that we have different views on the matter. I just want to point out that:

  all your references from wikipedia speak about alphabets derived from Latin, not Latin itself. Anyways I don't want to stick to this definition, which is of course largely questionable. If you prefer, change my words replacing "Latin alphabet" with ASCII

  I didn't say that people are "making tables from the EGD". Nevertheless, they may (and do) have a look at EGD when putting players data into their tournaments data, especially when they have some doubts about spelling. And, as I said, they CANNOT use spaces.

  The problem with letters "à,è" and any other non-ASCII character should of course be solved using the Alt-n and other tricks, but nevertheless this can represent an obstacle for the general audience.

Having said this, it's clear that we do not agree. Not a problem, right ? Peace :-)

• Zarlan: On the ASCII issue, I still say that Latin letters (alphabets derived from Latin? Letters derived from Latin, I can accept, but alphabets? Anyway...) are no problem for browsers to render ...and I do not have any idea what your talking about, with Alt-n. There are keys for ¨,~,^ and ` on any QWERTY keyboard (actually... that one seems a bit lacking, and I'm unsure how common this version is. Well, any non-English keyboard will have the proper keys ...with the curios exception of the Italian one), but again: why should limitations of input, limit the EGD? Either way, I accept that I won't be able to change your mind on the issue. As to the spaces...

"I didn't say that people are "making tables from the EGD". Nevertheless, they may (and do) have a look at EGD when putting players data into their tournaments data, especially when they have some doubts about spelling. And, as I said, they CANNOT use spaces."

Well they have two sources of spelling, as I see it: The actual person, from whom they presumable receive the name, either way ...so why would they be unsure about the spelling is beyond me (well, unless the player is highly dyslexic) and the EGD. If they decide to use an incorrect replacement for the space... well that's the case now, anyway, isn't it? (and if people know that underscores are automatically turned into spaces, surely they'd start using them, when they need something instead of a space?)

Zarlan: Oh wait! Alt-n!? do you mean like ALT + <number>? Alt codes? That's more something for letters like å and ß (I've memorised the Alt code for ß BTW. That and ¯).

Herman: I think you have an overly optimistic view of the simplicity of this issue. As the discussion already shows, there is no clear definition of what the "Latin alphabet" is. For computers, this might be Basic Latin (ascii) with the possible addition of Latin-1, Latin_Extended-A, Latin_Extended-B, Latin_Extended-C and Latin_Extended-D. My browser (FF3 on WinXP) can render Latin-1, Latin-A and part of latin-B, but none of Latin-C or Latin-D.

You reference ISO-8859-15, which discards the signs ¼, ½ and ¾. But these are extermely common in tournament tables. An alternative might be Windows-1251, which includes all printable characters from ISO-8859-15, as well as ¼, ½ and ¾, but that charset has its own problems, especially on non-Windows systems.

You dismiss Cyrillic with "should be transliterated anyway (they should, after all, be readable by Europeans).", but Russia is a part of Europe, and a member of the EGF, so why not cyrillize western European names for Russian easy of reading?

I think that instead, an approach that uses both an ascii representation and a "native alphabet" representation (so including Cyrillic, Hebrew, Chinese, etc) would be better. If things like integration between EGD and OpenGotha move ahead, players could simply be referred based on PIN, and tournament organizers could choose to either use the simple ascii representation when printing, or use native alphabet. Using PIN numbers for the results sent to the EGD would also preclude confusion on spelling and transliteration.

• Flatline:
  

"If things like integration between EGD and OpenGotha move ahead, players could simply be referred based on PIN, ..."

I entirely agree with Herman. Of course it will require a lot of work on many sides (EGD, pairing programs, tournament organizers, etc.), but a lot has been done so far, it is important to keep on.

Tapir: Hi all, the cyrillic, hebrew, arabic letter argument in a discussion about latin alphabets pretty much looks like a straw-man. As well the ¼ argument in ISO-8859-15, since it is so very uncommon in names. However, contrary to Zarlan I believe adding all diacritical signs and language-specific special-letters to the package may allow to add the single correct spelling but will generally increase confusion as a lot of players may habitually write simplified-latin-alphabet e.g. in online forms, correctly in on-site forms etc. I would address this only after the PIN (integration) issue, however I don't like that Herman mixes things up conceptually - i.e. non-standard signs in latin alphabets with other alphabet types as native alphabet, because both are different issues. E.g. a name written in non-standard latin alphabet other latin alphabet users may at least read (and pronounce more or less wrong without need for transliteration) while cyrillic, hebrew, korean names will definitively need a transliteration at the European Go Congress.

Flatline: The discussion was not about Latin alphabets, until I had the bad idea of using this definition. I meant it strictly related to the Basic Latin, but unfortunately this messed things up because there are many "Latin alphabets". A couple of posts ago I suggested to drop any reference to Latin since it clearly drives us on a slippery floor, and stick to the ASCII definition. What I'm saying, is that for all the above mentioned reasons, I think that - for the time being - players names in EGD must be in ASCII characters, in order to avoid further complications.

tapir: Well, the request was about names with certain non-standard latin letters and diacritic marks. Regarding complications, I don't disagree :)

• Zarlan: This might seem like I'm harping on about the issue, despite acknowledging that I wouldn't convince anyone, but Herman made new assertions, so:

I hardly see how not being able to render Latin_Extended-C, Latin_Extended-D and the last few letters in Latin_Extended-B, would cause any problem with names, so I think that's a straw man as well (not saying it's intentional, of course, but...). As I see it, Herman has, in arguing against me, done nothing more or less than confirm my point (about browsers being able to render the characters). The argument that Russia is a big part of Europe is also unconvincing. So is Greece. We don't use Greek letters, because only the Greek can read them. All of Europe can read Latin letter though.

I'd love to see an ASCII+Native solution though, with PINs to refer to players.

Herman: Actually, I was not arguing against you. I was arguing that although I like your idea in general, you seem to have an overly optimistic view of the simplicity of implementing it. I think it is a good idea for the EGD to support extended latin characters. But I also think it is a good idea to support other alphabets, like cyrillic. I think these are part of the same issue, and should not be solved separately, but together. I don't understand why you do not want Cyrillic. Over 10% of the EGD players have a Cyrillic name, are they second class go players?

Zarlan: Not arguing against me? You were arguing against my supposed overly optimistic view of how simple it is. How is that not arguing against me? (and what has your liking my idea, have to do with anything?)
Aaanyway...
Around 90% of EGD players can't read Cyrillic. 100% of EGD players can read Latin letters. Therefore, it is highly impractical to use Cyrillic, seeing as barely anyone would be able to read it. "Basic Latin vs Extended Latin" and "Basic Latin vs Complete Unicode" are completely different issues. To equate them, is an obvious category error. I don't think, say a Japanese person, would be offended at having his name written in latin letters, in the EGD. Everyone else would have reason to complain, if his name was written in kanji though, as gibberish (which it'd be, to anyone not able to read Japanese) has pretty much zero usefulness.

Herman: The current (basic latin) representation of the EGD is readable by 100% of players. What is the added value of using extended latin, when not all of extended latin is readable by 100% of the players? How many of the "extensions and ligatures" at the list of latin letters can you read? How many of the letters with diacritics? How many can you pronounce correctly?

In my opinion, the added value is that you can write a persons name correctly, even if that means that not everyone can read or pronounce it correctly. This especially has value in domestic tournaments or rating lists, where all the players will know how to correctly read and pronounce the names.

My suggestion was to use a basic latin representation, as well as a "native alphabet" representation. A solution that allows absolutely everyone to have their name represented in a readable format for Europeans in general, but also in a correct format for domestic use. So Russians at a Russian tournament can print names in Cyrillic, Hungarians tournaments can print them in the Hungarian alphabet, etc.

tapir: Can you read a wrong written (in simplified latin letters) e.g. turkish name correctly - without knowledge of the language? I guess no. You may not read correctly if it is written with extended latin letters, as well. But at least this is a strange argument against the extension - the diacritic mark or additional letter may at least makes you aware of that. Even in the player by PIN age there may well be three modes: simplified latin, extended latin for correct names in latin alphabets, native mode for non-latin alphabets. simplified latin for latin alphabets has little relation with transliteration from languages using non-latin script, and to point to this difference is no offence to speakers of those languages. Otherwise I totally agree to flatline and herman, that it is wise to wait for the PIN-age :)

Zarlan: Well Herman... "How many can you pronounce correctly?" you ask? Can you pronounce the name... "Louis" correctly? Or "Aron"? There are more than one way of doing it, you know. How do you pronounce the letter v? Basic ASCII, yet you still don't know how to pronounce it. The problem isn't the ability to pronounce, but to read. How many can I read? All (more or less correctly). Well, my browser might not render all of the letters, but as I've already said, I seriously doubt that any of those exist in names. As to the rest... I fully agree with tapir.

Herman: Er, yes, exactly. The point I was making above is that neither basic latin nor extended latin really allow non-native speakers to pronounce the name correctly. You claim you can read all of them. But what do you mean by that? Obviously, you don't mean you can pronounce them, so what do you mean when you say you can "read" them?

As I have said, multiple times now, I am not arguing against the inclusion of extended latin. I am arguing against the exclusion of Cyrillic (and other alphabets). Why should a large part of the European go players not be allowed to have their name spelled correctly? What is wrong with having both a correct (native alphabet) spelling and a general use (basic latin) spelling? Sure, as tapir suggests, we can have it in three formats (basic latin, extended latin and native) if we want. We could even have the software try to automatically convert between such representations (through iconv and things like that), based on what usage is intended.

Flatline: Forgive me if I may be repetitive, but I'd like to better explain my point of view.

1) people who send tournaments data to EGD are many, with many different systems and skills; I want to make things as easy as possible for them, and at the same time I want to reduce the possibility of serious mistakes. Please consider that such people often are handling players coming from different countries, so - for instance - an italian organizer can have in his tournament players coming from Lithuania (such as Janavièiûtë Þivilë and Damoðiûtë Rûta), from Sweden (such as Vestgården, Øystein), France (such as Seailles Jean-François) etc... Well, this guy has neither an adequate keyboard nor the necessary skills to handle correctly these names. So, he will have troubles (first problem) and the data he will send to EGD will suffer of likely errors (second problem). And it's not a good answer saying "go and ask the player himself", because sometimes this can be difficult.

2) EGD wants to be as easy-accessible as possible. So I say that yes, I'm also concerned about the fact that not every browser renders correctly extended charsets. I agree that this can be played around by storing two different formats (maybe three, as tapir suggests), so I think that this will be the way. Not a trivial one, by the way...

tapir: I guess additional name formats will be possible/convenient to handle only after the PIN-age started, anyway. P.S. Just to make sure, EGD is wonderful even in basic latin letters.

Flatline:

"I guess additional name formats will be possible/convenient to handle only after the PIN-age started,"

Sure, I meant that.

"P.S. Just to make sure, EGD is wonderful even in basic latin letters."

Well, I feel better! Thank you :-)

Zarlan: I don't quite feel like explaining how people can read a name like say Vlad Ţepeş (aka Dracula), despite not quite knowing how to pronounce it and as it's not really that important in affecting the EGD anyway... Also, I should perhaps clearly state that I understand and acknowledge Flatline's concerns now. Not the rendering issue, on which I am still unconvinced, but the rest is enough by itself. I hope that the PIN-age will come soon :)

Tapir: Imho the "reading argument" wasn't an argument at all whether I write Özge Işık or Ozge Isik only people knowing the language will pronounce it correctly, both can be read, but the first is even written correctly and helps by indicating that your pronouncation may not be correct. Damoðiûtë Rûta is a fine example, I would instantly ask before the game how to pronounce the name. The "writing argument" is much more convincing. Waiting for the PIN-age...

deft: I can only say that the situation for scandinavian players is very bad, as there is a big difference between A and Å, O and Ø and in fact they may be completely different names. We normally substitute aa for å but in fact we have people who have this substitution in their family name for historic reasons. I think these letters are present in all Latin codepages and I know for a fact they are supported by the MacMahon software so I don't see any good reason why the EGD doesn't support them.

eta parameter

Not really that important for the EGD, but I noticed the eta parameter seemed to be at 0.0016 recently, it used to be lower. Did I miss when this was changed? Maybe a record could be left here?

• Flatline (does this question come from tapir...?) Actually it isn't strictly an EGD question, nevertheless you are right, a record should have been left. The epsilon parameter changed recently from 0.014 to 0.016 (not 0.0016), exactly when all the ratings have been recalculated before the startup of EGD as official repository, i.e. at the beginning of April 2009.
  • IanDavis No I asked it, I think it looks like a good idea to increase the eta parameter.
  • Flatline: I know :-) I've explained WHEN this change occurred.
  • geoff How did you decide on the value of eta - did you carry out simulations?
    • Flatline: It has been decided by Aleš Cieply. Yes, he carried out simulations (BTW: epsilon, NOT eta)

• IanDavis The BGA website uses a secret interpolation formula to track the rating of an average shodan across Europe. For many years this had been slowly sinking lower and lower in value - from 2100 down to 2035. This year it seems to be climbing upwards and has now reached 2039. This is an interesting development, if it continues there may be scope for reducing the epsilon parameter to 0.015?

GoR vs. Rank Progression Chart

Edu: Currently the chart shows tournaments on the x-axis equally spaced. Could you think of changing it so, that the x-axis would really represent time. In other words, if there are tournaments in the beginning of 2004, 2005, and 2008, the spacing between the last two would be three times the spacing between the first two. This would help interpretation of any single chart as well as comparison of several charts.

• Flatline: You are right. It's already in my to-do list.
• Flatline: Ok, I did it (Sep 5th 2009)
  • tapir: Cool!
  • Phelan: I second the "Cool!". However, the graphs now are missing the legend that they had, indicating which is GoR and which is Rank progression.
    • tapir: Isn't that obvious?
    • Flatline: anyways I've added it
  • Edu: Great! Thank you also for such a quick response.

Herman: Is it an idea to have the graph size at a fixed width per year, instead of a fixed width for the whole graph? As it is, the graph will crunch further and further together as years get added. Instead, perhaps a format that uses 1 pixel per week (so 52 per year) would work? Those longest in the database (1996-2009, almost 14 years) will currently have a graph about 700 pixels wide, which is quite acceptable for any display resolution. I think it would also stay acceptable for quite a long time (eg: after 20 year, in 2016, the width will be just over 1000 pixels, easily acceptable even on today's screens).

• Flatline: I'm not convinced... The advantage with fixed-width graphs is that you can get as much precision as you can with your - let's say - 700 pixels. The fact that they tend to crunch is anyway unavoidable, unless you plot graphs that exceed the normal screen width. The only real advantage I see in your proposal, is that it would make easier comparisons. But I'm already working on this, since I want to make a side-by-side graph comparison tool.
  • Flatline: Done.

Pictures and .sgf policy

tapir: What is the policy regarding pictures and .sgf-files? Should not pictures be uploaded only with approval of the person showed? And what happens with kifus... if someone prefers not to have a game uploaded, but the opponent did?

• Flatline: All pictures are uploaded only after a written request or permission by the person showed, or by his/her parent(s) if he/she is underage. Regarding sgf: once you partecipate in a tournament your games are public, and you can hardly claim they are not: they are under any perspective public sport events.
  • tapir: Admittedly, there are games I prefer to forget instead of having them downloadable for future generations.

tapir: Once more concerning .sgf's. What if a .sgf uploaded by one player contains mistakes? (Not only the mistakes made by the unhappy opponent who don't want to see it online, but recording mistakes.)

• Flatline: Not a serious issue, anyway :-) It must be fixed, of course, or removed. What if the two players don't agree...? Well, never happened so far, in case I'll remove it.

eko410: What about to combine the .sgf files and game pictures? It would be great if we can upload a photo taken during a game like uploading the .sgf file of that game (the photo may show two opponents or the go board during the game).

Data access

• Herman: I would like to be able to experiment with extending the EGD's functionality. Is there any possibility to get remote access to the data in a convenient way, eg SOAP or similar RPC protocol?
  • Flatline: We haven't developed such interfaces yet. However we are willing to do it if this can drive to improve EGD's functionality. At the moment, for instance, we are studying how to integrate EGD and OpenGotha for submitting results. Please share your ideas with me, we shall see what we can do together.
    • Herman: Ok, here's some ideas: (note, some of these can equally well be done with a simple copy of the data, other would be more interesting if up to date)

1. I would like to generate additional statistics. Eg: Generate a histogram that shows how many games a player played against different ranks since a certain date, and what percentage of those games he won.

• Flatline: That sounds nice. I think it would be useful to add such histogram in the player's card. If you'd like to take care of it, we can continue this discussion privately.

1. I would like to be able to experiment with the GoR formula, for example changing the a and con parameters and seeing how that impacts the reliability of predictions down the line, etc. Eg, from a certain period take randomly 90% of games, feed them into GoR to update ratings, then calculate how reliably those ratings predicted the results of the remaining 10%. Things like Jeff Sonas did for the chess Elo ratings (See: http://www.chessbase.com/newsdetail.asp?newsid=562)

• Flatline: To do this, you need to have full access to the complete tournaments tables. I can grant it to anybody upon simple request, since the only concern is about bandwidth.

1. I would like to try and find interesting things. For example, can I find a group of three players, A, B and C, who defeat each other in a circle (A defeats B 60% of games, B defeats C 60% of games, C defeats A 60% of games).

• Flatline: Help me to better understand your idea: you mean a published toolset of predetermined interesting-things-detection for the general audience, or the pssibility to dig off-line into raw data for specific researchers ?

geoff When you say integrate EGD and Open Gotha I wonder exactly what you mean. My system produces a file from GoDraw? in the correct format for uploading to EGD and it all works very well.

• Flatline: I mean no need to enter the EGD backend to upload data, just clicking a button from OpenGotha. Also, using EGD webservice support when registering players for a tournament.

Yes Flatline, This looks to be a nice feature! I am ready to make the OpenGotha's part of the job

Comparing populations

• tapir: I would like to compare populations - say finnish - dutch, london - istanbul (for this the data may be insufficient) by calculating the overall GoR change due to the matches of a certain period. This would permit to spot rating differences and follow their changes over time. The kind of study mgoetze refers to above.

Get data via AJAX

• Flatline Ok, it's a little weird that I'm opening a "wishlist" topic, but I'd like to know your opinion about this matter: <GEEK MODE ON> I've developed a little tool which can be accessed as a web service: you call it with http://www.europeangodatabase.eu/EGD/GetPlayerDataByPIN.php?pin=XXXXXXXX and it gives back a JSON structure containing player's data from EGD database (try it, if you like). Do you think that it is useful, so that it can be regarded as a new feature ? Do you think that would be worth to implement also a GetPlayerPINByData? (i.e.: last name [and country [and name and/or club]] ), given that names are often misspelled, so the returned data will be an array of possible PIN's ? <GEEK MODE OFF>
  • tapir: I guess this is useful to cross-check (e.g. as a tournament organizer). Though I won't use it that much personally.
    • Flatline Frankly my idea was not only to let cross-checking, but also to specifically allow to setup webpages (or also desktop applications) for tournament registration with a direct link to the EGD database (just to get an idea, ahve a look at this registration form: http://goski.agi.go.it/index.php?option=com_wrapper&view=wrapper&Itemid=65 , and try typing the PIn OR the last name )
      • tapir: That's great!! No chance for tournament directors to mess up :)
  • TeeSushi Maybe it's possible to make a request by country and club? Thus a club can easily generate a list of his members and their actual status. Though I think it's not that important since most clubs use the lists that you can download at EGF ratings system.
    • Flatline: As explained in the Updates page, it is already possible to get data by country and club:

http://www.europeangodatabase.eu/EGD/GetPlayerDataByData.php?lastname=XXXXXXXXXX [&name=XXXXX][&country=XX][&club=XXXX]

N.B.: lastname OR country are required

• Sec? I came to this page to request for an AJAX interface only to find it is already there. great! - Can we also have access to the tournament data via AJAX? I wanted to play with generating different GoR-graphs and it would be nice to be able to get that data on a player-by-player basis.
  • Flatline: I'm happy you find useful this feature :-) For tournaments data, my only concern is that requests of this kind can be easily automated and can generate a huge bandwidth consumption... I'm thinking to allow requests on a single-tournament or on a single-player-history basis, and to limit the number of requests from the same IP.
    • Sec? if it is of any interest, the way twitter does it is to limit access to its API to "n requests per IP per hour" and people needing more need to request them stating why - they get a relaxed (higher) limit. -- For me this sounds like a valid approach. -- If you implement it, the ability to get all tournaments of a single player would be the most interesting, followed perhaps by a listing of all games within one tournament.

Four letter club abbreviations break functionality

Herman: With the introduction of four letter club abbreviations, a lot of the functionality for clubs is currently broken. If, for example, I want to generate a list of members and ratings for my club, Delft, I will find 12 of them under the abbreviation "Del" and four of them under "Delf". If I generate statistics for NL/Del, I get a nice graph of active players. But generating the same statistics page for NL/Delf, the graph is broken (due to there only being one year of data, I guess). But the bigger issue really is that there shouldn't be two pages for this at all. "Del" and "Delf" are the same club, so I'd like to see the statistics for players marked with either "Del" or Delf" together. Is there any plan to fix this? Perhaps by automatically converting old club abbreviations to new ones (so change "Del" to "Delf" for all older results, and convert it automatically for new results entered into the database). I would be more than happy to provide a list of Dutch clubs with "Old" -> "New" abbreviations, and I'm sure there's people all over Europe willing to do the same for their own country.

• Flatline: This sounds good: please do. I apologize for the inconsistencies introduced by the transition from 3-chars to 4-chars city codes, but this must be regarded as a temporary, unavoidable pain. We have already an automatic converter, so that with an "Old => New" table it is easy to fix everything. It is only necessary to find people willing to populate such tables (BTW: I've already fixed "Del" => "Delf").
  • Herman Thank you very much! I have sent you a file with (most of) the other Dutch conversions.
  • geoff My understanding is that club names can go up to 4 chars but EGD will continue to accept 3 chars. If so what is the convention you use to convert 3 to 4 chars?
    • Flatline: No. EGD does accept 4 chars.
    • PeterHB: For clarity, Flatline, can you confirm you are saying that from now on the EGD only accepts 4 character club codes? Or is that a misunderstanding? I'm hoping you will say that providing a once off file with matching of 3 to 4 character club codes will provide compatibility, and then results can be submitted in both 3 or 4 character format for a transition period of a year or two. A clear description of the situation would be helpful.
      • Flatline: EGD accepts up to 4 characters (i.e.: 1, 2 or 3 are accepted as well). However, the most widely used pairing program (MacMahon) used to export only 3 characters, so incoming data used to have this limitation. In May 2009 this program has been changed, and since then EGD strongly encourages to download the version 2.50, so that the city codes now can range as far as 4 characters. That's all. So, there is no need of a transition period of a year or two in which both 3 and 4 chars are used. Nevertheless, I urge every submitter to switch a.s.a.p. to 4-characters (i.e.: to download the latest version of MacMahon). Also, it would be very appreciated that some people from every country do the same job that Herman did for the Netherlands, i.e. provide a "3-chars" => "4-chars" conversion table AND act in their own country in order to make this same table available to every tournaments directors, and urge them to use it.
      • geoff: Are you planning to publish the club-code/club-names for each country? If this is not done then I am not convinced of the necessity of re-inventing 4 letter club codes. How are people in other countries supposed to know what the codes mean? One could just add a trailing underscore if you really want this for formatting purposes. In the UK all tournament results are submitted to me for processing and uploading to the EGD - we do not use MacMahon.
        • tapir: My impression was that a conversion table is needed because new versions of MacMahon will export 4 letters while old versions have only 3 letters - the problem isn't that the club has to have 4 letters, but that new 4 letter input should somehow compare with old 3 letter input which is still used, so the database can recognize A from Del is from the same city as B from Delf. Concerning conversion tables, can you give an idea for which countries they are still lacking, that we can spread the word?
          • isd: Clubs is not a very accurate field sometimes. It often happens that a player, living in a country (say Germany) will be from another country (say UK). He will use his club in the UK - COL, but this will be interpeted as a German Club. (or vice versa). I see this quite often. It would be nice to have a club conversion list (Full name to code-4 to code-3) published for each country to help out in such cases.

Class Z tournaments

Herman: At the moment, the EGD contains tournaments that are ranked A, B or C, depending on their thinking time. Is it an option to have a tournament class for tournaments with shorter thinking times, which would not count for the rating at all, but could still be uploaded? The purpose would be to have an archive of such tournaments. The reason I am asking is because someone on the Dutch go mailing list asked about the Dutch tournament archive (on the website of the Dutch go association). I would point him to the EGD, where he can easily find any tournaments played in the Netherlands, but realized that that is not actually true. Certain events will not be in the EGD because of their limited thinking time, despite being noteworthy tournaments. I would like, for example, to add the results of the Dutch lightning championships to such a category.

• kaiou: I agree with Herman, that would be nice. There are a lot of club tournaments, blitz tournaments etc that a lot of people would be happy to show on their EGD profile.
• Flatline: mumble mumble...
• Sec? oh yes. A comprehensive database of all go games would be a dream come true! :)

Ranks 21-30k

sh: In some countries (e.g. Germany, Netherlands, Belgium) it is common practice to allow kyu ranks in the range from 1k to 30k. The EGD database however only allows kyu ranks from 1k to 20k. I think there are several arguments in favor of expanding the valid range to 30k:

1) It is more beginner-friendly. Especially for children who play casually on tournaments, because their daddy or mommy or elder brother/sister attends the tournament. When I started to play on tournaments (after having played on KGS and having studied the game intensely for four months) I was 20k, and I noticed that there was a huge difference to the 30k players. So some of these kids who are nominally 20k but actually 30k would get creamed by someone whose playing strength is really 20k. This would not be very motivating and possibly even scaring off newbies to attend tournemants.

2) Sometimes the pairings of tournaments are created based on these ratings (opposed to those based on self assessment which is actually the majority of tournaments in Germany). They claim to make the pairings so, that players of equal strength play each other, hence the (very useful) method according to McMahon is applied. However with the narrow range this claim would really go astray in the ddk ranks.

3) A 30k player can actually reach a rating of 400 if he beats other 30k's in a tournament (one of my daughters is an example for that). This means that all the ranking tables below a rating of 400 are completely meaningless and it would leave only 16 relevant kyu ranks (which has also an influence on pt. 2)

4) One thing that makes go unique is that it has such a huge broadness of difference in playing strength. It is said that there are 40 ranks from beginner to professional, if a difference of one rank is supposed to be a 2/3 vs. 1/3 win probability. In other games there much fewer ranks, even in chess and chess like games the number of ranks does not exceed 20. So if you subtract the maximally 10 dan ranks it would leave 30 ranks for kyu players. So here we are.

I wonder why the EGD opted to allow only 20 kyu ranks when it was created.

Herman: Agree. Actually, I think there should be no bottom at all. The AGA rating system seems to function just fine without a bottom. The effect that sh mentions in point 3 for ratings under 400 can be very easily seen in this graph: http://upload.wikimedia.org/wikipedia/commons/7/77/Distribution_of_EGF_ratings_over_Ranks.png

Dieter: Just another opinion (oh, how fun is it to flood the web with one's opinions): I cannot distinguish between 22k or 17k. When I have to assess a newcomer at the club, by the time I can, they have already progressed up to 15k. I think 15k is the real starting point of a meaningful rank. So, absolute beginners will always get a rank of 25k, which means "default beginner rank, soon to progress to a meaningful rank". The ranks between 25k and 15k are just there to give some consistency to the ranking system. From that point of view, a 30k must be someone who doesn't know the rules or doesn't see any atari: indeed, such condition gives little potential for progress.

tapir: In my opinion one should start fetishizing rank as late as possible, better never. Considering yourself as a "my strength is 27k, i have nearly no chance against this 22k" holds you back. Kalli Balduin lets people (children) start at 50k, adding one rank per win (never subtracting) til they reach meaningful ranks to give some feeling of progress. That is not relevant to EGD though.

sh: It seems reasonable that a 2d player cannot distinguish between a 17k and a 22k. To him both players are incredibly weak. However when I was 17k, I had a tough game with a 23k on a tournament, giving him three stones. So the rank difference at these stages do make sense in my point of view, even up to 30k. Being 30k is a little bit more than just knowing the rules. It includes knowing about some very basic concepts as shown (and trained) on playgo.to. Rank is not an end in itself, it just serves to roughly indicate one's playing strength and create interesting matches on tournaments.

tapir: The main argument wasn't handicap is of no use for beginners (sure it is and it should be used - and is used - in play but reported as 20k) but it changes too fast for a rating system based on tournaments (at most one a month often less) to cope with. Rank adjustment by 2 stones between the tournaments -> reset of rating may well be the rule there.

Flatline: Just for answering sh who asked: "I wonder why the EGD opted to allow only 20 kyu ranks when it was created.": EGD was created this way for the simple reason that this was (and is) the provision stated by the EGF rating system. Having said this, I think it works fine. Tournament directors are of course free to use ranks below 20k, and to compute handicap basing upon these ranks. But these results - for the reasons explained by tapir - are not relevant to the rating system.

Herman: I think that the largest problem with the current system is the fact that many ranks stronger than 20 kyu are also affected. If, for example, a 13 kyu defeats a 25 kyu with a 9 stone handicap, then under the current system this is considered equivalent to him winning an even game against an 11 kyu. This is because the system silently upgrades the 25 kyu to 20 kyu (rating 100, because it doesn't go any lower), but does not adjust the handicap. The player will receive some 60 rating points for this match, while realistically it should only be worth 10 or so.

Dieter: I can understand the existence of a 25k rank. A 30k would lose with nine stones to a 21, who's someone who barely understands the most basic concepts. One cannot forbid such people to play 19x19, neither in tournament conditions, but I wouldn't encourage it either by encapsulating it in a rating system.

Herman: I agree that there is probably little point in trying to calculate ratings for players under 20 kyu, because such players usually improve so rapidly that their rating is unlikely to ever be accurate. I do think that it is bothersome that such players do influence the ratings of other players though. How about a solution where any player weaker than 20 kyu is put in the database at their reported rank, with a rating of zero (so they will be sorted below all 20 kyu's for purpose of generating lists), and their game are ignored for other players ratings.

Question about Very Large Handicaps

Ian? I was looking at this event, http://www.europeangodatabase.eu/EGD/Tournament_ShowGoR.php?key=T090831B My understanding was that games using handicaps greater than 9 stones were not entered into the rating system. I see from this event that they are.

• Flatline My fault. Actually games with handicaps greater than 9 stones have never been considered by the rating system. Now I've made the necessary corrections: EGD can accept them and can show them in the tournaments tables, but it doesn't consider them for the GoR recalculation. Sorry for the inconvenience.

AGA - GoR comparison

tapir: agagd and egd using the same technics may be an opportunity to approach the RankWorldwideComparison statistically at least between aga - euro-ranks. is something like this planned?

tapir: With the AGA-EGD link in place right now... is there any possibility to see an output of AGA-EGD rating relations soon? Basically all is in place, one just needs to extract this data.

• Flatline: Yes, basically... I haven't had a thorough look at the timeline of the double-hosted players yet, but I guess that very often they are people who have moved from Europe to US or vice-versa, so their data in the two databases come from different periods of their lives, making rating comparison unreliable. Nevertheless, maybe that some sort of comparison is possible.

• Velobici: Yes, hoping that both Flatline and I get some free time at the same time that we might work on this together.

Advanced tournament tables

It would be nice if the tournament table was presented as an HTML table, rather than as a simple text file in a box (the admin back end already has a function something like it). This table could then use some advanced styling and function. The German Association already has something like that on their own site. For example: http://www.dgob.de/tourn/tourn.cgi?f=07debbcp.txt&mode=cml

Some nice things that could be done:

• Show a win as green, a loss as red, a jigo as yellow and an unplayed round as blue/grey.
• Clicking on a result cell shows a popup with extra info (colors, handicap, result).
• Clicking on a player shows a popup with list of opponents and results (already present, but not as a popup, now the page reloads when you select a different player).
• Sorting by other columns (to show, eg, people with 4 points, or from the same club).

Flatline: Yes, it would be nice. When the tournament card was originally designed, it was intended in a very player-centric perspective. It occurs often to me to think that I should change it soon or later...

• Flatline: I did it at last.

More GET requests

Herman: Could more of the EGD be implemented as GET (as opposed to POST) requests? Right now, there are many pages that could easily be linked to directly with URL parameters if only GET were used instead of POST (eg: http://www.europeangodatabase.eu/EGD/Stats_Country.php?country_code=NL&club=Delf doesn't work, but there is no reason not to let it work).

Also, on a more formal note, the HTTP standard says that GET request should be safe (should not alter the state of the server), whereas POST requests can be unsafe (can alter the state of the server). Because of this, browsers should (and do) consider it unsafe to reload pages that were the result of a POST request (eg: go to the stats page for any club, then click reload, your browser should pop up a warning, asking for confirmation).

• Flatline: Try this: http://www.europeangodatabase.eu/EGD/Stats_Country.php?country_code=NL&club=Delf&ricerca=1

Herman Ahah, there is a secret parameter! :-)

• Flatline: EGD is a chamber of secrets ;-)

Automatically split events

Herman Sometimes, is useful for an event to be split into multiple events in the database. This already happens, for example, with the European Go Congress. The EGC is split into "first week" and "second week", which allows the weekend tournament to be processed between those two events. This has the disadvantage, however, that the EGD does not contain the wall list for the whole 10 round main tournament, even though it is a single event from a McMahon/Pairing point of view. It would be nice if the EGC (and possibly other events), could be entered as a single event, but with the added option to specify that it should be split over multiple dates. So in case of the EGC, some option to say "rounds 1-5 should count on date A, rounds 6-10 should count on date B". So in the database, it is visible as a single event, with 10 rounds, but for ratings calculation, it is split into two events in the background...

Declared rank updates between tournaments

Jouni: It would be nice if there is some kind of possibility to have declared ranks updated between tournaments. This would help pairings because up to date info could be retrieved directly from EGD with OpenGotha. Now direct usage of Gor for pairing is little tricky because we need to adjust possible pretournament resets by hand and there are possible cases where this is even impossible. Pairing with Gor should be essential especially in EGC because there are lots of Japanese and others who participate with non sense ranks, but often their Gors are already quite close after few congresses.

This would be great feature, because problem is quite significant in EGC. I think that it is enough control that registered and trusted EGD users could adjust declared ranks if needed. With Finnish ranks it would be easy because we have very practical common Wiki where is always maintained up to date official rank and tournament info. ( http://www.suomigo.net/wiki/Luokituslista) Similar wiki approach would work with EGD also, I think. Even though there are various degrees of rank liberalism in different European countries. (2009-12-01)

• Flatline : As far as I know, OpenGotha doesn't show the rank picked up from EGD; instead, it recalculates the correct rank from the actual GoR and displays this result. So, this feature would be useless. Furthermore, I don't think that EGD should allow ranks changes between tournaments, since it is basically a tournaments repository, and stores information about players only when they attend tournaments.

• Jouni: Perhaps it is difficult to find good solution for this, because of variations in rank liberalism. I wonder if there is a good method to introduce pretournament resets automatically? Of course the development of this feature should be done in cooperation between Aldo and Luc, if it is the case that people are willing to go for using GoR instead of declared rank in tournament pairings. I do not see why this is not the future of pairing, because GoR is superior in pairing accuracy compared to declared ranks. (2009-12-20)

• LovroF: You simply recalculate the rating yourself when starting the tournament...

Online Tournaments

Have you ever tought about giving rating for some online tournaments? The Fujitsu Preliminarys will be held on KGS this year... Maybe there would be more online tournaments for European players if they would be eligible for rating.

isd:The EGF doesn't accept ratings taken from online games. I don't see them changing their mind.

I know they didnt until now. But I think that would popularise playing of go. It would be good if they would maybe organise a tournament on some server once per month(or per two months, or every two weeks or whatever). Some players that are active but cannot attend tournaments would be quite satisfied.

isd: Wow, I just saw that the Fujitsu preliminarys were actually submitted. Maybe this is just a special case though?

I really hope they will start to accept online tournaments. As soon as they say they are accepting them, I will organise one.

Flatline: the Fujitsu preliminary has been a very special case. We are discussing within the ratings committee in order to settle rules for accepting on-line games in general. I guess that at the end they will be rather strict.

Well, we are waiting your decision than :)

Anything?

tapir: It seems kind of clear (to me) that in the end only special online events will count for this purpose. But how about e.g. the German Bundesliga. Played online regularly, but by people with identifiable EGF rating, appropriate time limits etc.

Lovro Furjanic - They will talk about it on AGM.

Anonymity, data security, feasability

Tapir: I read on a german go blog (Makko's Go Café) and the DGoB-Forum about some players wishing to be anonymous (in tournament play) and ongoing discussions between EGD and EGF and DGoB how to handle this. While I don't endorse this (tournaments are public, finally - though I dislike the excessive photographing at tournaments), I would be interested to read something about the current situation.

Herman: In my opinion, a go tournament is a public venue. If you do not want your name published, don't visit the tournament or register under a false name. You simply cannot run a tournament without publishing pairings and results. I do think we can expect tournament organizers to respect privacy insofar as to not publish personal details like email address, date of birth, or similar personal information, but I do not think that that privacy protection extends to the name of a player.

• tapir: I share this opinion. However, there is an ongoing discussion already. (I asked before about game records, which are sent with all errors to the EGD by some players. And the shame attached to have all those silly defeats safed for eternity, but this is another issue.)

Flatline: I've tried to read the blogs, even if I had to rely upon Google for the translation, since I cannot read German. Anyway in the reported case EGD didn't accept the tournament results, so the player agreed to move back to his real name. This must be regarded as a standard policy: nicknames are not allowed, for all the reasons already pointed out in the blogs as well as here.

• tapir: Thanks. If I am bored these days I can translate the blog entry. All what I know about it is from "Makko", I guess you stay in touch in EGD matters anyway.
  • Flatline: Yes, we are always in touch. Thank you for your promise to make a translation, but I have read easily enough Makko's Cafe, my problem is the DGob forum, where I've seen so many posts about the privacy issue, that I cannot ask you to translate all of them :-)
    • tapir: Indeed. That is way too much :)

sorting

• tapir: Sorting according placement obviously just compares strings thus making 110th place a better placement than 14th and that one better than 2nd place. it would be better to cut the string with the "/" and process the remaining placement as integer for sorting purposes.

European Go Calendar

• kaiou: It would be nice if there was a calendar of the upcoming tournaments, updatable in the way as the wallist uploading works. The official egf calendar is updated rarely and only lists the major tournaments. The wiki page is more complete, but only a few organizers are aware of his existance, or care about updating it (many time I added in bulk the italian tournaments). I often hear in kgs people that already look at the EGD as a reference for the past tournaments, and expect to find a calendar for the future ones.
  • tapir: i guess most people look at national pages for finding tournaments. and maybe that one of a neighbouring country. the player population that goes to tournaments across different countries regularly may be very limited.

Theoretical Question

Lovro Furjanic - Sorry, I did not know where to post this. Is there any possibility, whens omeon posts a tournament that is late, you lose rating. Let me explain. For example, in tournament A you get x number of points. It is not submited to EGD. You play tournament B and get y number of points( both x and y are positive). B is subminted to EGD. After that, A(it was held earlier) is submited to EGD. Is there any chance, that altough you won in both tournaments, your GOR drops after submitting of A because your profit on B got smaller as your GoR increased from A, and the margain by wich it decreased is bigger than one by wich it increased after A. Sorry iif I confused you...

Phelan: From what I understand, it doesn't matter when the tournaments are sent to the EGD. I don't really know how to explain it, but when the system runs after getting the new tournament(A), it will calculate the GoR change in tournament B based on the GoR the player has after A.

Lovro Furjanic - Thats exactly what I am talking about. If can your GOR from A increase less than your GoR decreases after you get lesser points B. I dont really know if you understand me :)

tapir: As far as i understand the system, the answer is a clear yes. I doubt however that if you won more than a handful of point you will end up losing points, but if you won 3 rating points in the first computation you may well end losing some points after some older tournaments are computed as well. But usually you add new tournaments to the database not old ones.

Unified Rating List

hyperpapeterie: Hope this isn't my ignorance, or a request someone else has made on here, but is there no way to show all players (including non-european players) in a single list, sorted by current rating?

tapir: The main list is basically a list of all players (with ratings according to European tournaments or tournaments with significant European participation). That's why WAGC etc. data is included. As far as I know this is the standard list shown to you on the EGD page.

hyperpapeterie: If I go to http://www.europeangodatabase.eu/EGD/EGF_rating_system.php, the option for all european players excludes some players (e.g. Kyoungnang Kang). The only other option I know of is to sort under the players page, which produces too many extraneous results (i.e. professionals who have never played in Europe). Were you thinking of a different list?

tapir: Just click on the submit button without any option and sort by GoR. ( here) Add or don't add the EGF only option. Seems you don't want this as well. But the reason is http://www.europeangodatabase.eu/EGD/Player_Card.php?&key=14733873, that she gives Korea, Seoul as residence. So there is no data in the database to divide her from those unwanted extraneous results.

hyperpapeterie: Thanks for letting me know that this option is the closest to what I want. I believe that there is a workable way to get the result I want based on the data in the database. You could filter for all and only players who have played a tournament in an EGF country. Perhaps there would be complications in implementing this, but I believe it would achieve the desired result of showing all players who compete in Europe.

Club graphing wrinkle

PeterHB: Looking at this couple of examples:
http://www.europeangodatabase.eu/EGD/Stats_Country.php?ricerca=1&country_code=UK&club=Read
http://www.europeangodatabase.eu/EGD/Stats_Country.php?ricerca=1&country_code=UK&club=Purb
There is a 'JpGraph Error'. This appears to be caused by trying to create a graph from a single data point. I wonder if this special case might be intercepted, and a less obtrusive message displayed. Just a minor suggestion.

• Flatline: You're right. I've removed the graph when there is a single point to be plotted.